Title: Aries Local 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 Local Transaction Control implementation

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

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

## 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 Local implementation registers a 
TransactionControl service in the OSGi Service Registry with the <code>osgi.local.enabled</code>
property set to <code>true</code>

## Local Transactions

Local transactions occur purely in-memory, and do not coordinate between resources. 

This means that Local Transactions are _not recoverable_ in the event of failure, and also
that Local Transactions are _not_ atomic across multiple resources. In particular, if two 
resources are accessed in a transaction (for example two different databases are modified)
then it is possible that one resource will be committed and the other rolled back.

Local transactions are therefore best suited to scenarios where only a single resource is
accessed within the transaction, or where consistency between resources is not important.

## Working with local transactions

The Local Transaction Control Service supports participants in ongoing transactions via the 
<code>registerLocalResource(LocalResource)</code> method. It does not support XA resources
and will throw an <code>IllegalStateException</code> if <code>registerXAResource(XAResource)</code>
is called.

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


  [1]: quickstart.html