[Mulgara-dev] transaction implementation

Andrae Muys andrae at netymon.com
Tue Jul 1 14:57:12 UTC 2008


On 01/07/2008, at 6:41 PM, Life is hard, and then you die wrote:
> First of all, the MulgaraInternalTransactionFactory and
> MulgaraExternalTransactionFactory are scoped per Database (i.e. per
> SessionFactory); however, all methods require a Session parameter, and
> indeed all data managed by these factories is on a per-session basis
> with no cross-session operations. Wouldn't it therefore be better to
> make instances of these session-scoped in the first place? That way
> not only are the data structures simplified, but we can get rid of the
> mutex and thereby reduce the potential for deadlocks. I.e. is there
> any future reason why these instances should stay session-factory
> scoped? (Btw., I've make this change in my local repository and
> verified it works and have not overlooked anything regarding the
> current state of things).

Certainly we could track the 'current-thread' with a simple  
synchronized block.  We do need to ensure that the Session is not  
subject to concurrent invocation, and that is handled by the  
transaction implementation.  The Factories are the result of  
refactoring to isolate the write-lock handling in the manager, and  
the rest of the transaction management in the 'factory', I hadn't  
noticed that in doing this I had eliminated the factories dependence  
on Database.  We should be alright to change the scope on this, and  
indeed this would make alot of sense architecturally.

> Second, there appears to be some duplication of functionality between
> both MulgaraInternalTransactionFactory and
> MulgaraExternalTransactionFactory, and between
> MulgaraInternalTransaction and MulgaraExternalTransaction (e.g. the
> timeout handling and the transaction abortion). It would seem like a
> cleaner approach if MulgaraInternalTransaction(Factory) instead were a
> wrapper around MulgaraExternalTransaction(Factory). In this setup
> MulgaraInternalTransactionFactory would start a JTA (Jotm) transaction
> and enlist the XAResource from MulgaraExternalTransaction, and
> MulgaraInternalTransaction would then just need to manage the
> suspension and resumption of transactions and could leave most of the
> transaction cleanup/abort code to the MulgaraExternalTransaction
> implementation; similarly MulgaraInternalTransactionFactory could be
> noticeably simplified.

I recall having difficulty figuring out how to make this work without  
changing the existing behaviour.  But I must admit, once I got the  
internal/external split working, I didn't revisit that decision.  It  
may be that now the code is working and stable, making the full leap  
to a fully JTA based internal implementation may end up being  
straight forward.

Andrae



More information about the Mulgara-dev mailing list