Spring transaction isolation level and propagation characteristics

Propagation behavior

The first aspect of a transaction is the propagation behavior. The propagation behavior defines the transaction boundary about the client and the called method. Spring defines the propagation behavior in 7.

propagation Behavior	meaning
propagation_mandatory [Propagation_manadatory]	Indicates that the method must be running in a transaction. If no transaction is currently occurring, an exception will be thrown
propagation_nested [Propagation_nested]	Indicates that if a transaction is currently in progress, the method should run in a nested transaction . A nested transaction can be committed or rolled back independently of the encapsulated transaction. If the encapsulated transaction does not exist, the behavior is like propagation_requires.
Propagation_never [Propagation_never]	Indicates that the current method should not run in a transaction . If a transaction is in progress, an exception is thrown .
propagation_not_supported [Propagation_not_supported]	Indicates that the method should not run in a transaction. If an existing transaction is in progress, it will be suspended during the operation of the method.
Propagation_supports [Propagation_supports]	Indicates that the current method does not require a transactional context, but it can also run in this transaction if a transaction is already running.
Propagation_requires_new [Propagation_requires_new]	Indicates that the current method must run in its own transaction. A new transaction will be started, and if an existing transaction is running, it will be suspended while the method is running.
Propagation_requires [Propagation_requires]	Indicates that the current method must run in a transaction. If an existing transaction is in progress, the method runs in that transaction, or a new transaction is started.

The propagation rule answers the question whether a new transaction should be started or suspended, or if a method should run in a transactional context.

• PROPAGATION_REQUIRED      required 支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。

• PROPAGATION_SUPPORTS      supports  支持当前事务，如果当前没有事务，就以非事务方式执行。
• PROPAGATION_MANDATORY      mandatory 支持当前事务，如果当前没有事务，就抛出异常。 
• PROPAGATION_REQUIRES_NEW    requires_new 新建事务，如果当前存在事务，把当前事务挂起。 
• PROPAGATION_NOT_SUPPORTED   not_supported 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 
• PROPAGATION_NEVER        never 以非事务方式执行，如果当前存在事务，则抛出异常。

Propagation_required
假如当前正要执行的事务不在另外一个事务里，那么就起一个新的事务 

比如说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候，ServiceA.methodA已经起了事务，

这时调用ServiceB.methodB，ServiceB.methodB看到自己已经运行在ServiceA.methodA的事务内部，就不再起新的事务。

而假如ServiceA.methodA运行的时候发现自己没有在事务中，他就会为自己分配一个事务。这样，在ServiceA.methodA或者在ServiceB.methodB内的任何地方出现异常，事务都会被回滚。

即使ServiceB.methodB的事务已经被提交，但是ServiceA.methodA在接下来fail要回滚，ServiceB.methodB也要回滚

PROPAGATION_SUPPORTS
如果当前在事务中，即以事务的形式运行，如果当前不再一个事务中，那么就以非事务的形式运行 


PROPAGATION_MANDATORY
必须在一个事务中运行。也就是说，他只能被一个父事务调用。否则，他就要抛出异常


PROPAGATION_REQUIRES_NEW
这个就比较绕口了。 比如我们设计ServiceA.methodA的事务级别为PROPAGATION_REQUIRED，ServiceB.methodB的事务级别为PROPAGATION_REQUIRES_NEW，

那么当执行到ServiceB.methodB的时候，ServiceA.methodA所在的事务就会挂起，ServiceB.methodB会起一个新的事务，等待ServiceB.methodB的事务完成以后，

他才继续执行。他与PROPAGATION_REQUIRED 的事务区别在于事务的回滚程度了。因为ServiceB.methodB是新起一个事务，那么就是存在两个不同的事务。

如果ServiceB.methodB已经提交，那么ServiceA.methodA失败回滚，ServiceB.methodB是不会回滚的。如果ServiceB.methodB失败回滚，

如果他抛出的异常被ServiceA.methodA捕获，ServiceA.methodA事务仍然可能提交。

PROPAGATION_NOT_SUPPORTED
当前不支持事务。比如ServiceA.methodA的事务级别是PROPAGATION_REQUIRED ，而ServiceB.methodB的事务级别是PROPAGATION_NOT_SUPPORTED ，

那么当执行到ServiceB.methodB时，ServiceA.methodA的事务挂起，而他以非事务的状态运行完，再继续ServiceA.methodA的事务。


PROPAGATION_NEVER
不能在事务中运行。假设ServiceA.methodA的事务级别是PROPAGATION_REQUIRED，

而ServiceB.methodB的事务级别是PROPAGATION_NEVER ，那么ServiceB.methodB就要抛出异常了。 


PROPAGATION_NESTED
理解Nested的关键是savepoint。他与PROPAGATION_REQUIRES_NEW的区别是，PROPAGATION_REQUIRES_NEW另起一个事务，

将会与他的父事务相互独立，而Nested的事务和他的父事务是相依的，他的提交是要等和他的父事务一块提交的。也就是说，如果父事务最后回滚，他也要回滚的。 


而Nested事务的好处是他有一个savepoint。 

