11.1 Transaction Concepts

A transaction can be described as a unit of work that is comprised of several different operations acting on one or more shared system resources and has a predictable outcome. Additionally, this unit of work needs to be governed by ACID properties. The acronym ACID ^[1] stands for Atomic, Consistent, Isolated, and Durable. These four classical characteristics essentially define the concept of a transaction:

^[1] Andreas Reuter, Transaction Processing: Concepts and Techniques (ISBN 1-55860-190-2) Morgan Kauffman.

• Atomic: The unit of work is atomic in that it is either performed in its entirety or not performed at all. This "all or nothing" properly ensures that in case of failure, changes that occur due to the unit of work are either made permanent (committed) or reversed (rolled back) to restore the original state.

• Consistent: Consistency requires that after the execution of the unit of work, the system is in a stable state. If there is any inconsistency, then the work done must be reversed to restore the original state. For example, the referential integrity of the data must be maintained upon completion.

• Isolated: The notion of isolation is simple; a transaction should execute as though it is running by itself, meaning that the correctness of the unit of work performed in a transaction should not be compromised when another concurrent transaction accesses the same set of resources.

• Durable: The changes made by the unit of work constituting the transaction should be permanent and should not be lost because of system failure.

From a design perspective, a transaction usually represents a level of abstraction in the context of a business operation. A transaction consists of business operations that have application semantics and a scope greater than a method invocation or database operation. For example, suppose that the transaction consists of an account withdrawal and an account deposit; the application code to realize this may consist of multiple databases and classes. However, the overall transaction is still governed by the ACID properties, which require that all the work done in the transaction be completed as one entity, or in the case of failure, no work is done at all, with data integrity being maintained in both cases. This all-or-nothing flat transaction model is characterized with the states shown in Figure 11-1. The transaction is begun and goes into an active state where some work is done. If the work was successfully performed, the transaction is committed and the resources accessed in that transaction are updated with the results of that work. If something goes wrong, the transaction is rolled back and the resources are restored to their initial state.

Figure 11-1. State transitions in a transaction.

Nested Transaction Model Not Supported

The nested transaction model allowing transactions to be nested inside each other is not supported by J2EE or JDO.

11.1.1 Parties involved

In any transactional system, the following multiple parties work in unison for the model to work smoothly:

• Transactional object: This object initiates or demarcates a transaction. It can be any user application or in an application server environment J2EE component like EJBs. In the case of EJBs using container-managed transactions, the application server may initiate and end the transaction; however, it still does that on behalf of the EJB.

• Transaction manager: This is the implementation of a transaction service and is responsible for coordinating and managing the transactions.

• Resource adapter: This is the system-level software "driver" that application code uses to connect to the underlying resources, e.g., JDBC drivers, JMS providers.

• Resource manager: This manages a set of resources. A transactional resource manager can participate in transactions that are externally controlled and coordinated by a transaction manager. A resource manager is typically in a different address space or on a different machine from the resource adapters and clients that accesses it, e.g., a database system, a mainframe transaction processing system, and so on.

• Resource: This is the actual underlying resource, e.g., a database instance.

Depending on the shared resources being accessed by the transactional object, the transaction can be characterized as a local or distributed transaction.

11.1.2 Local transactions

A transaction that involves a single resource manager is known as a local transaction. In local transactions, the transaction manager simply delegates management of the transaction to the underlying resource manager. For example, in an application server when a transaction object like a J2EE component interacts with a single database, the transaction manager creates a transaction object, associates it with the current thread, and invokes begin() , commit() , and rollback() on the underlying database connection.

11.1.3 Distributed transactions

A distributed transaction is a transaction that interacts with multiple and possibly heterogeneous resource managers in a coordinated manner. For example, a transaction manager needs to coordinate the transaction involving a database and a JMS queue in the same method execution to ensure that these resources work together coherently.

Distributed Transactions

From a JDO perspective, the concept of distributed transactions is important if the application attempts to use JDO-based persistence alongside application code that uses other persistence mechanisms.

11.1.4 Two-phase commit

In order to maintain the atomicity of a distributed transaction, the transaction managers use a standard two-level recovery mechanism known as a two-phase commit protocol (2PC). The two-phase commit protocol guarantees data integrity by ensuring that transactional updates are committed in all the participating resources, or are fully rolled back out of all the resources, reverting to the state prior to the start of the transaction. To understand how 2PC works, look at what happens in such a transaction:

1. The resources are enlisted with the transaction manager.

2. The transactional object initiates a transaction.

3. The transaction manager begins the transaction.

4. Application code updates resource A.

5. Application code updates resource B.

6. Application code requests a commit form the transaction manager.

7. The transaction manager executes the two-phase commit.

The transaction manager, as the name suggests, completes the transaction in two phases. A simplified view of the interaction is shown in Figure 11-2.

Figure 11-2. The two-phase commit execution.

Distributed Transaction Standards

The most widely accepted distributed transaction processing model is that specified by the Opengroup consortium in the XA specification. The XA specification defines the API in the form of an interface ”the XAInterface that serves as a contract between distributed transactional components . See http://www.opengroup.org/products/ publications /catalog/s423.htm.

• Phase 1: The transaction manager sends a prepare-to-commit request to the resource managers. The resource managers perform internal checks and store information about the requested updates in some durable storage (e.g., such as a disk). When the transaction manager receives acknowledgements from all the resource managers, it stores the information somewhere, such as in a file system.

• Phase 2: The transaction manager sends a commit message to all the resource managers. The resource managers perform the requested update on their end and send an acknowledgement of the execution back to the transaction manager. After the transaction manager receives all the acknowledgements, it informs the transactional object about the result of the transaction.

The transaction manager issues a rollback message to the resource managers if either of these conditions is true:

• Any of the resource managers is unable to prepare itself (e.g., locks could not be obtained) and returns a failure message in Phase 1.

• Any of the resource managers is unable to complete the task and returns a failure message in Phase 2.

The two-phase commit protocol in distributed transactions can sometimes give rise to fatal error conditions called heuristics that violate the atomic properties. A typical case called a heuristic rollback is as follows : In Phase 1, the transaction manager signals the resource to prepare itself within the context of a transaction. The acknowledgement from the resources is, in fact, a commitment that later on when the transaction manager signals a commit or rollback, it will be able to do either. However, sometimes it may break this promise ”for example, the transaction manager goes away and the resource is waiting in a prepared state tying up other locks. Even though the resource does not know the outcome of the transaction, it makes a preemptive decision, called a heuristic decision, based on some internal timer or other administrative command. Typically, this guess is to rollback the transaction, release internal locks, and return itself to a consistent state. If the sub sequently transaction manager returns with a request to do some work (e.g., commit) on the same transaction, the resource throws a heuristic exception.

These are other similar heuristic conditions:

• Heuristic commit: A resource preemptively decides to commit its part of a distributed transaction.

• Heuristic mixed: Due to one or more heuristic decisions, a transaction has different branches in conflicting states, some committed and some rolled back.

From a developer's perspective, any indication of a heuristic condition is a signal to examine the application deployment and architecture. Typical causes may include a lack of system resources on the database or resource manager and excessive consumption of resources (e.g., locks or memory) by a particular transaction.