activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mattias Jiderhamn <>
Subject Re: Synchronizations removed at JTA resume - bug?
Date Tue, 20 Nov 2012 11:28:22 GMT
It turns out that not only is this a bug, it is known bug:

I created a test case and commented on the above issue with reference to 
the test case.

I'll start another thread for discussing a workaround.


Dejan Bosanac wrote (2012-11-19 11:00):
> Hi Mattias,
> can you raise Jira with these details, so that it doesn't get lost in
> the emails. Also, it'd be ideal to have a test case that reproduce the
> issue if possible.
> Regards
> --
> Dejan Bosanac
> ----------------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Twitter: @dejanb
> Blog:
> ActiveMQ in Action:
> On Sat, Nov 17, 2012 at 11:34 AM, Mattias Jiderhamn
> <> wrote:
>> I've spent quite some time trying to figure out why ActiveMQ retry does not
>> work for us with JTA, and I may finally have found the reason.
>> In org.apache.activemq.ActiveMQMessageConsumer.registerSync() there is a
>> synchronization registered, that would handle the rollback (specifically
>> deliveredMessages.clear()) so that message is not considered to be
>> delivered, but can be redelivered.
>> However, in out case the JTA transaction of the ActiveMQ consumer is
>> suspended and later resumed, before it is rolled back.
>> JTA specification
>> (
>> section 3.2.3:
>> "When the application's transaction context is resumed, the application
>> server ensures that the resource in use by the application is again enlisted
>> with the transaction. Enlisting a resource as a result of resuming a
>> transaction triggers the Transaction Manager to inform the resource manager
>> to re-associate the resource object with the resumed transaction
>> (XAResource.start(TMRESUME))."
>> So when JTA transaction is resume()d the Resin JTA transaction manager calls
>> org.apache.activemq.TransactionContext.start(), in which the the
>> synchronizations list is set to null!
>> It seems to me that some JTA implementations do not call XAResource.start()
>> on resume() even though the spec says so (the way I read it), which may
>> explain why this works for some people.
>> Would anyone agree if I claim there is a bug in ActiveMQ, that prevents it
>> from working properly with resumed JTA transactions...?
>> </Mattias>

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