[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: back-bdb deadlocks
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
>