The propagation behavior and isolation level of spring transactions

1. Dissemination of transactions

In the process of using the transaction, the most propagating behavior is require, in most MIS system, the whole business layer can be cut to a require transaction to meet the needs.

But spring provides more than that, for complex business, spring also provides the corresponding transaction propagation behavior to meet the business needs.

The propagation behavior in spring is as follows:

Require: Support the current transaction, if there is no transaction, build a new one, which is the most common;

Supports: Supports the current transaction and, if there is no transaction, executes it in a non-transactional manner;

Mandatory: Supports the current transaction and throws an exception if there is no current transaction;

RequiresNew: Creates a new transaction, suspends the current transaction if a transaction is currently present;

NotSupported: Executes the operation in a non-transactional manner and suspends the transaction if there is a current transaction;

Never: Executes in a non-transactional manner and throws an exception if a transaction is currently present.

Nested: Creates a new transaction and suspends the current transaction if a transaction is currently present. The difference from requirenew is related to the parent transaction, and there is a savepoint.

Among them, Require, Supports,notsupported,never Two see the text also can understand, not much said. And mandatory is to require that all operations must be in one transaction, and more stringent on the transaction requirements than require.

Requirenew: When a require method A calls Requirenew method B, the B method will be new to a transaction, and the transaction is not related to a transaction, that is, the B method has an exception, does not cause a rollback, and B has been committed, a and then an exception, B is not going to roll back.

Nested: The difference between this and requirenew is that the transaction of the B method and the transaction of a method are relevant. The B transaction is committed only when a transaction is committed. That is, when an exception occurs, A and B transactions are rolled back, and when B has an exception, B rolls back, and A rolls back to SavePoint, as shown in the following code:

public void A () {    //operation 1    //Operation 2    //Operation 3    try{        //savepoint        B ();//A nested method    } catch{        // An exception occurs, the B method rolls back, the A method rolls back to        //savepoint, which means that operations 1, 2, 3 are still in       C ();    } finally{    }}   

2. Isolation level of a transaction
after talking about the behavior of the transaction propagation, and now again the transaction isolation level, the transaction isolation level appears to make you a balance between performance and data effectiveness, not to say that the higher the better, only the right is the best.

The transaction isolation level is as follows:

Serializable: The most stringent level, the transaction serial execution, the resource consumes the most;

REPEATABLE READ: Guarantees that a transaction does not modify data that has been read by another transaction but not committed (rolled back).

Read Committed: The default transaction level for most major databases ensures that one transaction does not read to another data that has been modified but not committed by a parallel transaction. Applies to most systems.

READ UNCOMMITTED: Ensures that illegal data is not read during the read process.

To understand these four levels, you also need to know three things that are not pleasing:

Dirty reads: Dirty reads, that is, transaction a uncommitted data is read by transaction B, and if transaction a fails to roll back, the data read by B will be incorrect.

Non-repeatable reads: Non-repeatable read, that is, transaction a in two read data, the first read is 100, then transaction B to change the value of 200, transaction A read again, the results found that the value changed, resulting in a transaction data confusion.

Phantom READ: Phantom reads are similar to non-repeatable reads and are also inconsistent with multiple reads in the same transaction. But the inconsistency of non-repeatable reads is because the data set it is going to be changed, and the data that the phantom reads is inconsistent is not the data that he wants to read, but the change of its conditional data set. For example: SELECT ID where name= "ppgogo*", the first time to read the 6 eligible IDs, the second time, because transaction B changed the name of the first post from "DD" to "ppgogo9", the result is taken out of 7 data.

The isolation level of a transaction causes the reading of illegal data to be as follows:

The propagation behavior and isolation level of spring transactions