The default Transaction Manager implementation.

## Package Specification

The classes in this package belong may be grouped into two:

- Application server interface. This group consists of the two classes {@link: TransactionPropagationContextFactory} and {@link: TransactionPropagationContextImporter}. Together these two classes form the JBoss-specific Communication Resource Manager (CRM).
- The default Transaction Service. This is the rest of the classes in this package. It is a very fast JTA implementation with two drawbacks:
  - It has no transactional logging or recovery after server crashes.
  - Transactions cannot be propagated from one server VM to another. But the thin-client UserTransaction service works fine, in case you just want to control transactions on a single server from your stand-alone clients.

## The JBoss-specific Communication Resource Manager

A CRM is responsible for converting local transactions from/to a form that can be serialized so it can be passed over the wire to another Java VM.

The JTA specification does not define the CRM, so we have implemented our own.

The J2EE specification suggests that the CRM used is the OTS CosTSPortability CRM, but that depends heavily on CORBA, and JBoss is not dependent on any particular object request broker technology, so we do not use that.

The advantage of using our own CRM implementation instead of CosTSPortablilty is twofold:

- JBoss does not depend on CORBA, and will run just fine without it.
- JBoss is able to use JTA implementations that are completely incompatible with OTS.

## Adapting an existing JTA implementation for JBoss

In JBoss everything is a MBean. Implementing your JTA implementation as an MBean makes it simpler to manage it in a standardized way.

Since your JTA implementation is a service you probably want to make your MBean implemementation extend from `org.jboss.system.ServiceMBeanSupport`. When running in the server, your MBean should publish three objects in JNDI:

- java:/TransactionManager When this JNDI name is looked up, it should return an object instance that implements `javax.transaction.TransactionManager`. This is the standard JTA transaction manager that the JBoss server uses to control transactions.
- java:/TransactionPropagationContextImporter When this JNDI name is looked up, it should return an object instance that implements `org.jboss.tm.TransactionPropagationContextImporter`. This is used by the JBoss communication layers to convert the wire representation of a transaction to a `javax.transaction.Transaction` instance that can be used locally.
- java:/TransactionPropagationContextFactory When this JNDI name is looked up, it should return an object instance that implements `org.jboss.tm.TransactionPropagationContextFactory`. This is used by the JBoss communication layers to convert the wire representation of a `javax.transaction.Transaction` instance to a form that can be passed over the wire to another JBoss server.

See the implementation of `org.jboss.tm.TransactionManagerService` for an example of such a MBean. Please note that the three names your MBean should publish in JNDI need not refer to the same object instance as the `TransactionManagerService` does.

Please note that the transaction propagation context (TPC) used by the CRM interfaces `TransactionPropagationContextImporter` and `TransactionPropagationContextFactory` is of type `java.lang.Object`. This allows for the widest range of possible TPC implementations. For your TPC to work with the JBoss JRMP transport, it should be Java-serializable at runtime.

## Related Documentation

- The JTA specification
- The OTS specification

## Package Status

- STABLE