J2EE Transaction Frameworks: Distributed Transaction Primer

In the first part of this series, we covered the basics of transaction processing in a distributed component based system. In this part, the two main types of transactions possible in a J2EE configuration are described. Issues of isolation and serialization of resource managers are discussed. Explicit transaction management using JTA API for the three typical J2EE configurations is described in detail.

Transactions in J2EE configurations

In Part 1 of this series we ended the discussion identifying the three common J2EE configurations found in applications. For the benefit of the reader, the figure showing those configurations is repeated below.

• Case I: Stand-alone Client <-> EJB Container <-> RDBMS/EIS Resources
• Case II: Browser <-> Web Container <-> RDBMS/EIS Resources
• Case III: Browser <-> Web Container <-> EJB Container <-> RDBMS/EIS Resources

This part will explain how the different types of transaction types map to the cases mentioned above.

J2EE transaction types

The typical configuration of a J2EE application is an application component deployed in a container provided by an application server. The application component needs transactional access to multiple resource managers and uses a transaction manager that's responsibile for managing transactions across multiple resource managers.

A resource manager as shown in the figure above can support two types of transactions:

• JTA/XA Transaction: The transaction manager that controls and coordinates the transaction is external to the resource manager. Such a transaction is henceforth referred to as a JTA or an XA transaction.
• RM/Local Transaction: The transaction manager that controls and coordinates the transaction is internal to the resource manager The coordination of such transactions involves no external transaction managers. This means the Transaction Manager component shown in the figure above is part of the Resource Manager.

A transaction manager as shown above (1) coordinates transactions across multiple resource managers and (2) provides additional low level services to propagate transactional context across multiple resource managers. The J2EE connector architecture defines a transaction management contract between an application server and a resource adapter with its underlying resource manager. The transaction management contract has two parts, depending on the type of transaction:

• a JTA javax.transaction.xa.XAResource based contract between a transaction manager and a resource manager
• a local transaction management contract

An application server vendor uses this to provide the infrastructure and runtime environment for transaction management. Application components in turn rely on this transaction infrastructure to support their component level transaction model.

Note: It is important to emphasize that most enterprise information systems support some form of transaction management. For example, a typical JDBC database allows multiple SQL updates to be grouped in an atomic transaction. Components should always access any resource (database or an enterprise information system) under the scope of a transaction since this provides some guarantee on the integrity and consistency of underlying data being accessed. Such systems can be accessed under either a JTA transaction or a resource manager (RM) local transaction.

In the following figure, a client invokes a method on the remote interface of an EJB A. EJB A accesses resources managed by an EIS A and calls EJB Y to access another EIS B.

The application server uses a transaction manager to enable an application component to perform transactional access across multiple EIS resource managers. The transaction manager manages transactions across multiple resource managers and supports propagation of the transaction context across distributed systems. The transaction manager supports a JTA XAResource transaction management contract with a resource manager. The EIS system A supports JTA transactions by implementing a XAResource interface through its resource manager. The EIS system B also implements the XAResource interface. This interface enables the two resource managers to participate in transactions that are coordinated by an external transaction manager. The XAResource interface is used by the transaction manager to manage transactions across the two underlying resource managers. As the EJBs A and B access the EIS systems, the application server enlists the connections to both the systems from their respective resource managers. Finally when the transaction commits, the transaction manager performs a 2PC protocol across the two resource managers, ensuring that all read and write access to resources managed by both the EIS systems is either entirely committed or entirely rolled back.

Currently, the J2EE platform is only required to support access to a single JDBC database within a transaction (multiple connections to the same database are allowed). It is not required to support access to multiple JDBC databases within a single transaction. It is also not required to support access to other types of enterprise information systems such as enterprise resource planning systems. However, some products might choose to provide these extra transactional capabilities. For example, the J2EE SDK supports access to multiple JDBC databases in one transaction using the two-phase commit protocol. It is important for developers to understand and distinguish which transaction capabilities are required and which are optional in a J2EE product. For true portability of an application, only features required by the J2EE specification should be used. For example, if a J2EE application needs to access multiple databases under a single transaction, it will not run properly on a J2EE product that does not support two-phase commit.

The figure shown above illustrates the different types of transaction management and their associated components. It is meant to clarify the relationships between JTA transaction, the EJBs and their bean managed or container managed demarcation. Note that it is always possible to do explicit local transactions from fat clients, servlets or EJBs provided the resource manager offers some transactional API.