13.5.1 Transaction isolation levels overview

Transaction isolation levels provide a trade-off between accuracy of reads versus concurrent readers. The levels can best be described by the types of read anomalies they permit and forbid. Consider the read anomalies that can occur with two concurrent transactions, T1 and T2:

T1 reads data that has been modified by T2, before T2 commits.

Non-repeatable read is caused by fine-grained locks.

T1 reads a record and drops its lock.

T2 updates.

T1 re-reads different data.

This is a non-repeatable read involving a range of data and inserts or deletes on the range.

T1 reads a set of records that match some criterion.

T2 inserts a record that matches the criterion.

T1 continues processing the set, which now includes records that were not part of the original matching set.

There are four possible settings for the transaction isolation level:

This setting permits phantom reads and forbids both dirty and unrepeatable reads.

This setting permits non-repeatable and phantom reads and forbids dirty reads.

This setting permits all the read anomalies, including dirty reads, non-repeatable reads, and phantom reads.

This setting forbids all the read anomalies.

The container applies the isolation level as follows:

The transaction isolation level is tied to a database connection. The connection uses the isolation level specified in the first bean that uses the connection. The container throws an IsolationLevelChangeException whenever the connection is used by another bean method that has a different isolation level.

Not all databases support all JDBC isolation levels. Moreover, JDBC definitions for isolation levels might not match the database definition of isolation levels. As an example, DB2 definitions for isolation levels follow the naming conventions used in Transaction Processing: Concepts and Techniques by Gray. Table 13-4 shows a mapping between EJB and DB2 isolation levels.

Table 13-4