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