[Mulgara-general] New JTA support now considered beta - please test and report success/failure to the list.

[Andrae Muys]

On 07/02/2008, at 2:15 PM, Life is hard, and then you die wrote:
> Using the mgr-73 branch, I'm getting a failed assertion doing
> essentially
>
>   s1.setAutoCommit(false)
>   insert/query
>   s1.commit()
>   s1.close()
>
>   s2.setAutoCommit(false)
>
> Shouldn't the session.close() reset things? (Note this not using
> XAResource yet).

Ok, looking at the transaction code with fresh eyes it is clear that  
I wasn't thinking clearly when I was managing the writeTransaction  
field.  This field was critically important in the pre-JTA code, as  
it was involved in tracking the holder of the write-lock.  Now it has  
been demoted to a reference to the holder to ensure the cleanup  
routines work correctly.

Unfortunately (as demonstrated by your example) that cleanup code  
isn't right.  I'm also concerned to see that I've masked the field in  
the external transaction factory, meaning that I doubt it can be  
written correctly until I untangle that.

Thanks for catching that, I'll think some more about how to resolve  
this, and hopefully have a patch ready sometime tomorrow.

Andrae

-- 
Andrae Muys
andrae at netymon.com
Senior RDF/SemanticWeb Consultant
Netymon Pty Ltd