Reprinted from: https://www.ibm.com/developerworks/cn/java/j-master-spring-transactional-use/index.html
Transaction management is an essential part of application system development. Spring provides rich functional support for transaction management. Spring transaction management is divided into two ways: coding and declarative. Programmatic transactions refer to the realization of transactions through coding; declarative transactions are based on AOP, which decouples specific business logic from transaction processing. Declarative transaction management keeps business code logic from being polluted, so declarative transactions are used more in actual use. There are two ways for declarative transactions, one is to declare related transaction rules in the configuration file (xml) , and the other is to use the @Transactional annotation . Annotation configuration is a popular way to use it, so this article will focus on transaction management based on @Transactional annotation.
The implementation steps of @Transactional annotation management transaction
The implementation of managing transactions using the @Transactional annotation is divided into two steps.
The first step is to add transaction configuration information such as Listing 1 in the xml configuration file. In addition to the configuration file, the @EnableTransactionManagement annotation can also enable transaction management. Here is an example of a simple DataSourceTransactionManager.
Listing 1. Transaction configuration information in xml configuration
1 <tx:annotation-driven /> 2 <bean id="transactionManager" 3 class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> 4 <property name="dataSource" ref="dataSource" /> 5 </bean>
The second step is to add the @Transactional annotation to the appropriate method and set the appropriate attribute information. The attribute information of the @Transactional annotation is shown in Table 1.
Table 1. Attribute information of the @Transactional annotation
| property name | illustrate |
| name | When there are multiple TransactionManagers in the configuration file, you can use this property to specify which transaction manager to choose. |
| propagation | The propagation behavior of the transaction, the default value is REQUIRED. |
| isolation | The isolation degree of the transaction, the default value is DEFAULT. |
| timeout | Transaction timeout, the default value is -1. If the time limit is exceeded but the transaction has not completed, the transaction is automatically rolled back. |
| read-only | Specifies whether the transaction is a read-only transaction, the default value is false; in order to ignore those methods that do not require a transaction, such as reading data, you can set read-only to true. |
| rollback-for | Used to specify the exception types that can trigger transaction rollback. If there are multiple exception types to be specified, they can be separated by commas. |
| no-rollback- for | Throws the exception type specified by no-rollback-for and does not roll back the transaction. |
In addition to this, the @Transactional annotation can also be added at the class level. When the @Transactional annotation is released at the class level, it means that all public methods of the class are configured with the same transaction attribute information. See Listing 2, all methods of EmployeeService support transactions and are read-only. When @Transactional is configured at the class level and @Transactional is configured at the method level, the application will manage transactions with the method-level transaction attribute information. In other words, the method-level transaction attribute information will override the class-level configuration information.
Listing 2. Class-level support for the @Transactional annotation
1 @Transactional(propagation= Propagation.SUPPORTS,readOnly=true) 2 @Service(value ="employeeService") 3 public class EmployeeService
At this point, you will find that the implementation steps to manage transactions using the @Transactional annotation are simple. However, if the transaction management of the @transaction annotation in Spring is not well understood, it is easy to make mistakes, such as the transaction should be rolled back (rollback) without rolling back the transaction. Next, we will first analyze the transaction implementation mechanism of Spring's annotation method, and then list the relevant precautions, so as to finally achieve the purpose of helping developers to use Spring's transactions accurately and proficiently.
Transaction implementation mechanism of Spring's annotation method
When the application system calls the target method declaring @Transactional, Spring Framework uses AOP proxy by default, and generates a proxy object when the code runs. According to the attribute configuration information of @Transactional, this proxy object determines whether the target method declaring @Transactional is intercepted or not. Interceptor TransactionInterceptor to use interception. When TransactionInterceptor intercepts, a transaction will be created and added before the target method starts to execute, and the logic of the target method will be executed. Finally, according to whether there is an abnormality in the execution situation, the abstract transaction manager will be used (see Figure 2 for related introductions). ) AbstractPlatformTransactionManager operates the data source DataSource to commit or roll back the transaction, as shown in Figure 1.
Figure 1. Spring transaction implementation mechanism
