[Date Prev][Date Next]
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.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support