How is the XA Enlistment Problem typically solved in a JEE environment

[cs224]

Hello,

I am trying to create a standalone application that runs outside of a JEE container and am wondering how the different standards like JTA, JNDI and JCA are playing together to solve what some people call the XA enlistment problem.

It seems that there exist some "Auto-Enlisting XA Wrapper" classes like the Narayana TransactionalDriver, the Apache Aries Auto-Enlisting XA Wrapper, the Bitronix ResourceBean, the WebSphere XADataSourceProxy, and others. But all of these solutions look like "one-off" solutions that work for a specific container / transaction manager environment. I was wondering if there is some standard that defines how auto enlisting should work in a transaction manager independent way?

The Spring JtaTransactionManager class has a method "public boolean supportsResourceAdapterManagedTransactions()" that is documented as: "Determine whether the underlying transaction manager supports XA transactions managed by a resource adapter (i.e. without explicit XA resource enlistment)."

This statement would at least indicate to me that there is some standard mechansim that operates without explicit XA resource enlistment.

I had a look at the narayana jca-and-hibernate quickstart that demonstrates how to integrate Narayana, IronJacamar, and Hibernate, because I was expecting that this auto enlistment should be part of the JCA mechanisms, but this quickstart is doing the enlistment manually, too.

Could somebody please point me to the relevant standard and documentation on how this mechanism is supposed to work?

Many thanks and best regards,

Christian

[tomjenkinson]

Hi Christian,

Unfortunately there isn't a standard for auto-enlistment of XAResources into a transaction.

One of the mechanisms that is used in WildFly is a UserTransactionListener:

jboss-transaction-spi/UserTransactionListener.java at master · jbosstm/jboss-transaction-spi · GitHub

Alternatively, you can wrap the driver and when (for example) JDBC::getConnection() is called it can detect whether or not a transaction is inflight and if so it can perform the necessary enlistment operations. This is approach that appears to be advocated in the Fuse docs you referenced.

Hope it helps,

Tom

[cs224]

I have now finally gotten around to read J2EE Connector Architecture and Enterprise Application Integration (12.3.1 Creating new Connections; page 206)and thought it might help others to document here what I've learned.

It seems that the JEE containers perform the "auto enlistment" in the call sequence:

javax.resource.cci.ConnectionFactory.getConnection() ->

javax.resource.spi.ConnectionManager.allocateConnection() ->

javax.resource.spi.ManagedConnectionFactory.createManagedConnection()

The ConnectionFactory and the ManagedConnectionFactory are under the control of the ResourceAdapter and the ConnectionManager may be under the control of the JEE container. The spi.ManagedConnectionFactory also serves as a factory for the cci.ConnectionFactory [Object createConnectionFactory(ConnectionManager cxManager)] and at that point takes the ConnectionManager as an argument. Like that the ConnectionManager can intercept the getConnection() calls and perform the "auto enlistment".

[jesper.pedersen]

JCA is cool that way

http://www.ironjacamar.org/doc/userguide/1.2/en-US/html/ch01.html#overview_outbound

http://www.ironjacamar.org/doc/userguide/1.2/en-US/html/ch08.html

You likely need a XATransaction capable resource adapter, and don't use CCI - it is horrible and broken. Feel free to join the IronJacamar community for additional pointers

[cs224]

Wow, there is a complete resource adapter code generator. I did not know that. Thanks for pointing me towards the documentation. I will have a look at it and join the IronJacamar community.