Isolation level

The second aspect of a declarative transaction is the isolation level. The isolation level defines the degree to which a transaction may be affected by other concurrent transaction activity activities. Another way to think about the isolation level of a transaction is to think of it as the selfish degree to which the transaction deals with the data.

In a typical application, multiple transactions run concurrently, often manipulating the same data to complete their work. Concurrency, though required, can cause problems:

• Dirty Reads (Dirty read)--dirty reads occur when a transaction reads data that has been overwritten by another transaction but has not yet been committed. If these changes are rolled back later, the data read by the first transaction will be invalid.
• Non-repeatable read (nonrepeatable Read)-non-repeatable reads occur when a transaction executes the same query two or more times, but each query result is not the same. This is usually due to the fact that another concurrent transaction has updated data between two queries.
• Phantom reads (Phantom reads)-Phantom reads and non-repeatable reads are similar. Phantom reads occur when a transaction (T1) reads several rows of records and another concurrent transaction (T2) inserts some records. In subsequent queries, the first transaction (T1) will find some additional records that were not originally available.

In an ideal state, transactions are completely isolated from each other, preventing these problems from occurring. However, full isolation can affect performance because isolation often involves locking records in the database (and sometimes locking the complete data table). An aggressive lock can hinder concurrency and require transactions to wait for each other to complete the work.

Given that full isolation affects performance, and not all applications require complete isolation, there are times when transaction isolation can be handled flexibly. Therefore, there will be several isolation levels.

Isolation Level	meaning
Isolation_default [DEFAULT]	Use the default isolation level of the back-end database.
isolation_read_uncommitted [read_uncommitted]	Allows you to read changes that have not yet been committed. May cause dirty reads, Phantom reads, or non-repeatable reads.
isolation_read_committed [read-committed]	Allows reading from a concurrent transaction that has already been committed. Can prevent dirty reads, but Phantom reads and non-repeatable reads may still occur.
Isolation_repeatable_read [Repeatable_read]	The result of multiple reads of the same field is consistent unless the data is changed by the current transaction itself. can prevent dirty reads and non-repeatable reads, but Phantom reads can still occur.
isolation_serializable [SERIALIZABLE]	Completely obey the isolation level of acid, ensuring that no dirty reads, non-repeatable reads, and phantom reads occur. This is also the slowest in all isolation levels, as it is usually done by completely locking the data tables involved in the current transaction.

	Dirty Reads	Non-repeatable Reads	Phantom reads
Serializable	No	No	No
Repeatable READ	No	No	Yes
READ COMMITTED	No	Yes	Yes
Read UNCOMMITTED	Yes	Yes	Yes

Declarative:
Using Transactionproxyfactorybean:

class= "Org.springframework.transaction.interceptor.TransactionProxyFactoryBean" >     <property Name= "TransactionManager" ><ref bean= "TransactionManager"/></property> <property     name= " Target "><ref local=" Usermanagertarget "/></property>     <property name=" Transactionattributes " >      <props>       <prop key= "insert*" >PROPAGATION_REQUIRED</prop>       <prop key= "update* ">PROPAGATION_REQUIRED</prop>       <prop key=" * ">PROPAGATION_REQUIRED,readOnly</prop>      </props>     </property>  </bean>  

Read-only

The third attribute of a declarative transaction is whether it is a read-only transaction. If a transaction performs only read operations on the back-end database, the database may take advantage of the read-only feature of that transaction, taking some optimizations. By declaring a transaction as read-only, you can give the backend database an opportunity to apply the optimizations that it deems appropriate. Because read-only optimizations are implemented by a back-end database when a transaction is started, only the propagation behavior that has the potential to start a new transaction (Propagation_requires_new, propagation_required, ropagation _nested) method, it makes sense to declare a transaction as read-only.

In addition, if Hibernate is used as a persistence mechanism, then declaring a transaction as read-only will make Hibernate's flush mode set to Flush_never. This tells hibernate to avoid unnecessary object synchronization with the database, thus delaying all updates to the end of the transaction.

Transaction timeout

In order for an application to perform well, its transactions cannot run for too long. Therefore, the next attribute of a declarative transaction is its timeout.

Assuming that the transaction runs for a very long time, the long-running transaction unnecessarily consumes the database resources because the transaction may involve locking the backend database. You can then declare that a transaction automatically rolls back after a certain number of seconds, without waiting for it to end itself.

Because the timeout clock begins when a transaction starts, only the propagation behavior that has the potential to start a new transaction (Propagation_requires_new, propagation_required, Ropagation_ NESTED), declaring a transaction timeout makes sense.

rolling back rules

The next edge of a transaction Pentagon is a set of rules that define which exceptions cause rollback and which do not. By default, transactions are rolled back only when there is a runtime exception (runtime exception), and are not rolled back when a check exception (checked exception) occurs (this behavior is consistent with the rollback behavior in the EJB).

However, you can also declare a rollback as a run-time exception when a particular checked exception occurs. Similarly, you can declare that a transaction does not roll back when a particular exception occurs, even if those exceptions are run-time.

Spring transaction isolation level and propagation characteristics