[Mulgara-dev] transaction implementation

[Life is hard, and then you die]

On Wed, Jul 02, 2008 at 12:57:12AM +1000, Andrae Muys wrote:
> 
> 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.

This is already being done, but it's done in the
MulgaraInternalTransaction, not the factory.

> We do need to ensure that the Session is not  
> subject to concurrent invocation, and that is handled by the  
> transaction implementation..

Two things here: it is my understanding that Session implemenations
(i.e. DatabaseSession) are not required to be thread safe, i.e. an app
must do synchronization itself if it uses the session in multiple
threads. Second, the Mulgara{In,Ex}ternalTransaction implementations
don't synchronize right now (with the exception of the activation
mutex in the MulgaraInternalTransaction); however, I've already had to
change that to fix an issue with timeouts, so as of my next checkin
the transaction implementations will be thread-safe.

> 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.

Good. Then I'll finish that up after I finish the transaction
synchronization.

> > 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.

Ok, I'll have another look at this then.

Thanks for your answers.


  Cheers,

  Ronald