Two common configuration methods for Spring declarative transactions

Two common configuration methods for Spring declarative transactions

        Declarative transaction management is built on top of AOP. Its essence is to intercept the method before and after, and then create or join a transaction before the target method starts, and commit or roll back the transaction according to the execution status after the target method is executed. The biggest advantage of declarative transactions is that there is no need to programmatically manage transactions, so there is no need to mix transaction management code in business logic code, just make relevant transaction rule declarations in configuration files (or through @Transactional Annotation method), you can apply transaction rules to business logic.

        Obviously declarative transaction management is better than programmatic transaction management, which is the non-intrusive development method advocated by spring. Declarative transaction management keeps business code from being polluted. An ordinary POJO object can get full transaction support as long as it is annotated. Compared with programmatic transactions, the only disadvantage of declarative transactions is that the finer granularity of the latter can only be applied to the method level, and cannot be applied to the code block level like programmatic transactions. But even if there is such a demand, there are many workarounds, for example, the code block that needs transaction management can be independent as a method and so on.

1. One is an xml configuration file based on the tx and aop namespaces. The core configuration is as follows:

<!-- 对数据源进行事务管理 -->
<bean id="transactionManager"
	class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
	<property name="dataSource" ref="dynamicDataSource" />
</bean>

<!-- 配置哪些方法要加入事务控制 -->
<tx:advice id="txAdvice" transaction-manager="transactionManager">
	<tx:attributes>
		<!-- 让所有的方法都加入事务管理，为了提高效率，可以把一些查询之类的方法设置为只读的事务 -->
		<tx:method name="*" propagation="REQUIRED" read-only="true" />
		<!-- 以下方法都是可能设计修改的方法，就无法设置为只读 -->
		<tx:method name="add*" propagation="REQUIRED" rollback-for="java.lang.Exception"/>
		<tx:method name="insert*" propagation="REQUIRED" />
		<tx:method name="del*" propagation="REQUIRED" />
		<tx:method name="update*" propagation="REQUIRED" />
		<tx:method name="save*" propagation="REQUIRED" />
		<tx:method name="clear*" propagation="REQUIRED" />
		<tx:method name="handle*" propagation="REQUIRED" rollback-for="java.lang.Exception"/>
	</tx:attributes>
</tx:advice>

<!-- 配置一个切面 -->
<aop:config>
	<!-- 配置一个切点 -->
	<aop:pointcut id="allMethods" expression="(execution(* cn.edu.his.pay.service.*.*(..)))" />
	<aop:advisor advice-ref="txAdvice" pointcut-ref="allMethods" />
</aop:config>

2. Based on the @Transactional annotation, the core configuration is as follows:

<!-- 对数据源进行事务管理 -->
<bean id="transactionManager"
	class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
	<property name="dataSource" ref="dynamicDataSource" />
</bean>

<!-- 开启事务控制的注解支持 -->
<tx:annotation-driven transaction-manager="transactionManager"/>

Summary: Both methods can effectively use Spring's transaction management mechanism to manage the ACID of transactions. There are certain trade-offs to use in the project here. First, let's analyze the first one. The first one is mainly to use Aop. +xml configuration, this method is mainly to configure the entry point of Aop in xml (that is, the method in service) and configure which methods need to be added to transaction management, usually in the way of regular matching, and the core configuration information (transaction control) All are configured in xml; and the second is Aop+annotation, which uses Aop to scan the method with @Transactional annotation, and manages the transaction according to the transaction control rules configured by the annotation before the method. . In comparison, I recommend using the first one, because it can set the transaction control rules of the method in batches, and the second one needs to add annotations to each method that requires transaction control, but since the first one controls all methods , the second is the designated method of control. At this time, the overhead of the first type is definitely larger than that of the second type. In addition, you need to understand the transaction isolation level and consider how to ensure the ACID of the data in the specified business. It is better to set the corresponding transaction control rules in the code, and don't use the transaction configuration with two methods in the same project (meaningless), their functions are the same, just use one.