Transaction isolation (the “I” in ACID) is a critical part of any transactional system. This section explains isolation conditions, database locking, and transaction isolation levels. These concepts are important when deploying any transactional system.
Transaction isolation is defined in terms of isolation conditions called dirty reads, repeatable reads, and phantom reads. These conditions describe what can happen when two or more transactions operate on the same data.
To illustrate these conditions, let’s think about two separate
client applications using their own instances of the TravelAgent EJB
to access the same data—specifically, a cabin record with the
primary key of 99. These examples revolve around the
RESERVATION table, which is accessed by both the
bookPassage() method (through the Reservation EJB)
listAvailableCabins() method (through
JDBC). It might be a good idea to go back to Chapter 12 and review how the
RESERVATION table is accessed through these
methods. This will help you to understand how two transactions
executed by two different clients can impact each other. Assume that
both methods have a transaction attribute of
A dirty read occurs when the first transaction reads uncommitted changes made by a second transaction. If the second transaction is rolled back, the data read by the first transaction becomes invalid because the rollback undoes the changes. The ...