activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Guggi <>
Subject Re: XA Transaction with multiple xa-connections not working on rollback
Date Sat, 06 Apr 2013 19:41:42 GMT
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)


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

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


On Sat, Apr 6, 2013 at 8:48 PM, Daniel Guggi <> 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 <>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-
>> thank you,
>> daniel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message