Sun Microsystem Inc

Chapter 11 Support for Transactions

One of the key features of the Enterprise JavaBeans architecture is support for distributed transactions. The Enterprise JavaBeans architecture allows an application developer to write an application that atomically updates data in multiple databases which may be distributed across multiple sites. The sites may use EJB Servers from different vendors.

11.1 Overview

This section provides a brief overview of transactions and illustrates a number of transaction scenarios in EJB.

11.1.1 Transactions

Transactions are a proven technique for simplifying application programming. Transactions free the application programmer from dealing with the complex issues of failure recovery and multi-user programming. If the application programmer uses transactions, the programmer divides the application’s work into units called transactions. The transactional system ensures that a unit of work either fully completes, or the work is fully rolled back. Furthermore, transactions make it possible for the programmer to design the application as if it ran in an environment that executes units of work serially.

Sun Microsystems Inc.

Support for transactions is an essential component of the Enterprise JavaBeans architecture. The enterprise Bean Provider and the client application programmer are not exposed to the complexity of distributed transactions. The Bean Provider can choose between using programmatic transaction demarcation in the enterprise bean code (this style is called bean-managed transaction demarcation) or declarative transaction demarcation performed automatically by the EJB Container (this style is called con- tainer-managed transaction demarcation).

With bean-managed transaction demarcation, the enterprise bean code demarcates transactions using the javax.transaction.UserTransaction interface. All resource manager[10] accesses between the UserTransaction.begin and UserTransaction.commit calls are part of a transaction.

With container-managed transaction demarcation, the Container demarcates transactions per instructions provided by the Application Assembler in the deployment descriptor. These instructions, called transaction attributes, tell the container whether it should include the work performed by an enterprise bean method in a client’s transaction, run the enterprise bean method in a new transaction started by the Container, or run the method with “no transaction” (Refer to Subsection 11.6.3 for the description of the “no transaction” case).

Regardless whether an enterprise bean uses bean-managed or container-managed transaction demarcation, the burden of implementing transaction management is on the EJB Container and Server Provider. The EJB Container and Server implement the necessary low-level transaction protocols, such as the two-phase commit protocol between a transaction manager and a database system, transaction context propagation, and distributed two-phase commit.

11.1.2 Transaction model

The Enterprise JavaBeans architecture supports flat transactions. A flat transaction cannot have any child (nested) transactions.

Note: The decision not to support nested transactions allows vendors of existing transaction processing and database management systems to incorporate support for Enterprise JavaBeans. If these vendors provide support for nested transactions in the future, Enterprise JavaBeans may be enhanced to take advantage of nested transactions.

11.1.3 Relationship to JTA and JTS

The Java™ Transaction API (JTA) [5] is a specification of the interfaces between a transaction manager and the other parties involved in a distributed transaction processing system: the application programs, the resource managers, and the application server.

[10]The terms resource and resource manager used in this chapter refer to the resources declared in the enterprise bean’s deployment descriptor using the resource-ref element. These resources are considered to be “managed” by the Container.