RE: back-bdb deadlocks

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

I've modified test008 to have two add/delete threads working
on siblings...  I haven't deadlocked yet.  Is this an equivalent
case?

Kurt

At 07:36 PM 2002-01-16, Howard Chu wrote:
>I've cleaned things up and recompiled/linked with BDB 4.0.14 (was using 3.3.11)
>and the same deadlock occurs in txn_abort. You're right, this sounds like a bug
>for Sleepycat to address. I cannot find any code path that bdb_add executes
>without a transaction, so it appears we're doing the right things.
>
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support
>
>> -----Original Message-----
>> From: Lawrence Greenfield [mailto:leg+@andrew.cmu.edu]
>> Sent: Wednesday, January 16, 2002 6:13 PM
>> To: openldap-devel@OpenLDAP.org; Howard Chu
>> Subject: Re: back-bdb deadlocks
>>
>>
>>    From: "Howard Chu" <hyc@highlandsun.com>
>>    Date: Wed, 16 Jan 2002 16:40:15 -0800
>>
>>    I believe a similar solution to this is needed in back-bdb, but I
>>    haven't yet spent much time thinking about it can work. The current
>>    situation is that back-bdb gets deadlocked very easily by more than
>>    2 simultaneous updaters.  There doesn't seem to be any easy
>>    solution to this; my debug session with three deadlocked threads
>>    showed that two of them were deadlocked in txn_abort - i.e.,
>>    deadlock detection already did it's job, but new locks were still
>>    needed to unravel the transaction. Pretty rude. (I suspect this
>>
>> If this is happening and OpenLDAP is playing by Berkeley db's rules,
>> there is a bug in Berkeley db and it should be reported to Sleepycat.
>> I've never seen something like that happen in my testing, though I
>> very rarely play with multithreaded programs.
>>
>> Larry
>>