Transactional Isolation And Propagation

Summery

Propagation

Defines how transactions relate to each other. Common options:

• Required: Code will always run in a transaction. Creates a new transaction or reuses one if available.
• Requires_new: Code will always run in a new transaction. Suspends the current transaction if one exists.

Isolation

Defines the data contract between transactions.

• Read Uncommitted: Allows dirty reads.
• Read Committed: Does not allow dirty reads.
• Repeatable Read: If a row is read twice in the same transaction, the result will always be the same.
• Serializable: Performs all transactions in a sequence.

The different levels have different performance characteristics in a multi-threaded application. Those who understand the dirty reads concept they are able to be select a good option.

Isolation Level

defines how the changes made to some data repository by one transaction affect other simultaneous concurrent transactions, and also how and when that changed data becomes available to other transactions. When we define a transaction using the Spring framework we are also able to configure in which isolation level that same transaction will be executed.

@Transactional(isolation=Isolation.READ_COMMITTED)
public void someTransactionalMethod(Object obj) {

}

• READ_UNCOMMITTED isolation level states that a transaction may read data that is still uncommitted by other transactions.
• READ_COMMITTED isolation level states that a transaction can't read data that is not yet committed by other transactions.
• REPEATABLE_READ isolation level states that if a transaction reads one record from the database multiple times the result of all those reading operations must always be the same.
• SERIALIZABLE isolation level is the most restrictive of all isolation levels. Transactions are executed with locking at all levels (read, range and write locking) so they appear as if they were executed in a serialized way.

Propagation

Is the ability to decide how the business methods should be encapsulated in both logical or physical transactions.

• REQUIRED behavior means that the same transaction will be used if there is an already opened transaction in the current bean method execution context.
• REQUIRES_NEW behavior means that a new physical transaction will always be created by the container.
• NESTED behavior makes nested Spring transactions to use the same physical transaction but sets savepoints between nested invocations so inner transactions may also rollback independently of outer transactions.
• MANDATORY behavior states that an existing opened transaction must already exist. If not an exception will be thrown by the container.
• NEVER behavior states that an existing opened transaction must not already exist. If a transaction exists an exception will be thrown by the container.
• NOT_SUPPORTED behavior will execute outside of the scope of any transaction. If an opened transaction already exists it will be paused.
• SUPPORTS behavior will execute in the scope of a transaction if an opened transaction already exists. If there isn't an already opened transaction the method will execute anyway but in a non-transactional way.

References

• Spring Transactional Isolation & Propagation
• Spring transaction isolation level tutorial