[Mulgara-dev] MGR-70 - Transaction Deadlock bug.

[Andrae Muys]

I think I've fixed this, but of course only time will tell.  Given  
the nature of the bug I would appreciate it if anyone with any  
understanding of the transaction code could look at the stuff I did  
in the mgr-70 branch - I will feel much better knowing there's been  
at least some code-review before I merge into trunk.

The problem (like all deadlock bugs) was lock-ordering.  Specifically  
some operations are Session specific, and some are Transaction  
specific.  The Session specific ones start by making a request of the  
TransactionManager, which may activate and use various transactions  
to complete the request.  The Transaction specific ones start by  
activating the Transaction, which may or may not call the  
TransactionManager to keep it informed of the transactions lifecycle.

Naturally both the TransactionManager and the Transaction have locks  
that need to be obtained at various times, and so if there are two  
concurrent operations pending on the Session/Transaction we can have  
deadlock.

Avoiding this shouldn't be hard, as we only allow clients to have one  
operation pending per Session - the problem comes when there is a bug  
in the client.  The solution I [believe I] have implemented is to  
defer obtaining the Transaction lock until we have confirmed the  
client has not violated the concurrent access ban.

As mentioned above I would appreciate any code-review.

Andrae

-- 
Andrae Muys
andrae at netymon.com
Mulgara Consultant
Netymon Pty Ltd