Title: Aries XA Transaction Control implementation
Notice:    Licensed to the Apache Software Foundation (ASF) under one
           or more contributor license agreements.  See the NOTICE file
           distributed with this work for additional information
           regarding copyright ownership.  The ASF licenses this file
           to you under the Apache License, Version 2.0 (the
           "License"); you may not use this file except in compliance
           with the License.  You may obtain a copy of the License at
           .
             http://www.apache.org/licenses/LICENSE-2.0
           .
           Unless required by applicable law or agreed to in writing,
           software distributed under the License is distributed on an
           "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
           KIND, either express or implied.  See the License for the
           specific language governing permissions and limitations
           under the License.

#Aries XA Transaction Control implementation

The Aries XA Transaction control implementation is available at the following maven coordinates:

        <dependency>
            <groupId>org.apache.aries.tx-control</groupId>
            <artifactId>tx-control-service-xa</artifactId>
            <version>${aries.tx.control.version}</version>
        </dependency>

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][1]

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 
with the <code>osgi.local.enabled</code> _and_ <code>osgi.xa.enabled</code>
properties set to <code>true</code>.

## XA Transactions

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 
<code>registerXAResource(XAResource)</code> method. 

Lifecycle callbacks can be registered against the current scope using the 
<code>preCompletion(Runnable)</code> and <code>postCompletion(Consumer<TransactionStatus>)</code> 
methods.

##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 <code>registerLocalResource(LocalResource)</code> 
method.

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 <code>XAResources</code>, 
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.


  [1]: quickstart.html#TODO