You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Andreas Benneke (Jira)" <ji...@apache.org> on 2021/03/14 16:06:00 UTC

[jira] [Updated] (AMQ-8187) ActiveMQ should support local transaction even in JTA mode

     [ https://issues.apache.org/jira/browse/AMQ-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas Benneke updated AMQ-8187:
---------------------------------
    Description: 
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 
{code:java}
javax.jms.JMSException: Session's XAResource has not been enlisted in a distributed transaction.
 at org.apache.activemq.ActiveMQXASession.doStartTransaction(ActiveMQXASession.java:101) 
{code}
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-2659 it does no longer.
 * With AMQ-2659 one 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 {{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.

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

 
{code:java}
javax.jms.JMSException: Session's XAResource has not been enlisted in a distributed transaction.
 at org.apache.activemq.ActiveMQXASession.doStartTransaction(ActiveMQXASession.java:101) 
{code}
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-2659 it does no longer.
 * With AMQ-2659 one 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 {{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.


> ActiveMQ should support local transaction even in JTA mode
> ----------------------------------------------------------
>
>                 Key: AMQ-8187
>                 URL: https://issues.apache.org/jira/browse/AMQ-8187
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: XA
>    Affects Versions: 5.16.0, 5.16.1
>            Reporter: Andreas Benneke
>            Priority: Major
>
> 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 
> {code:java}
> javax.jms.JMSException: Session's XAResource has not been enlisted in a distributed transaction.
>  at org.apache.activemq.ActiveMQXASession.doStartTransaction(ActiveMQXASession.java:101) 
> {code}
> 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-2659 it does no longer.
>  * With AMQ-2659 one 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 {{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.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)