Java Transaction Service
Subbu Allamaraju
Introduction
Transaction management is one of the most crucial requirements for enterprise application development. Given the complexity of today's business requirements, transaction processing occupies one of the most complex segments of enterprise level distributed applications to build, deploy and maintain.
By definition, a transaction is a unit of work done by multiple distributed components on shared data, with the following properties:
- ATOMICITY: A transaction should be done or undone completely and unambiguously. In the event of a failure of any operation, effects of all operations that make up the transaction should be undone, and data should be rolled back to its previous state.
- CONSISTENCY: A transaction should preserve all the invariant properties (such as integrity constraints) defined on the data. On completion of a successful transaction, the data should be in a consistent state. In other words, a transaction should transform the system from one consistent state to another consistent state. For example, in the case of relational databases, a consistent transaction should preserve all the integrity constraints defined on the data.
- ISOLATION: Each transaction should appear to execute independently of other transactions that may be executing concurrently in the same environment. The effect of executing a set of transactions serially should be the same as that of running them concurrently.
- DURABILITY: The effects of a completed transaction should always be persistent.
These properties, called as ACID properties, guarantee that a transaction is never incomplete, the data is never inconsistent, concurrent transactions are independent, and the effects of a transaction are persistent.
A typical transaction processing architecture includes a transaction manager to implement transactions and preserve the ACID properties of transactions with the help of resource managers. A resource manager is a component that manages persistent and stable data storage systems. The transaction manager implements a protocol known as the two phase commit protocol to preserve the ACID properties. Please refer to Nuts and Bolts of Transaction Processing for a review of various transaction processing concepts and related standards and technologies.
Background
In the distributed transaction management domain, X/Open Distributed Transaction Processing (DTP) model is the most widely adopted model for building transactional applications. Almost all vendors developing products related to transaction processing, relational databases, and message queuing, support the interfaces defined in the DTP model.
This model defines three components: application programs, resource managers, and a transaction manager. This model also specifies functional interfaces between application programs and the transaction manager (known as the TX interface), and between the transaction manager and the resource managers (the XA interface). With products complying to these interfaces, one can implement transactions with the two phase commit and recovery protocol to preserve atomicity of transactions.
Object Transaction Service (OTS) is another distributed transaction processing model specified by the Object Management Group (OMG). This model is based on the X/Open DTP model, and replaces the functional TX and XA interfaces with CORBA IDL interfaces. In this model, the various objects communicate via CORBA method calls over IIOP. Yet, the OTS model is interoperable with the X/Open DTP model. An application using transactional objects could use the TX interface with the transaction manager for transaction demarcation.
As a part of the enterprise Java initiative, Sun Microsystems Inc. proposed the Java Transaction Service and the Java Transaction API in early 1999. Of these, the JTS is still in a draft form (as of May 1999, at version 0.95).
This paper reviews the Java Transaction Service and the Java Transaction API specifications and discusses the underlying architecture. It also discusses various usage scenarios.
Java Transaction Service - Architecture
The Java transaction initiative consists of two specifications: Java Transaction Service (JTS) and Java Transaction API (JTA).
Figure 1: Java Transaction InitiativeJTS specifies the implementation of a Java transaction manager. This transaction manager supports the JTA, using which application servers can be built to support transactional Java applications. Internally the JTS implements the Java mapping of the OMG OTS 1.1 specifications. The Java mapping is specified in two packages: org.omg.CosTransact
ions and org.omg.CosTSPortability .The JTA specifies an architecture for building transactional application servers and defines a set of interfaces for various components of this architecture. The components are: the application, resource managers, and the application server, as shown in Figure 1.
The JTS thus provides a new architecture for transactional application servers and applications, while complying to the OMG OTS 1.1 interfaces internally. This allows the JTA compliant applications to interoperate with other OTS 1.1 complaint applications through the standard IIOP.
As shown in Figure 1, in the Java transaction model, the Java application components can conduct transactional operations on JTA compliant resources via the JTS. The JTS acts as a layer over the OTS. The applications can therefore initiate global transactions to include other OTS transaction managers, or participate in global transactions initiated by other OTS compliant transaction managers.
The Java Transaction Service is architected around an application server and a transaction manager. The architecture is shown in Figure 2.
Figure 2: JTS ArchitectureThe JTS architecture consists of the following components:
- Transaction Manager: The transaction manager is the core component of this architecture and is provided by an implementation of the JTS. It provides interfaces to create transactions (including transaction demarcation and propagation of transaction context), allows enlistment and delistment of resources, provides interfaces for registering components for application synchronization, implements the synchronization protocol, and initiates and directs the two phase commit and recovery protocol with the resource managers.
- Application Server: One of the key features of the JTS architecture is that it allows an application server to be built on top of the transaction service and the resources. Application developers can develop and deploy application components onto the application server for initiating and managing transactions. The application server can therefore abstract all transactional semantics from the application programs.
- Application Components: These are the clients for the transactional resources and implement business transactions. These are deployed on the application server. Depending on the architecture of the application server, these components can directly or indirectly create transactions and operate on the transactional resources. For example, an Enterprise JavaBean (EJB) server allows declarative transaction demarcation, in which case, the EJB components need not directly implement the transactions. However, a Java implementation of a CORBA OTS, requires the CORBA object to demarcate transactions explicitly.
- Resource Manager: A resource manager is an X/Open XA compliant component that manages a persistent and stable storage system, and participates in the two phase commit and recovery protocol with the transaction manager. The application manager also provides interfaces for the application server and the application components to operate on the data managed by it.
- Communication Resource Manager: This allows the transaction manager to participate in transactions initiated by other transaction managers. However, the JTS specification does not specify any protocol for this communication and assumes that an implementation of the communication resource manager supports the CORBA OTS and GIOP specifications.
Java Transaction API
The JTA specification may be classified into three categories of interface as shown in Figure 3. In a JTS implementation, these are provided by the transaction manager, resource manager and the application components respectively.
Figure 3: JTA InterfacesTransaction Manager Interfaces
- javax.transaction.
Status : Defines the following flags for the status of a transaction:
Flag Purpose STATUS_ACTIVE Transaction is active (started but not prepared). STATUS_COMMITTED Transaction is committed. STATUS_COMMITTING Transaction is in the process of committing. STATUS_MARKED_ ROLLBACK Transaction is marked for rollback. STATUS_NO_TRANSACTI ON There is no transaction associated with the current Transaction, UserTransaction or TransactionManager objects. STATUS_PREPARED Voting phase of the two phase commit is over and the transaction is prepared. STATUS_PREPARING Transaction is in the process of preparing. STATUS_ROLLEDBACK Outcome of the transaction has been determined as rollback. It is likely that heuristics exists. STATUS_ROLLING_ BACK Transaction is in the process of rolling back. STATUS_UNKNOWN A transaction exists but its current status can not be determined. This is a transient condition Table 1: Transaction Status Flags
The javax.transaction.Transaction , javax.transaction.TransactionManag , and javax.transaction.er UserTransaction interfaces provide a getStatus method that returns one of the above status flags.- javax.transaction.
Transaction : An object of this type is created for each global transaction. This interface provides methods for transaction completion(commit and rollback), resource enlistment (enlistResource) and delistment (delistResource), registration of synchronization objects (registerSynchronization ), and query of status of the transaction (getStatus).- javax.transaction.
TransactionManag : This interface is implemented by the JTS and allows an application server to communicate with the transaction manager to demarcate transactions (begin, commit, rollback, suspend and resume), set the transaction for rollback (setRollbackOnly), get the associated Transaction object (getTransaction), set the transaction timeout interval (setTransactionTimeoer ut ) and query the status of the transaction (getStatus).- javax.transaction.
UserTransaction : This interface allows application components to manage transaction boundaries explicitly. This interface provides methods to begin and end transactions (begin, commit, and rollback), set the transaction for rollback (setRollbackOnly), set the transaction timeout interval (setTransactionTimeout ), and get the status of the transaction (getStatus). The application server should provide an interface to create an object of this type.- javax.transaction.
xa.Xid : This interface is a Java mapping of the X/Open transaction identifier xid structure. The transaction manager uses an object of this type to associate a resource manager with a transaction.Resource Manager Interfaces
- javax.transaction.
xa.XAResource : This is a Java mapping of the X/Open XA interface, and is implemented by resource managers operating with the JTS. This interface provides methods to start (start) and end (end) work on behalf of a specified transaction, to prepare a transaction with the current resource (prepare), to end transactions with the current resource (commit, forget, recover, and rollback), to compare the current resource manager with another resource manager (isSameRM), and to get and set the transaction timeout (getTransactionTimeout , setTransactionTimeout ).Application Interfaces
The only interface that an application object could implement is the Synchronization interface. The application components may have to implement whatever other interfaces are mandated by a given application server.
- javax.transaction.
Synchronization : An object intended to participate in a synchronization protocol with the transaction manager should implement this interface. This mechanism is based on the Observer pattern. This interface has two methods - beforeCompletion and afterCompletion to be called before starting and after completing, respectively, the two phase commit operation.
Java Transaction API - Usage
This section describes the usage of the JTA for implementing various transaction semantics. The purpose of this section is to provide conceptual guidelines only.
Transaction Demarcation
Transaction demarcation enables work done by distributed components to be bound by a global transaction. The JTA specifies two approaches with which new global transactions can be initiated and demarcated.
- Programmatic Demarcation: The javax.transaction.
UserTransaction interface provides methods for application components to begin and end transactions programmatically. The underlying application server should provide a mechanism to obtain a reference to this object. The JTA specification requires that the application servers use the JNDI for storing references to UserTransaction objects and for lookup.The application component can then use this object to begin, commit and rollback transactions.
In this approach, association between the calling thread and the transaction, and transaction context propagation are handled transparently by the transaction manager.
Usage// Get a UserTransaction object
// Begin a transaction
userTransaction.begin();
// Transactional operations ...
// End the transaction
userTransaction.commit(); - Application Server Controlled Demarcation In this approach, the javax.transaction.
TransactionManag interface controls transaction demarcation on behalf of the application being managed. The transaction manager also maintains the transaction context and its association with the calling threads implicitly.er
Usage// Begin a transaction
Transaction t = TransactionManager.begin();
// Transactional operations ...
// End the transaction
TransactionManager.commit(); Transaction Context
Transaction context is an association between the transactional operations on the resources, and the objects invoking these operations. During the course of a transaction, the transaction context is shared by all objects participating in the transaction. Thus, the transaction context logically envelopes all the operations performed on transactional resources during the course of a transaction.
The javax.transaction.
Transaction object encapsulates the transaction context information. This object can be used to perform transaction specific operations irrespective of the calling thread's transaction context.In JTS, the transaction context propagation is managed by the underlying implementation of the transaction manager.
Resource Enlistment and Delistment
Resource enlistment is the process by which resource managers are registered with the transaction manager for their participation in the transaction. This process enables the transaction manager to keep track of the all the resource managers participating in a transaction. The transaction manager uses this information to coordinate transactional work performed by the resource managers, and to drive the two phase commit and recovery protocol.
Using the javax.transaction.
Transaction interface, the application server can enlist and delist resource managers with the transaction manager.Usage
Resource enlistment is done by the application server when an application requests it for a connection to a transactional resource.
// ... an implementation of the application server
// Get a reference to the underlying TransactionManager object.
...
// Get the current Transaction object from the TransactionManager.
transaction = transactionManager.getTransaction( );
// Get an XAResource object from a transactional resource.
...
// Create a Transaction object.
...
// Enlist the resource
transaction.enlistResource( xaResource) ;
...
// Return the connection to the application.
..
Resource delistment is done similarly after the application closes connections to transactional resources.
Application Synchronization with a Transaction
Using the JTS synchronization protocol, certain objects can be registered with the transaction manager for notification before the start of and the completion of the two-phase commit process. This enables such application objects to synchronize transient state and data stored in persistent storage.
The javax.transaction.
Transaction interface provides a method to register javax.transaction.Synchronization objects with the transaction manager. The transaction manager then uses the synchronization protocol and calls the beforeCompletion and afterCompletion methods before and after the two phase commit process.Application objects can be registered for synchronization using the registerSynchroniza
tion method of the Transaction interface.Two Phase Commit
This protocol between the transaction manager and all the resources enlisted ensures that either all the resource managers commit the transaction, or they all abort.
The first phase of this protocol is the preparation phase, during which the transaction manager conducts a voting among all the resource managers registered for the target transaction. The transaction manager calls the prepare method on each resource manager, which will return a X_READONLY or XA_OK constant. The first value implies that the operations conducted on the target resource are read only, and there are no operations to be committed. The second value indicates that the resource manager is ready to commit the operations. In case the resource manager wants the transaction to be rolled back, it throws an appropriate XAException.
The second phase is a commit or recover phase. Depending on whether all resource managers are ready for a commit or not, one of these phases will be invoked by the transaction manager.
In case all the resource managers return a X_OK in the first phase, the transaction manager calls the commit method on each resource manager. Please note that the two phase protocol is not fool-proof, and the commit calls may throw appropriate XAException in return. In such a case, the transaction manager should initiate the recovery phase.
In case the voting determines a rollback, the transaction calls the recover on each prepared resource manager.
Conclusion
This article introduces the JTS and JTA, the architecture, and how some of the transaction processing semantics could be implemented in a JTS application environment.
The JTS and JTA are the latest entrants into the enterprise distributed computing arena. Although the JTS is a Java implementation of the OMG OTS 1.1 specification, the JTA retains the simplicity of the XA and TX functional interfaces of the X/Open DTP model.
At the time of writing this article, object transaction processing products complying to the JTS and JTA are yet to appear, although Integrated Transaction Service (from Inprise), JTSArjuna (from Arjuna Solutions Limited), and TPBroker (from Hitachi Software) implement the Java mapping (JTS) of the OTS 1.1 specification. However, the JTA is more relevant in the context of application servers such as EJB application servers. Currently EJB application servers compliant to entity beans implement the JTS and JTA interfaces.
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch format to Traditional
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
__,_._,___
No comments:
Post a Comment