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