8.2 J2EE Platform Transactions

Enterprise applications require safe, reliable, recoverable data access, so support for transactions is an essential element of the J2EE architecture. The J2EE platform supports a combination of servlets and JSP pages accessing multiple enterprise beans within a single transaction. Each component may acquire multiple connections to multiple resource managers.

The J2EE platform supports both programmatic and declarative transaction demarcation. The component provider can programmatically demarcate transaction boundaries in the component code with the Java Transaction API. Enterprise beans support declarative transaction demarcation, in which the enterprise bean container automatically starts and completes transactions based on configuration information in the components' deployment descriptor. In both cases, the J2EE platform assumes the burden of implementing transaction management.

J2EE transaction management is transparent to component and application code. A J2EE application server implements the necessary low-level transaction protocols, such as interactions between a transaction manager and resource managers, transaction context propagation, and distributed two-phase commit protocol. The J2EE platform requires only support for so-called "flat" transactions, which cannot have any child (nested) transactions.

An application can perform distributed transactions because a transaction manager propagates the transaction context across multiple resource managers. Transaction managers can also cooperate to propagate transaction context across J2EE server boundaries. Consider a large retail store chain. The transaction manager for a store's application server may also interoperate with the transaction managers for other stores within the same enterprise, permitting customers to pay for an item at one location and have it delivered from another. Such transactional capabilities pave the way for a high level of integration across the enterprise.

The next few sections provide examples of these transactional scenarios, which involve multiple distributed transaction participants.

8.2.1 Accessing Multiple Resources within a Transaction

As of version 1.3 of the J2EE platform, a J2EE product is required to support access within a single transaction to:

• A single JDBC database (multiple connections to the same database are allowed)
• A single Java Message Service (JMS) provider, and
• Multiple Enterprise Information Systems (EISs) through resource adapters (Connectors) specifying the XATransaction transaction level

Please refer to Section 8.8 on page 273 for more on these three types of resource managers.

Access to multiple JDBC databases within a single transaction is not required by J2EE version 1.3, and neither is support for multiple JMS providers within a transaction. Some product providers may add value to their product line by including these extra, non-standard transactional capabilities. For example, the J2EE reference implementation supports access to multiple JDBC databases in one transaction through XA-capable JDBC drivers.

The following scenario illustrates a J2EE transaction that spans multiple resource managers. In Figure 8.2, a client invokes a method on enterprise bean X. Bean X accesses database A using a JDBC connection. Then enterprise bean X calls a method on another enterprise bean Y, which sends a JMS message to some other system using a JMS provider. Enterprise bean Y then invokes a method on enterprise bean Z, which updates and returns some data from an external EIS system using a resource adapter that implements the J2EE Connector architecture. The transaction manager in the J2EE server coordinates activities with the three resource managers. The server ensures that the database update by bean X, the message transmission by bean Y, and the EIS operation performed by bean Z are either all committed, or all rolled back.

Figure 8.2 A Database, a JMS Provider, and an EIS within a Single Transaction

An application component provider does not have to write extra code to ensure consistent transactional behavior. Enterprise beans X, Y, and Z access their resources using the JDBC API, JMS, and the J2EE Connector architecture, respectively. Behind the scenes, the J2EE server's transaction manager enlists the connections to all three systems as part of the transaction. When the transaction commits, the J2EE server and the resource managers perform a two-phase commit to ensure atomic update of the two systems.

8.2.2 Transactions across Servers

J2EE products can distribute transactions across multiple application servers.

In Figure 8.3, a client invokes enterprise bean X, which updates data in enterprise information system A, and then calls another enterprise bean Y that is hosted by a different J2EE server. Enterprise bean Y performs read-write access to enterprise information system B.

Figure 8.3 A Transaction Can Span Multiple J2EE Servers

When X invokes Y, the two J2EE servers cooperate to propagate the transaction context from X to Y. This transaction context propagation is transparent to the application code. At transaction commit time, the two J2EE servers use a distributed two-phase commit protocol to ensure that the two enterprise information systems are updated within a single transaction.