[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: back-bdb deadlocks?

Howard Chu wrote:

A read operation can cause an undetected deadlock when loading an entry into the cache. This is because the lockerID used to lock the cache entry is not the same as the lockerID BDB generates when accessing the database. If a writer has already locked the id2entry pages and is waiting on a write lock for the cache entry, then the reader will be stuck waiting for the id2entry pages and neither will make any progress.

This implies that we must use transactions for readers as well as writers, to insure that all locks associated with a read operation get the same lockerID, so that deadlocks can be detected by BDB. Either that or we need to tweak the lock ordering again so that a reader cannot hold any other locks while it is accessing the database.

I've checked in a fix for this. Creating a new transaction for every search operation would add a fair amount of overhead, so I've allocated long-lived per-thread transactions instead (similar to the way locker IDs are being re-used). We can't just replace the existing lockerID mechanism with these transactions, because the intended lifetimes of their locks are not the same. Anyway, I think this should finally resolve the deadlock issues.

Please test...
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support