Transaction Management in Spring - Spring Enterprise Recipes: A Problem Solution Approach - page 183

Phantom read : For two transactions T1 and T2, T1 reads some rows from a table and then T2 inserts
new rows into the table. Later, if T1 reads the same table again, there will be additional rows.
Lost Updates : For two transactions T1 and T2, they both select a row for update and, based on
the state of that row, make an update to it. Thus, one overwrites the other when what should've
happened is that the second transaction to commit should have waited until the first one
committed before it performed its selection.

In theory, transactions should be completely isolated from each other (i.e., serializable) to avoid all
the mentioned problems. However, this isolation level will have great impact on performance because
transactions have to run in serial order. In practice, transactions can run in lower isolation levels in order
to improve performance.
A transaction's isolation level can be specified by the isolation transaction attribute.
Spring supports five isolation levels, as shown in Table 4-10. These levels are defined in the
org.springframework.transaction.TransactionDefinition interface.

Table 4-10. Isolation Levels Supported by Spring

Isolation Description

DEFAULT

Uses the default isolation level of the underlying database. For most databases, the
default isolation level is READ_COMMITTED .

READ_UNCOMMITTED Allows a transaction to read uncommitted changes by other transactions. The dirty

read, non-repeatable read, and phantom read problems may occur.

READ_COMMITTED Allows a transaction to read only those changes that have been committed by other

transactions. The dirty read problem can be avoided, but the non-repeatable read
and phantom read problems may still occur.

REPEATABLE_READ Ensures that a transaction can read identical values from a field multiple times. For

the duration of this transaction, updates made by other transactions to this field are
prohibited. The dirty read and non-repeatable read problems can be avoided, but
the phantom read problem may still occur.

SERIALIZABLE Ensures that a transaction can read identical rows from a table multiple times. For

the duration of this transaction, inserts, updates, and deletes made by other
transactions to this table are prohibited. All the concurrency problems can be
avoided, but the performance will be low.

Note that transaction isolation is supported by the underlying database engine but not an
application or a framework. However, not all database engines support all these isolation levels. You
can change the isolation level of a JDBC connection by calling the setTransactionIsolation() method
on the java.sql.Connection interface.