Spring: 7 transaction propagation behaviors

7 Transaction Propagation Behaviors

• The so-called transaction propagation behavior is how when multiple transaction methods call each other, how the transaction is propagated among these methods. Spring supports the following 7 transaction propagation behaviors. 

spread behavior	meaning
PROPAGATION_REQUIRED ( REQUIRED in XML file )	Indicates that the current method must run in a context with a transaction. If the client has a transaction in progress, the callee will run in the transaction, otherwise, restart a transaction. ( If an exception occurs on the called side, both the calling side and the called side transaction will be rolled back )
PROPAGATION_SUPPORTS ( SUPPORTS in XML file )	Indicates that the current method does not necessarily need to have a transaction context, but it can also run within a transaction if there is one
PROPAGATION_MANDATORY ( MANDATORY in XML file )	Indicates that the current method must run in a transaction, if there is no transaction, an exception will be thrown
PROPAGATION_NESTED ( NESTED in XML file )	Indicates that if the current method has a transaction running, the method should run in a nested transaction, and the nested transaction can be committed or rolled back independently of the encapsulated transaction. If the encapsulated transaction exists and the outer transaction throws an exception and rolls back, then the inner transaction must be rolled back, otherwise, the inner transaction does not affect the outer transaction. If the encapsulating transaction does not exist, same as PROPAGATION_REQUIRED
PROPAGATION_NEVER ( NEVER in XML files )	Indicates that the current transaction should not run in a transaction, if there is a transaction, throw an exception
PROPAGATION_REQUIRES_NEW ( REQUIRES_NEW in XML file )	Indicates that the current method must run in its own transaction. A new transaction will be started, and if there is an existing transaction running, the method will be suspended at runtime until the new transaction commits or is rolled back .
PROPAGATION_NOT_SUPPORTED ( NOT_SUPPORTED in XML file )	Indicates that the method should not be run within a transaction. If a transaction is running, it will be suspended during runtime and will not resume execution until the transaction is committed or rolled back

Difference between PROPAGATION_NESTED and PROPAGATION_REQUIRES_NEW:

1. They are very similar, like a nested transaction, if there is no active transaction, will start a new transaction. 
2. When using PROPAGATION_REQUIRES_NEW, the inner transaction and the outer transaction are like two independent transactions. Once the inner transaction is committed, the outer transaction cannot be rolled back. The two transactions do not affect each other. Two transactions are not a true nested transaction. At the same time it requires the support of the JTA transaction manager.
3. When PROPAGATION_NESTED is used, the rollback of the outer transaction can cause the rollback of the inner transaction. The exception of the inner transaction will not cause the rollback of the outer transaction, it is a real nested transaction. When DataSourceTransactionManager uses savepoint to support PROPAGATION_NESTED, JDBC driver 3.0 or higher and JDK version 1.4 or higher are required. Other JTATrasactionManager implementations may have different support.
4. PROPAGATION_REQUIRES_NEW starts a new "internal" transaction that does not depend on the environment. This transaction will be fully committed or rolled back without dependencies on the outer transaction, it has its own isolation scope, its own locks, etc. When the inner transaction starts While executing, the outer transaction will be suspended, and when the house transaction ends, the outer transaction will continue to execute.
5. On the other hand, PROPAGATION_NESTED starts a "nested" transaction, which is a true subtransaction of an existing transaction. When the nested transaction starts executing, it will get a savepoint. If this nested transaction fails, we will roll back To this savepoint. The submerged transaction is part of the outer transaction, and it will only be committed after the outer transaction ends.
6. It can be seen that the biggest difference between PROPAGATION_REQUIRES_NEW and PROPAGATION_NESTED is that PROPAGATION_REQUIRES_NEW is a completely new transaction, while PROPAGATION_NESTED is a sub-transaction of the outer transaction. If the outer transaction commits, the nested transaction will also be committed. This rule also applies to roll back .

REQUIRED,REQUIRES_NEW,NESTED异同

1. PROPAGATION_NESTED, which is a nested transaction, only supports DataSourceTransactionManager as a transaction manager when using JDBC 3.0 driver. 
   

   Requires the java.sql.Savepoint class for the JDBC driver. To use PROPAGATION_NESTED, you also need to set the nestedTransactionAllowed property of PlatformTransactionManager to true (the property value defaults to false).

   A very important concept of nested transactions is that the inner transaction depends on the outer transaction. When the outer transaction fails, the actions done by the inner transaction are rolled back. The failure of the inner transaction operation will not cause the rollback of the outer transaction.

2. The inner methods modified by NESTED and REQUIRED belong to the transaction of the outer method. If the outer method throws an exception, the transaction of these two methods will be rolled back. But REQUIRED is to join the peripheral method transaction, so it belongs to the same transaction as the peripheral transaction. Once the REQUIRED transaction throws an exception and is rolled back, the peripheral method transaction will also be rolled back. NESTED is a sub-transaction of the peripheral method and has a separate savepoint, so the NESTED method throws an exception and is rolled back without affecting the transaction of the peripheral method.
3. Both NESTED and REQUIRES_NEW can rollback the internal method transaction without affecting the outer method transaction. But because NESTED is a nested transaction, after the outer method is rolled back, the subtransactions that are the transaction of the outer method will also be rolled back. While REQUIRES_NEW is implemented by opening a new transaction, the internal transaction and the peripheral transaction are two transactions, and the rollback of the peripheral transaction will not affect the internal transaction.

Reference source: https://segmentfault.com/a/1190000013341344