Re: back-bdb deadlocks

[Marijn Meijles <marijn@bitpit.net>]

You wrote:
> 
> Using the Berkeley DB lock_get() function to get a WRITE lock associated with
> the transaction. The object being locked is a string, the parent DN. It is not
> associated with any particular database. When the transaction commits or aborts
> the lock is automatically discarded along with the rest of the transaction.
> This would appear to be the only safe way to handle locks in the txn
> environment.
> 
I see, I assumed wrongly that you could manually lock an entry in a db.

But what you are doing bottom-line is just locking the parent, because
the retries take longer than the increased concurrency gains. As I've
outlined earlier, there are other ways to resolve this issue. If I
were you, I wouldn't give it too much thought right now as the concurrent
behavior will change big time when you put in an entry cache. Better do
the tuning after you put in an entry cache.

> I've tried several other approaches as well. One that helps is to run the
> deadlock detector automatically, (dbenv->set_lk_detect) instead of having a
> separate thread do periodic deadlock checks. (When it deadlocks so frequently,
> resolving only once every N seconds is much too slow.) In addition, it seems to
> help a lot to configure with dbnosync. Not sure why, but the number of
> deadlocks drops dramatically then. Also setting the deadlock resolution to
> "youngest" instead of default ( =random ) helps. With these settings the test
> usually finishes in under a minute.
> 
Great to see that the design choices we made a while back without too much
testing actually sre quite good ;)

-- 
Marijn@bitpit.net
---
The light at the end of a tunnel may be an oncoming train.