A detailed explanation of transactional propagation properties in spring

When using spring, most of the use of his declarative transactions, a simple rule configuration in the configuration file, the use of spring's AOP features can easily handle the transaction problem; There is a problem with the propagation property of a transaction propagation, It is defined in the Transactiondefinition interface for Platfromtransactionmanager use, and Platfromtransactionmanager is the core interface for spring transaction management.

TransactionDefinition
public interface TransactionDefinition {
　 int getPropagationBehavior();
　 int getIsolationLevel();
　 int getTimeout();
　 boolean isReadOnly();
}

GetTimeout () method that returns the number of seconds a transaction must complete.

IsReadOnly (), transactions are read-only, and the transaction manager is able to optimize against this return value to ensure that transactions are read-only.

The Getisolationlevel () method returns the isolation level of a transaction from which the transaction manager controls another transaction to see what data is within the transaction.

Five different transaction isolation levels are defined in the Transactiondefinition interface, Isolation_default This is a platfromtransactionmanager default isolation level. Use the default transaction isolation level of the database. The other four corresponds to the isolation level of JDBC, isolation_read_uncommitted, which is the lowest isolation level for a transaction, and allows a transaction to see uncommitted data for this transaction. This isolation level produces dirty reads, no repeat reads, and Phantom reads.

There are a total of 7 options available in the Transactiondefinition interface:

Propagation_required: Supports the current transaction, and creates a new transaction if there are currently no transactions. This is the most common choice.

Propagation_supports: Supports the current transaction and executes it in a non transactional manner if there are currently no transactions.

Propagation_mandatory: Supports the current transaction and throws an exception if there are currently no transactions.

Propagation_requires_new: Creates a new transaction, suspends the current transaction if there is currently a transaction.

Propagation_not_supported: Performs an operation in a non transactional manner and suspends the current transaction if there is currently a transaction.

Propagation_never: Executes in a non transactional manner and throws an exception if there is a current transaction.

Propagation_nested: Supports current transaction, adds new savepoint point, commits or rolls back synchronously with current transaction.

Now with an example, apply the above various propagation properties to illustrate: First, declare two bean:servicea and SERVICEB, wherein SERVICEB is referenced;

ServiceA {
　　　　 void methodA() {
　　　　　　 ServiceB.methodB();
　　　　 }
　　 }
　　 ServiceB {
　　　　 void methodB() {
　　　　 }
　　 }

Next, we will analyze the following:

Propagation_required

To join a transaction that is currently being executed is not in another transaction, then a new transaction is established; For example, the SERVICEB.METHODB transaction level is defined as propagation_required, so because of the execution of Servicea.methoda, Servicea.methoda had already started a transaction, when the call Serviceb.methodb,serviceb.methodb saw that he was already running inside the Servicea.methoda transaction, no new transactions were made. And if Servicea.methoda found himself not in the business, he would assign himself a transaction. In this way, the transaction is rolled back when an exception occurs in Servicea.methoda or anywhere within the SERVICEB.METHODB. Even if the SERVICEB.METHODB transaction has been committed, the Servicea.methoda is fail to roll back and serviceb.methodb to roll back in the next step.