Ticket 47797 - DB deadlock when two threads (on separated backend) try to record changes in retroCL
Bug Description:
The DB is opened so that if a db lock can not be granted it does not wait and returns DB_DEADLOCK
In some part of code, the server just loops retrying where it should abort the txn (and release the locks
it may hold) and retry with a different txn
Fix Description:
If DB_LOCK_DEADLOCK is returned, the correct course of action is to abort the (possibly nested) transaction
and retry the database operation
file:///usr/share/doc/db4-devel-4.7.25/gsg_txn/C/lockingsubsystem.html
Resolving Deadlocks
When DB determines that a deadlock has occurred, it will select a thread of control to
resolve the deadlock and then return DB_LOCK_DEADLOCK to that thread.
If a deadlock is detected, the thread must:
Cease all read and write operations.
Close all open cursors.
Abort the transaction.
Optionally retry the operation. If your application retries deadlocked operations, the new attempt must be made using a new transaction.
https://fedorahosted.org/389/ticket/47797
Reviewed by: Rich and Mark (Thanks)
Platforms tested: F17/F20 (ipa unit tests)
Flag Day: no
Doc impact: no