Understanding Transaction Fundamentals

A transaction is a set of one or more SQL statements that are executed together as a unit of work, so either all the statements are executed or none of the statements are executed. In addition to grouping statements together for execution as a unit, a transaction becomes the fundamental unit of recovery, consistency, and concurrency in reliable J2EE applications.

One of the primary objectives of EJB architecture is to provide transaction services through the EJB container. This relieves the application programmer from dealing with the complex issues of failure recovery, concurrency, and multi-user programming. The transaction simplifies the task of building a sophisticated enterprise application, and it is the foundation for dealing with complex B2B (Business-to-Business) and B2C (Business-to-Consumer) applications.

The following two sections discuss transaction properties, and the transaction models used in transactional applications.

The ACID Properties

Enterprise transactions share certain characteristics, commonly known as ACID properties, which are important for data integrity and consistency:

• Atomic: All operations of the transaction must be performed successfully or not at all.

• Consistent: The transaction must transition the data from one consistent state to another, preserving the data's semantic and referential integrity. Access should not be allowed to inconsistent data.

• Isolated: Transactions may run concurrently, but any changes made to data by a transaction are invisible to other concurrent transactions until the transaction commits. Isolation requires that several concurrent transactions must be repeatable, (that is, they must produce the same results in the data as same transactions executed serially, and in any order).

• Durable: After the transaction is committed, the resultant data should be permanent. This implies that data for all committed transactions can be recovered after a system crash or media failure.

In summary, an ACID transaction ensures the consistency and integrity of the persistent data. It also assumes a stable set of inputs and working data, and that the data changes are recoverable after system failure.

Exploring the Transaction Models

Generally, a transaction model describes the main entities that constitute a transaction, and defines when a transaction starts, when it succeeds, and what to do in case of failure. A transaction consists of group of statements, such as database SQL, logical operations, or messages sent to a queue. There are two transaction models: flat and nested.

Flat Transactions

In this simple model, a transaction consists of a series of operations. It can be either local or global (distributed). If all the operations succeed, the transaction is committed. If one operation fails, the whole transaction rolls back to the same state before it started. The EJB architecture supports flat transactions, which we will cover today.

Nested Transactions

This model allows new transactions to be spawned as children, inside another transaction. This is similar to a tree of transactions: The root transaction contains sub-transactions, and so on. Each sub-transaction can be rolled back individually. The whole nested transaction commits if and only if all the sub-transactions succeed.