the jta spec says:
3.4.6 Resource Sharing
When the same transactional resource is used to interleave multiple
transactions, it is
the responsibility of the application server to ensure that only one
transaction is enlisted
with the resource at any given time.
On Sat, Apr 6, 2013 at 9:41 PM, Daniel Guggi <daniel.gu...@gmail.com> wrote:
> glassfish code just does that:
>
> it know the following resources states (one TransactionContext per
> connection - same xid,same branch => imo ok because
> TransactionContext.isSameRM returns true)
>
>
> TransactionContext{transactionId=XID[4871251,globalId=4000ffffffcaffffff98ffffffceffffffe064676e622c7365727665722c50313030,branchId=64676e622c7365727665722c503130302c0]}=0,
>
> TransactionContext{transactionId=XID:[4871251,globalId=4000ffffffcaffffff98ffffffceffffffe064676e622c7365727665722c50313030,branchId=64676e622c7365727665722c503130302c0]}=0
>
> on rollback glassfish just calls end(xid,flags) once per xaresource (the
> xa resources above are equal i guess)
>
> on commit glassfish calls end(xid,flags) for every resource state
> (transactioncontext)
>
> don't know if this is correct - i didn't find anything in the jta-specs...
>
> or maybe it is wrong to consider that two xa resources are equal for
> different activemq-connections -> TransactionContext.isSameRM()
>
> daniel
>
>
>
> On Sat, Apr 6, 2013 at 8:48 PM, Daniel Guggi <daniel.gu...@gmail.com>wrote:
>
>> i forget to mention.
>>
>> when we do not throw an exception after the jms-template send everything
>> works fine - transaction gets committed org.apache.activemq.
>> TransactionContext.end(xid,flags) is called twice as expected...
>>
>>
>>
>>
>> On Sat, Apr 6, 2013 at 8:46 PM, Daniel Guggi <daniel.gu...@gmail.com>wrote:
>>
>>> hi,
>>>
>>> we use spring's DMLC using an xa-pooledconnectionfactory
>>>
>>> when the DMLC receives a message the (test) message-lister just sends a
>>> message to another queue using spring's jmstemplate. this jms-template also
>>> uses a xa-pooledconnectionfactory (but another instance)
>>>
>>> that meas that we have two activemq xa-connections - one by the listener
>>> and the other by the jms-template
>>>
>>> if the message-listener throws a runtime-exception after jmstemplate
>>> send, the rollback is not properly performed.
>>>
>>> i can see that org.apache.activemq.TransactionContext.end(xid,flags) is
>>> only called once for the dmlc-connection - so therefore no rollback is not
>>> performed for the other xa-connection/session, which leads to a (jta)
>>> system-exception on the next-message, because the pooldcf returns the
>>> cached session
>>>
>>> any ideas how this could happen - this might be a jta issue? btw. we are
>>> using glassfish-3.1.2.2
>>>
>>> thank you,
>>> daniel
>>>
>>
>>
>
