org.jboss.tm

Overview

Package

Class

Tree

Deprecated

Index

Help

PREV PACKAGE NEXT PACKAGE

FRAMES NO FRAMES

Package org.jboss.tm

The default Transaction Manager implementation.

See:
Description

Interface Summary
JBossXATerminator (src)	Extends XATerminator to include registration calls
LastResource (src)	A tagging interface to identify an XAResource that does not support prepare and should be used in the last resource gambit.
TransactionLocalDelegate (src)	The interface to implementated for a transaction local implementation
TransactionPropagationContextFactory (src)	Implementations of this interface are used for getting a transaction propagation context at the client-side.
TransactionPropagationContextImporter (src)	Implementations of this interface are used for importing a transaction propagation context into the transaction manager.
TransactionTimeoutConfiguration (src)	The interface to implementated by a transaction manager that supports retrieving the current threads transaction timeout
XAExceptionFormatter (src)	XAExceptionFormatter.java Created: Tue Jan 28 12:07:56 2003

Class Summary
GlobalId (src)	This object encapsulates the global transaction ID of a transaction.
LocalId (src)	LocalId is a wrapper for a long value that identifies a transaction within a JBoss server.
TransactionImpl (src)	Our `Transaction` implementation.
TransactionLocal (src)	A TransactionLocal is similar to ThreadLocal except it is keyed on the Transactions.
TransactionLocalDelegateImpl (src)	An implementation of the transaction local implementation using Transaction synchronizations.
TransactionLocalDelegateImpl.TransactionLocalSynchronization (src)
TransactionManagerService (src)	This is a JMX service which manages the TransactionManager.
TransactionPropagationContextUtil (src)	Comment
TxManager (src)	Our TransactionManager implementation.
TxUtils (src)	TxUtils.java has utility methods for determining transaction status in various useful ways.
XidFactory (src)	XidFactory.java Created: Sat Jun 15 19:01:18 2002
XidImpl (src)	This object encapsulates the ID of a transaction.

Exception Summary
JBossRollbackException (src)	JBossRollbackException.java Created: Sun Feb 9 22:45:03 2003
JBossTransactionRolledbackException (src)	JBossTransactionRolledbackException.java Created: Sun Feb 9 22:45:03 2003
JBossTransactionRolledbackLocalException (src)	JBossTransactionRolledbackLocalException.java Created: Sun Feb 9 22:45:03 2003
JBossXAException (src)	Thrown to indicate a problem with a xaresource related operation.

Package org.jboss.tm Description

The default Transaction Manager implementation.

Package Specification

Application server interface. This group consists of the two classes and . 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.

Package Status

STABLE