[Date Prev][Date Next]
Re: back-bdb deadlocks?
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.
Looks like we are heading to a right direction. One thing to note is that
there's currently no retry mechanism provided for the added transaction.
Also lacks the retry mechanism is bdb_cache_db_relock() itself. If it is
selected as a victim to resolve a deadlock, it needs to restart the op if
it's a write op, or it needs to restart the locking transaction if it's a
OK, I've added retries to the two remaining callers of
bdb_cache_find_id() and made sure the lock return code is propagated
back to the caller. That should be OK now.
Also, I still suspect that we need to protect db ops in a search op
in order to insure deadlock freedom
(http://www.sleepycat.com/docs/ref/lock/notxn.html), although it might be
I'm not sure that doc applies; this application is transactional, and
all of our writes are protected. With this patch, most of the reads are
protected as well and in general, a read operation never holds onto any
page locks. Deadlock requires each thread to attempt to control multiple
resources at once; with the exception of the brief transaction in
bdb_cache_find_id() our read operations don't do this. They grab one
entry at a time and release it before moving on to the next.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support