4 Replies Latest reply on Sep 11, 2014 9:43 AM by Christian Schuhegger

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

    Christian Schuhegger Newbie

      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