Overview of Transactions

If you've used RDBMS before, or completed a Computer Studies course or read any other J2EE book, you've probably read a section like this one already. But read on anyway, if only to be acquainted with some of the J2EE terminology that is used in this arena.

A transaction is an atomic unit of work:

• Atomic unit means indivisible—either every step within the transaction completes or none of them do.

• Work here usually means some modification to data within a persistent data store. In RDBMS terms, this means one or more INSERT, UPDATE, or DELETEs. However, strictly speaking, it also applies to reading of data through SELECT statements.

For a persistent data store to support transactions, it must pass the so-called “ACID” test:

• Atomic— The transaction is indivisible; the data store must ensure this is true.

• Consistent— The data store goes from one consistent point to another. Before the transaction, the data store is consistent; afterwards, it is still consistent.

  The age-old example is of transferring money between bank accounts. This will involve two UPDATEs, one decrementing the balance of account #1 and the other incrementing the balance of account #2. If only one UPDATE occurs, the transaction is not atomic, and the data store is no longer in a consistent state.

• Isolation— The data store gives the illusion that the transaction is being performed in isolation. Enterprise applications have many concurrent users who are all performing transactions at the same time, so behind the scenes, the data store uses techniques, such as locks, to serialize access to the contended data where necessary.

• Durability— If a transaction completes, any changes made to the data as a result of that transaction must be durable. In other words, if the power were to fail a millisecond after the transaction has completed, the change must still be there when power is reconnected.

Many data stores use transaction logs to address this requirement. The transaction log holds a journal of changes made to the actual data. When the transaction completes, the log is written to disk, although the actual data need not be.

Many data stores allow transactions to be started explicitly using a syntax such as the following:

begin transaction t1
					

where t1 is the (optional) name transaction. Transactions are completed using either commit (make changes permanent) or rollback (undo all changes made in the transaction, and revert all data back to the state before the transaction began). Many data stores will use

commit transaction t1

and

rollback transaction t1

To conclude this short introduction, consider the fragment of SQL shown in Listing 8.1. It transfers $50 from account #20457 to account #19834.

Listing 8.1. Example Fragment of SQL to Transfer Money Between Accounts

 1: begin transaction transfer_money
 2:
 3: update account
 4: set balance = balance - 50
 5: where account_id = 20457
 6:
 7: update account
 8: set balance = balance + 50
 9: where account_id = 19834
10:
11: commit transaction transfer_money

In effect, there are two different types of commands:

• Lines 1 and 11 demarcate the transaction.

• Lines 3–5 and 7–9 modify data.

A conventional RDBMS processes all of the SQL in Listing 8.1, but it is performing two different roles in doing so. To understand and process the transaction demarcation commands, it is acting as a transaction manager. To understand and process the remaining lines, it is acting as a resource manager.

In the EJB specification, these two responsibilities are split. In principle, you can think of the EJB container as acting as the transaction manager, and the persistent data store acting only as the resource manager. The term transaction coordinator is sometimes used instead of transaction manager because there could be more than one resource whose transactions are being coordinated.

Splitting the responsibilities of transaction management and resource management has two consequences. For the bean provider, it means that to start a transaction, the bean must interact both with the EJB container and with the persistent data store. The former interaction is largely implicit because it is configured through the deployment descriptor (and as you know, the latter interaction is implicit if CMP Entity beans are used). The other consequence is that, for the persistent data store, it must defer all transaction control responsibility up to the EJB container. Behind the scenes, there is some quite sophisticated communication going on; you'll learn a little about this activity later on today.