When running a JTA environment it comes quite handy to not always having to blow up a full JTA transaction
if you already know in advance, that a particular interaction does not require synchronization
with other resources or interactions.
Until 5.15 ActiveMQ did support this, but the last changes in https://issues.apache.org/jira/browse/AMQ-2659 broke this.
When you now try to interact with ActiveMQ in such a local transaction you get
This is perfectly correct when one want to enforce JTA transactions, but exactly not wanted for local transactions.
I am not sure, where the problem here is. Some thoughts:
- Until 5.15 the ActiveMQXASession supported this by itself, but as of
AMQ-2659it does no longer.
AMQ-2659one could think that the intention of the change was to make ActiveMQXASession no longer work outside JTA transactions.
- I am however not sure if the consequence was intended, that is now no longer working in local transactions as well.
- The ActiveMQXASession is created by ActiveMQXAConnection.createSession, however the first parameter "transacted" is effectively ignored and a (transacted) ActiveMQXASession is returned even if transacted is false.
- createSession(false, ...) is exactly what the transaction managers do to start a session in a local transaction (e. g. see DualSessionWrapper.createNonXASession in Bitronix)
- Or are the transaction managers doing something wrong here? If, how should sessions on such local transactions be initiated?
Please find a stripped down test case here https://github.com/abenneke/sandbox/tree/master/activemq-local-transactions.
It has tests using Bitronix and Atomikos to reproduce the given cases.