Detailed introduction to Spring transaction principles

1. Basic principles of transactions

The essence of Spring transactions is actually the support of transactions by the database. Without the transaction support of the database, spring cannot provide transaction functions. For pure JDBC operation database, if you want to use transactions, you can follow the following steps:

1. Get the connection Connection con = DriverManager.getConnection()

2. Open transaction con.setAutoCommit(true/false);

3. Execute CRUD

4. Commit transaction/rollback transaction con.commit() / con.rollback();

5. Close the connection conn.close();

After using Spring’s transaction management function, we can not Then write the code for steps 2 and 4, and let Spirng automatically complete . Then Spring is How to open and close transactions before and after the CRUD we write? To solve this problem, we can understand the implementation principle of Spring's transaction management as a whole. The annotation method is as an example

#.

1. ##Configuration fileEnable annotationsDriver, and mark the relevant classes and methods with the @Transactional annotation

##. #spring will parse and generate related beans when it starts. At this time, it will check the classes and methods with relevant annotations, generate proxies for these classes and methods, and inject relevant configurations according to the relevant parameters of @Transaction, so that The agent handles the relevant transactions for us (turn on normal transaction submission and exception rollback).
The real database layer transaction submission and rollback is through binlog or redo. Log implemented.
2. Propagation of Spring transactions

Properties

The so-called propagation properties of spring transactions are defined when there are multiple transactions at the same time. When they exist, how spring should handle the behavior of these transactions. These attributes are defined in TransactionDefinition. The explanation of the specific

constants

is shown in the following table:

Constants Name##PROPAGATION_REQUIREDSupports the current transaction. If there is no current transaction, create a new transaction. This is the most common choice, and it is also the most common choice. Spring's default transaction propagation. PROPAGATION_REQUIRES_NEWCreate a new transaction. If a transaction currently exists, suspend the current transaction. The newly created transaction will have nothing to do with the suspended transaction. They are two independent transactions. After the outer transaction fails and is rolled back, the results of the inner transaction execution cannot be rolled back. The inner transaction fails, outer transaction capture, you can also not process the rollback operationPROPAGATION_SUPPORTSSupports the current transaction, if there is no transaction currently, it will be executed in a non-transactional manner. PROPAGATION_MANDATORYSupports the current transaction. If there is no current transaction, an exception will be thrown. PROPAGATION_NOT_SUPPORTEDPerform the operation in a non-transactional manner. If a transaction currently exists, the current transaction will be suspended. PROPAGATION_NEVERExecute in a non-transactional manner and throw an exception if a transaction currently exists. PROPAGATION_NESTED

3. Database isolation level

Constant Explanation
throws an exception
If an active transaction exists, run in a nested transaction. If there is no active transaction, the REQUIRED attribute is executed. It uses a single transaction with multiple savepoints that can be rolled back. Rollback of internal transactions will not affect external transactions. It only works on the DataSourceTransactionManager transaction manager.

Isolation level	Isolation level value	Problems caused
Read-Uncommitted	0	Causes dirty read
Read-Committed	1	Avoid dirty reads, allow non-repeatable reads and phantom reads
Repeatable-Read	2	Avoid dirty reads, non-repeatable reads, Allow phantom reading
Serializable	3	Serialized reading, transactions can only be executed one by one, avoiding dirty reads, non-repeatable reads, Phantom reading. The execution efficiency is slow, so use it with caution

Dirty read: One transaction added, deleted, or modified data, but it was not committed. Another transaction can read the uncommitted data. If the first transaction is rolled back at this time, the second transaction will read dirty data.

Non-repeatable read: Two read operations occurred in a transaction. Between the first read operation and the second operation, another transaction modified the data. At this time, the data read twice is inconsistent.

Phantom reading: The first transaction batches modifications to a certain range of data, and the second transaction adds a piece of data to this range. At this time, the first transaction will lose the modification of the newly added data.

Summary:

The higher the isolation level, the more complete and consistent the data can be guaranteed, but the greater the impact on concurrency performance.

The default isolation level of most databases is Read Commited, such as SqlServer and Oracle

The default isolation level of a few databases is: Repeatable Read, for example: MySQL InnoDB

4. Isolation levels in Spring

##ConstantExplanation##ISOLATION_DEFAULTISOLATION_READ_UNCOMMITTEDISOLATION_READ_COMMITTEDISOLATION_REPEATABLE_READISOLATION_SERIALIZABLE

5. Nesting of transactions

Through the above theoretical knowledge, we have a rough understanding of some attributes and characteristics of database transactions and spring transactions. Next, we analyze some nested transaction scenarios, To deeply understand the mechanism of spring transaction propagation.

