[jira] [Comment Edited] (ARTEMIS-4180) Unable to differentiate between XA and non XA connection factories

["Julio J. Gomez Diaz (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARTEMIS-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693276#comment-17693276 ] 

Julio J. Gomez Diaz edited comment on ARTEMIS-4180 at 2/24/23 5:08 PM:
-----------------------------------------------------------------------

Sure [~jbertram] ,  we use Spring Framework with Spring Boot.

When a connection factory supports XA transactionality (XAConnectionFactory) and its created as a bean in the Spring Context a Bean PostProcessor takes all of them and, ONLY IF it implements XAConnectionFactory the object it's wrapped by a transaction corrdinator/manager wrapper ( Narayana or Atomikos) in order to be able participate in XA transactions managed by such XA transaction coordinators. That's the normal behavior and this is the behavior with IBM MQ connection factories and even with Apache ActiveMQ (pre-ARTEMIS).

It was a surprise when, in Artemis library, the same class implements both non XA and XA connection factory, because ActiveMQ in the past (pre-ARTEMIS) did it well (separate).

With the ARTEMIS mixture of XA and non XA connection factories, the post-proccessor cannot determine if it must wrap(or not) the connection factory with the NArayana (or Atomikos) wrapper. In our case all Artemis connectionfactories get XA-wrapped and this is definitely wrong. To wrap a non XA connection factory with a XA-wrapper I think we can agree is wrong.

We thought that we must not look for ugly workaroundd but to raise this concern as it seems a design choice that hurts this kind of integration. I repeat in ActiveMQ library (pre-ARTEMIS) it was working ok, separated ones.

 

I hope I clarified the case, I think it's pretty common (Spring Boot 3.x use).

 

If you need further clarification please let me know.

 


was (Author: juliojgd):
Sure [~jbertram] ,  we use Spring Framework with Spring Boot.

When a connection factory supports XA transactionality (XAConnectionFactory) and its created as a bean in the Spring Context a Bean PostProcessor takes all of them and, ONLY IF it implements XAConnectionFactory the object it's wrapped by a transaction corrdinator/manager wrapper ( Narayana or Atomikos) in order to be able participate in XA transactions managed by such XA transaction coordinators. That's the normal behavior and this is the behavior with IBM MQ connection factories and even with Apache ActiveMQ (pre-ARTEMIS).

It was a surprise when, in Artemis library, the same class implements both non XA and XA connection factory, because ActiveMQ in the past (pre-ARTEMIS) did it well (separate).

With the ARTEMIS mixture of XA and non XA connection factoies, the post-proccessor cannot determine if it must wrap(or not) the connection factory with the NArayana (or Atomikos) wrapper. In our case all Artemis connectionfactories get XA-wrapped and this is definitely wrong. To wrap a non XA connection factory with a XA-wrapper I think we can agree is wrong.

We thought that we must not look for ugly workaround but to raise this concerna as it seems a design choice that hurts this kind of integration. I repeat in ActiveMQ library (pre-ARTEMIS) it was working ok, separated ones.

 

I hope I clarified the case, I think it's pretty common (Spring Boot 3.x use).

 

If you need further clarification please let me know.

 

> Unable to differentiate between XA and non XA connection factories
> ------------------------------------------------------------------
>
>                 Key: ARTEMIS-4180
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-4180
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.26.0
>            Reporter: Julio J. Gomez Diaz
>            Priority: Major
>
> Using the ActiveMQ Artemis library ([https://github.com/apache/activemq-artemis)] we've detected that the org/apache/activemq/artemis/jms/client/ActiveMQConnectionFactory.java implements also the XAConnectionFactory, and org/apache/activemq/artemis/jms/client/ActiveMQXAConnectionFactory extends this, it seems rare that definition, the NON-XA Connection Factory implementation should implement only the ordinary {{jakarta.jms.ConnectionFactory}} and the XA Connection Factory should implement the {{jakarta.jms.XAConnectionFactory}}, this way we can be distinguished without problems if the Connection Factory is XA or not. This solution is what we are been working so far in another JMS-enabled brokers, and the exception is ActiveMQ Artemis. Apache ActiveMQ (pre-Artemis) follow this pattern (separation of XA and non XA).
> Why is it necessary the org/apache/activemq/artemis/jms/client/ActiveMQConnectionFactory implements also the {{jakarta.jms.XAConnectionFactory}}? Can this be changed? (Separated)
> We think this would be a great improvement for the sake of implementation ease.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)