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

[Andrae Muys]

On 11/02/2008, at 10:24 PM, Life is hard, and then you die wrote:

> On Mon, Feb 11, 2008 at 09:56:56PM +1000, Andrae Muys wrote:
>>
>> On 07/02/2008, at 4:08 PM, Andrae Muys wrote:
>>> 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.
>>
>> Found and fixed - an attempt to be extra paranoid about resetting the
>> transaction state on session-close backfired when resetting the
>> manager's state prevented the factory from resetting properly.
>> Details in commit log - fixed in revision 639.
>
> Works for me. Thanks!

Just stopped working for me - identified as a lock-ordering deadlock  
introduced in this fix.  There's now a race-condition between  
starting/stopping a transaction and closing the session.

Andrae

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