Spring annotates transactions, declares that in the case of coexistence of transactions, the order is in order

 1 <!-- hibernate -->
 2     <bean id="sessionFactory"
 3         class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
 4         <property name="dataSource" ref="dataSource" />
 5         <property name="hibernateProperties">
 6             <props>
 7                 <prop key="hibernate.hbm2ddl.auto">update</prop>
 8                 <prop key="hibernate.show_sql">true</prop>
 9                 <prop key="hibernate.format_sql">true</prop>
10                 <prop key="connection.autoReconnect">true</prop>
11                 <prop key="connection.autoReconnectForPools">true</prop>
12                 <prop key="connection.is-connection-validation-required">true</prop>
13                 <prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>
14             </props>
15         </property>
16         <property name="mappingDirectoryLocations">
17             <list>
18                 <value>classpath*:*oddtech/bean</value>
19             </list>
20         </property>
21     </bean>
22 
23     <!-- 事務管理 -->
24     <bean id="txManager"
25          class = " org.springframework.orm.hibernate3.HibernateTransactionManager " >
 26          <property name= " sessionFactory "  ref = " sessionFactory " />
 27      </bean>
 28      <!-- Annotated transaction support -->
 29      < tx:annotation-driven transaction-manager= " txManager "   order= " 0 " />
 30      <!-- Service transaction registration aspect -->
 31      <aop:config >
 32          <aop:pointcut expression="execution(* oddtech.service.impl.*.*(..))"
33             id="txPoint"  />
34         <aop:advisor advice-ref="txAdvice" pointcut-ref="txPoint"  order="1"/>
35     </aop:config>
36 
37     
38 
39 
40     <tx:advice transaction-manager="txManager" id="txAdvice">
41         <tx:attributes >
42             <tx:method name="find*" propagation="REQUIRED" read-only="true" 
43                 rollback-for="Exception" />
44             <tx:method name="select*" propagation="REQUIRED" read-only="true"
45                 rollback-for="Exception" />
46             <tx:method name="insert*" propagation="REQUIRED"  
47                 rollback-for="Exception" />
48             <tx:method name="delete*" propagation="REQUIRED"
49                 rollback-for="Exception" />
50             <tx:method name="update*" propagation="REQUIRED" 
51                 rollback-for="Exception" />
52             <tx:method name="modify*" propagation="REQUIRED"
53                 rollback-for="Exception" />
54             <tx:method name="*" read-only="true"
55                 rollback-for="Exception" />
56         </tx:attributes>
57     </tx:advice>

When @Transactional is used in a class (Test) and a method (insert) in the oddtech.service.impl package, it is equivalent to executing the AOP aspect twice in the new Test().insert() method. Then we need to define the order of execution of AOP aspects through the order attribute. The smaller the order is, the earlier it is in the AOP chain and the earlier it is executed. (chain mode)

So we need to add the order attribute to 0 in <tx:annotation-driven transaction-manager="txManager" order="0"/>, <aop:advisor advice-ref="txAdvice" pointcut-ref="txPoint" order ="1"/> The order attribute is added as 1. Then the execution order of the two of them is as follows:

. This belongs to transaction nesting .

Then let's look at the example mentioned above: when a class (Test) and a method (insert) in the oddtech.service.impl package use @Transactional, then we want the insert method to be read-only, read-only=true, Then we need to define it like this: @Transactional(readOnly = true,propagation=Propagation.REQUIRED), why?

In the statement transaction, we define the transaction propagation level of insert as: REQUIRED. For the transaction propagation level, please refer to http://blog.csdn.net/feng27156/article/details/8534609 , then we define REQUIRED in the annotation transaction 's affairs. Declare the transaction at the transaction level defined using the annotation.

Except in special cases, annotating transactions should not conflict with declaring transactions. Declaring transactions defines uniform rules. If you want a method to have a special transaction propagation mechanism, don't conflict with the uniform rules.

<tx:method name="*" read-only="true" rollback-for="Exception" />

According to the rules, define a test method and add: @Transactional definition. Then the test method is read-only=false, propagation=REQUIRED. This is the default. The unified rule <tx:method name="*" read-only="true" rollback-for="Exception" /> will not conflict with the annotation transaction of the test method.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324516106&siteId=291194637