Assume that Method A() of outer transaction Service A calls Method B() of inner Service B

PROPAGATION_REQUIRED (spring default)

If the transaction level of ServiceB.methodB() is defined as PROPAGATION_REQUIRED, then spring has already started a transaction when executing ServiceA.methodA(). At this time, ServiceB.methodB() is called, and ServiceB.methodB() sees that it is already running in ServiceA. Within the transaction of methodA(), no new transaction will be initiated.

If ServiceB.methodB() finds that it is not in a transaction when it is running, it will allocate a transaction for itself.

In this way, if an exception occurs anywhere within ServiceA.methodA() or ServiceB.methodB(), the transaction will be rolled back.

PROPAGATION_REQUIRES_NEW

For example, we design the transaction level of ServiceA.methodA() to be PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB() to be PROPAGATION_REQUIRES_NEW.

Then when ServiceB.methodB() is executed, the transaction where ServiceA.methodA() is located will be suspended, ServiceB.methodB() will start a new transaction, waiting for ServiceB.methodB() After the transaction is completed, it continues execution.

The difference between it and PROPAGATION_REQUIRED is the degree of rollback of the transaction. Because ServiceB.methodB() starts a new transaction, there are two different transactions. If ServiceB.methodB() has been submitted, then ServiceA.methodA() fails and rolls back, but ServiceB.methodB() will not roll back. If ServiceB.methodB() fails to rollback, if the exception it throws is caught by ServiceA.methodA(), the ServiceA.methodA() transaction may still be submitted (it mainly depends on whether the exception thrown by B is an exception that A will rollback) .

PROPAGATION_SUPPORTS

Assuming that the transaction level of ServiceB.methodB() is PROPAGATION_SUPPORTS, then when executing ServiceB.methodB(), if it is found that ServiceA.methodA() has already When a transaction is opened, join the current transaction. If it is found that ServiceA.methodA() does not open the transaction, it will not open the transaction itself. At this time, the transactionality of the inner method completely depends on the outermost transaction.

PROPAGATION_NESTED

The situation now becomes more complicated. The transaction attribute of ServiceB.methodB() is configured as PROPAGATION_NESTED. At this time, there will be How to collaborate? ServiceB#methodB If rollback, then the internal transaction (i.e. ServiceB#methodB) will be rolled back to the SavePoint before it was executed, while the external transaction (i.e. ServiceA#methodA) can be processed in the following two ways:

a. Capture exceptions and execute exception branch logic

void methodA() { 

        try { 

            ServiceB.methodB(); 

        } catch (SomeException) { 

            // 执行其他业务, 如 ServiceC.methodC(); 

        } 

    }

This method is also the most valuable part of nested transactions. It has the effect of branch execution. If ServiceB.methodB fails, then execute ServiceC.methodC( ), and ServiceB.methodB has rolled back to the SavePoint before it was executed, so no dirty data will be generated (equivalent to this method never being executed). This feature can be used in some special businesses, and PROPAGATION_REQUIRED and PROPAGATION_REQUIRES_NEW There is no way to do this.

b. The external transaction rollback/commit code does not make any changes, then if the internal transaction (ServiceB#methodB) rollback, then first ServiceB.methodB rolls back to the SavePoint before it was executed (in any case it will So), the external transaction (i.e. ServiceA#methodA) will decide whether to commit or rollback according to the specific configuration

The other three transaction propagation attributes are basically not used and will not be analyzed here.

6. Summary

For places where transactions are needed in the project, I recommend that developers still use spring’s TransactionCallback interface to implement transactions. Do not blindly use spring transaction annotations. If you must use Note, you must have a detailed understanding of the spring transaction propagation mechanism and isolation level, otherwise unexpected effects may occur.

This is the default isolation level of PlatfromTransactionManager, using the default transaction isolation level of the database. The other four correspond to JDBC isolation levels.
This is the lowest isolation level for a transaction, which allows another transaction to see the uncommitted data of this transaction. This isolation level will produce dirty reads, non-repeatable reads and phantom reads.
Ensure that the data modified by one transaction can only be read by another transaction after it is submitted. Another transaction cannot read the uncommitted data of this transaction.
This transaction isolation level can prevent dirty reads and non-repeatable reads. However, phantom reads may occur.
This is the most expensive but most reliable transaction isolation level. Transactions are processed as sequential execution.

The above is the detailed content of Detailed introduction to Spring transaction principles. For more information, please follow other related articles on the PHP Chinese website!