JTA : Java Transaction API

Introduction

The Java™ Transaction API (JTA) allows applications to perform distributed transactions; that is, transactions that access and update data on two or more networked computer resources. 

To demarcate a JTA transaction, you invoke the begin, commit, and rollback methods of the javax.transaction.UserTransactioninterface.

Distributed Transaction

A distributed transaction is simply a transaction that accesses and updates data on two or more networked resources, and therefore must be coordinated among those resources.

The distributed transaction processing (DTP) model defines several components:
* The application
* The application server
* The transaction manager
* The resource adapter
* The resource manager

The Resource Manager

The resource manager is generally a relational database management system (RDBMS), such as Oracle or SQL Server. All of the actual database management is handled by this component.

The Resource Adapter

The resource adapter is the component that is the communications channel, or request translator, between the "outside world," in this case the application, and the resource manager. In Java Context, this is a JDBC driver.

The Application Server

Application servers handle the bulk of application operations and take some of the load off of the end-user application. Application server adds another process tier to the transaction.

The first step of the distributed transaction process is for the application to send a request for the transaction to the transaction manager.

Transaction Manager

The transaction manager is responsible for making the final decision either to commit or rollback any distributed transaction. A commit decision should lead to a successful transaction; rollback leaves the data in the database unaltered. JTA specifies standard Java interfaces between the transaction manager and the other components in a distributed transaction: the application, the application server, and the resource managers.

Most enterprises use transaction managers and application servers because they manage distributed transactions much more efficiently than an application can.

Transaction Branch

Although the final commit/rollback decision treats the transaction as a single logical unit, there can be many transaction branches involved. A transaction branch is associated with a request to each resource manager involved in the distributed transaction.

Requests to three different RDBMSs, therefore, require three transaction branches. Each transaction branch must be committed or rolled back by the local resource manager.

This relationship is illustrated in the following diagram:

The numbered boxes around the transaction manager correspond to the three interface portions of JTA:

 1—UserTransaction—The javax.transaction.UserTransaction interface provides the application the ability to control transaction boundaries pro grammatically. The javax.transaction.UserTransaction method starts a global transaction and associates the transaction with the calling thread.

2—Transaction Manager—The javax.transaction.TransactionManager interface allows the application server to control transaction boundaries on behalf of the application being managed.

3—XAResource—The javax.transaction.xa.XAResource interface is a Java mapping of the industry standard XA interface based on the X/Open CAE Specification (Distributed Transaction Processing: The XA Specification).

Notice that a critical link is support of the XAResource interface by the JDBC driver. The JDBC driver must support both normal JDBC interactions, through the application and/or the application server, as well as the XAResource portion of JTA. DataDirect Connect for JDBC drivers provide this support.

Two-Phase Commit Protocol

The transaction manager controls the boundaries of the transaction and is responsible for the final decision as to whether or not the total transaction should commit or rollback. This decision is made in two phases, called the Two-Phase Commit Protocol.

In the first phase, the transaction manager polls all of the resource managers (RDBMSs) involved in the distributed transaction to see if each one is ready to commit. If a resource manager cannot commit, it responds negatively and rolls back its particular part of the transaction so that data is not altered.

In the second phase, the transaction manager determines if any of the resource managers have responded negatively, and, if so, rolls back the whole transaction. If there are no negative responses, the translation manager commits the whole transaction, and returns the results to the application.

 

Serializability

An important concept to understanding isolation through transactions is serializability. Transactions are serializable when the effect on the database is the same whether the transactions are executed in serial order or in an interleaved fashion.

Degrees of isolation (degrees of Consistency)

Degrees of isolation:

degree 0 - a transaction does not overwrite data updated by another user or process ("dirty data") of other transactions

degree 1 - degree 0 plus a transaction does not commit any writes until it completes all its writes (until the end of transaction)

degree 2 - degree 1 plus a transaction does not read dirty data from other transactions

degree 3 - degree 2 plus other transactions do not dirty data read by a transaction before the transaction commits

Returning without committing

In a stateless session bean with bean-managed transactions, a business method must commit or roll back a transaction before returning. However, a stateful session bean does not have this restriction.

In a stateful session bean with a JTA transaction, the association between the bean instance and the transaction is retained across multiple client calls. Even if each business method called by the client opens and closes the database connection, the association is retained until the instance completes the transaction.
In a stateful session bean with a JDBC transaction, the JDBC connection retains the association between the bean instance and the transaction across multiple calls. If the connection is closed, the association is not retained.

Methods not allowed in Bean-Managed Transactions

Do not invoke the getRollbackOnly and setRollbackOnly methods of the EJBContext interface in bean-managed transactions. These methods should be used only in container-managed transactions. For bean-managed transactions, invoke the getStatus and rollbackmethods of the UserTransaction interface.