Java Transaction API
J2EE implements the DTP model using JTA, in which the transaction manager is represented by javax.transaction.UserTransaction. JTA enforces the transaction ACID properties between multiple resource managers. The JTA transaction manager is implemented by the EJB container vendor (application server vendor), and registered in the JNDI namespace. A client creates a distributed transaction context by looking up the JNDI namespace for the named resource UserTransaction, which acts as a factory of distributed transactions. The UserTransaction interface abstracts all the classes and interfaces of managing a J2EE distributed transactions. The application and component developer needs only to use the begin(), commit(), and rollback() methods of the UserTransaction context.
The begin() method explicitly starts a distributed transaction and associates the transaction with a calling thread. The transaction manager transparently (that is, behind the scenes) manages transactional access to any XA-compliant resource managers that the application uses. This clean isolation of responsibilities makes it easer to develop portable and complex enterprise applications.
Note
To start a distributed transaction, developers issue an explicit begin() method. This is somewhat different in a local transaction, where a transaction is implicitly started in the method setAutoMode(false) of a JDBC Connection, or createQueueSession(true) of a JMS Connection.
The following code demonstrates how the named resource UserTransaction is looked up in the default JNDI service, and a context is established for the transaction manager. Applications and components of the Web tier use this context to control the behavior of the distributed transaction. The body of the distributed transaction can be any code designed to access one or more resource manager.
Context ctx = new InitialContext();
UserTransaction utx =
(UserTransaction) ctx.lookup("java:comp/UserTransaction");
utx.begin();
// use multiple resources, such as databases (JDBC),
// messaging (JMS), and integrations (JCA)
utx.commit();
Note
The transaction manager interacts with the XA-compliant resource adapter transparently. Implicitly, it uses a transaction ID to identify each transaction thread of execution. Applications do not need to know about this transaction ID.
The previous code snippet demonstrates how to establish a UserTransaction context from a Web tier component (a JSP or a servlet). A UserTransaction context is established differently in the EJB tier, as explained later.
Three different types of resource manager are defined and supported by the J2EE architecture: JDBC-compliant databases, JCA adapters, and JMS providers. All three types of resource managers may be used within the scope of a single distributed transaction.
Note
We discuss only resource managers and resource adapters for JDBC and JMS. The JCA adapter and resource manager are beyond the scope of this book.
The main benefit of JTA is to combine multiple components and enterprise applications into a single distributed transaction with minor programming effort. Transactions are propagated automatically between multiple components and J2EE applications. As mentioned before, in a container-managed transaction, all demarcations are handled declaratively using the deployment descriptor. Bean-managed transactions use explicit demarcation in the bean's code.
Note
JTA can be used by an EJB to access a single resource. In this case, the JTA driver is intelligent enough to switch to local transaction mode, and uses the one-phase commit protocol.
There are many scenarios in which JTA can be used to access multiple resources in a single distributed transaction context. Here are the most commonly used scenarios in enterprise applications. Figure 16.3 illustrates these scenarios.
Scenario 1: A distributed transaction spans two EJBs: A and B. Each has its JDBC Connection to a DataSource. Each database instance has its own connection pool, which is defined separately in the JNDI service. The JTA transaction context propagates from EJB A to EJB B. This scenario is useful in updates of two databases simultaneously, as one unit of work.
Scenario 2: A distributed transaction spans two EJBs: A and B. The first has its JDBC Connection to a DataSource, whereas the second has its connection to a JMS provider. The JTA transaction context propagates from EJB A to EJB B. This scenario is useful in updating a database, while ensuring the delivery of a JMS message.
Scenario 3: Similar to Scenario 2, except that EJB A has access to two data sources; each has its connection pool. JTA transaction context propagates from EJB A to EJB B.
Scenario 4: The JTA transaction manager propagates the transaction context across the EJB container (application server) boundary to another J2EE-compliant container. These containers can be of the same vendor or of different vendors.
You see from these scenarios that the distributed transaction context is propagated from one component to another. You need to keep in mind that JTA is working behind the scenes through the EJB container to control transaction behavior.
Note
While a JMS resource manager is participating in a distributed transaction, the JTA driver will ignore a JMS transacted Session setting. This setting will be resumed after the distributed transaction is completed. Similarly, a local transaction setting of the JDBC resource manager will be ignored by the JTA driver during the course of the distributed transaction, and will resume its setting after the transaction is completed.
JTA Exception Handling
Few JTA exceptions are required to be handled while processing a distributed transaction. Table 16.2 summarizes JTA exceptions as part of the javax.transaction package.
| Exception | Description |
|---|---|
| RollbackException | Thrown to indicate that the transaction has been rolled back rather than committed. |
| HeuristicMixedException | Thrown to indicate that a heuristic decision was made and that some relevant updates have been committed, whereas others have been rolled back. |
| HeuristicRollbackException | Thrown to indicate that a heuristic decision was made and that some relevant updates have been rolled back. |
| SystemException | Thrown if the transaction manager encounters an unexpected error condition. |
Note
JTA transactions are automatically rolled back if a SystemException is thrown from a bean method. Transactions are not automatically rolled back, however, if an application exception is thrown.
Java Transaction Services
The Java Transaction Service (JTS) API is a Java binding of the CORBA Object Transaction Service (OTS) specification. JTS provides transaction interoperability using the standard IIOP protocol for transaction propagation between servers. The JTS API is intended for vendors who implement transaction-processing infrastructure for enterprise middleware. For example, an EJB Server vendor may use a JTS implementation as the underlying transaction manager.
EJB containers are not required to support the JTS interfaces; they are only required to support the JTA and the Java Connector APIs. The JTS interfaces are low-level APIs between a J2EE server and enterprise information system (EIS) resource managers, and they are not intended for the use by application developers.