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

Thread 1—Prepare to check book stock
Thread 1—Book stock is 10
Thread 1—Sleeping
Thread 2—Prepare to increase book stock
Thread 1—Wake up
Thread 2—Book stock increased by 5
Thread 2—Sleeping
Thread 2—Wake up
Thread 2—Book stock rolled back
In order that the underlying database can support the REPEATABLE_READ isolation level, it may
acquire a read lock on a row that was read but not yet committed. Then other transactions must wait to
update the row until the read lock is released, which happens when the locking transaction commits or
rolls back.
The SERIALIZABLE Isolation Level
After a transaction has read several rows from a table, another transaction inserts new rows into the
same table. If the first transaction reads the same table again, it will find additional rows that are
different from the first read. This problem is known as phantom read . Actually, phantom read is very
similar to non-repeatable read, but involves multiple rows.
To avoid the phantom read problem, you should raise the isolation level to the highest: SERIALIZABLE .
Notice that this isolation level is the slowest because it may acquire a read lock on the full table. In practice,
you should always choose the lowest isolation level that can satisfy your requirements.
Setting the Isolation Level Attribute in Transaction Advices, Proxies, and APIs
In a Spring xxxtransaction advice, the isolation level can be specified in the <tx:method> element as
follows:
<tx:advice ...>
<tx:attributes>
<tx:method name= " * "
isolation= " REPEATABLE_READ " />
</tx:attributes>
</tx:advice>
In classic Spring AOP, the isolation level can be specified in the transaction attributes of
TransactionInterceptor and TransactionProxyFactoryBean as follows:
<property name= " transactionAttributes " >
<props>
<prop key= " ... " >
PROPAGATION_REQUIRED, ISOLATION_REPEATABLE_READ
</prop>
</props>
</property>