- The characteristics and isolation level of Spring transactions are the same as transactions. For details, please see Transactions - What are transactions, characteristics of transactions, and isolation levels of transactions_Drunken Godot's Blog-CSDN Blog
1. Implementation methods and principles of Spring transactions
1. Implementation method
When using the Spring framework, there are two ways to implement transactions:
- Programmatic transactions: users control the processing logic of transactions through code
- Declarative transactions: implemented through @Transactional annotation
Transaction operations should originally be controlled by the database, but in order to facilitate users to operate business logic, spring has extended the transaction function. Generally, programmatic transactions are rarely used, and more are added by adding @Transactional annotations . To implement, when this annotation is added, the automatic function of the transaction will be turned off, and the spring framework will help control it.
2. Implementation principle
Spring's transaction operation is a core embodiment of AOP. When a method is added with the @Transactional annotation, Spring will generate a proxy object based on this class and use this proxy object as a bean. When using the method of this proxy object, if there is For transaction processing, the transaction will be automatically submitted to the relationship first, and then the specific business logic will be executed. If there is no exception in the execution logic, the agent logic will be submitted directly. If any exception occurs, the rollback operation will be performed directly. Of course, users can control which exceptions are rolled back.
2. Propagation characteristics of Spring transactions
When a transaction is implemented using the @Transactional annotation, and multiple transaction methods call each other, how does the transaction propagate between these methods? Spring provides 7 different propagation features to ensure the normal execution of transactions. The specific usage is as follows:
@Transactional(propagation = Propagation.REQUIRED)
public int saveUser(User user){
scoreDao.save(**);
return userDao.save(user);
}7 propagation features of Spring transactions:
- REQUIRED: The default propagation feature. If there is currently no transaction, create a new transaction. If there is currently a transaction, join this transaction.
Method B is called in method A, and the transaction propagation of method B is set to PROPAGATION_REQUIRED. If there is a transaction on method A, B will use A's transaction. If not, B will create a new transaction by itself.
- SUPPORTS: If there is currently a transaction, join the current transaction. If there is no transaction currently, execute in a non-transactional manner.
Method B is called in method A, and the transaction propagation of method B is set to PROPAGATION_SUPPORTS. If there is a transaction on method A, B will use A's transaction. If not, B will execute in a non-transactional manner.
- MANDATORY: If a transaction currently exists, join the current transaction. If the current transaction does not exist, an exception will be thrown.
If method B is called in method A, and the transaction propagation of method B is set to PROPAGATION_MANDATORY, method A is required to have a transaction. If so, B uses A's transaction. If A does not exist, an error will be reported.
- REQUIRED_NEW: Create a new transaction and suspend the current transaction if it exists
Method B is called in method A, and the transaction propagation of method B is set to PROPAGATION_REQUIRES_NEW. If there is a transaction on method A, the transaction of method A is suspended, and B uses its own transaction. If method A does not have a transaction, B will create a new transaction by itself.
- NOT_SUPPORTED: Execute in a non-transactional manner. If a current transaction exists, the current transaction is suspended.
Method B is called in method A, and the transaction propagation of method B is set to PROPAGATION_NOT_SUPPORTED. If there is a transaction on method A, the transaction of method A will be suspended (because methods A and B are executed in the same thread) as a non-transaction Executed in a non-transactional manner. If A does not have a transaction, it will be executed in a non-transactional manner.
- NEVER: Do not use transactions. If the current transaction exists, an exception is thrown.
If method B is called in method A, and the transaction propagation of method B is set to PROPAGATION_NEVER, it is required that there must be no transactions on method A. If there is, an error will be reported. If A does not have a transaction, it will be executed in a non-transactional manner, and B will always be executed in a non-transactional manner.
- NESTED: If the current transaction exists, it will be executed in the nested transaction, otherwise the operation of REQUIRED is the same
Method B is called in method A, and the transaction propagation of method B is set to PROPAGATION_NESTED. If there is a transaction on method A, the transaction of method B is nested in the transaction of method A. If method A does not have a transaction, B will create a new transaction by itself.
The differences between NESTED, REQUIRED and REQUIRED_NEW are as follows:
The difference between NESTED and REQUIRED_NEW:
REQUIRED_NEW is to create a new transaction and the newly started transaction has nothing to do with the original transaction, while NESTED is to open a nested transaction when there is currently a transaction. In the case of NESTED, when the parent transaction is rolled back, the child transaction will also be rolled back. , and in the case of REQUIRED_NEW, the original transaction is rolled back and will not affect the newly opened transaction.
The difference between NESTED and REQUIRED:
In the case of REQUIRED, when the caller has a transaction, the callee and the caller use the same transaction. When an exception occurs on the callee, a transaction is shared, so the transaction will be rolled back regardless of whether the exception is caught. In NESTED In this case, when an exception occurs on the callee, the caller can catch its exception, so that only the child transaction is rolled back, and the parent transaction will not be rolled back.