JAVA : Transactions and Persistence

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 any-
way, 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 per-
forming transactions at the same time, so behind the scenes, the data store uses tech-
niques, 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 mil-
lisecond 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 com-
pletes, 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 transac-
tion, and revert all data back to the state before the transaction began). Many data stores
will use
commit transaction t1
and
rollback transaction t1


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 con-
trol responsibility up to the EJB container. Behind the scenes, there is some quite sophis-
ticated communication going on; you’ll learn a little about this activity later on today.