RE: back-bdb deadlocks

["Howard Chu" <hyc@highlandsun.com>]

I may have misconfigured something, I'm testing again with
set_lk_max_locks 200000
in my DB_CONFIG file. Apparently I ran out of free locks in my previous test.

I have two threads doing a stream of adds, and another thread doing a
repetitive add/delete stream, plus several search threads going at once.
I guess the search threads are unnecessary in this case since there is
no transaction work there. I think you need at least 3 writers to trigger
the problem.

It looks like it may run to completion, usually it locks up very quickly. THis
may be Stupid Human error...

  -- 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: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Wednesday, January 16, 2002 7:48 PM
> To: Howard Chu
> Cc: openldap-devel@OpenLDAP.org
> Subject: RE: back-bdb deadlocks
>
>
> 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
> >>
>