Aries XA Transaction Control implementation
The Aries XA Transaction control implementation is available at the following maven coordinates:
It is based on the JTA transaction manager provided by Apache Geronimo.
Using the Transaction Control Service
For the basics of using the Transaction Control Service see the Quick Start Documentation
As per the Transaction Control specification the Aries XA implementation registers a
TransactionControl service in the OSGi Service Registry.
The Aries XA Transaction Control implementation is able to support the use of both XA
and Local Resources within the same transaction. The service is therefore registered
properties set to
The XA transactions created by the XA Transaction Control implementation are not configured
to create a transaction log. Therefore the XA Transactions are not recoverable in the event of failure.
This may change in the future if transaction log support is added to the implementation.
The primary difference between XA and Local Transactions is that XA transactions are atomic across multiple resources. In particular, if two
resources. This means that all resources in the transaction will be committed or rolled back together.
XA transactions are therefore best suited to scenarios where multiple resources are
accessed within the transaction, particularly if consistency between the resources is important.
Working with XA transactions
The XA Transaction Control Service supports participants in ongoing transactions via the
Lifecycle callbacks can be registered against the current scope using the
Local Resources and the Last Participant Gambit
In addition to supporting XA resources the XA Aries Transaction Control implementation also supports
Local Resources which can be added using the
When local resources are added to the XA transaction they are processed in a special way. When
the two-phase commit is preparing resources it first prepares all of the registered
then the Local resources are committed or rolled back as appropriate, then the XAResources are completed.
This is known as the Last Resource Gambit.
The value of the Last Resource Gambit is highest when there is exactly one Local resource in the transaction.
In this case the Local resource is effectively doing a prepare and commit/rollback in one step, but as all of the
other resources have been prepared already there is almost no risk of inconsistency across the resources.
As the number of Local Resources involved in the transaction rises the risk of inconsistency becomes much
greater. It is therefore recommended that XA transactions contain zero or one Local resources, although
any number may be registered.