浅谈spring aop 控制下的事物 Dk-CSDN博客

本文链接：https://blog.csdn.net/it304/article/details/53006455

听说过spring的都知道spring有个aop,确实好用,事物基本上都是由aop切入的(注意:aop只是提供切入功能,事物并不是spring aop提供的)

随便找一个事物的框架吧,例如 hibernate?

<bean id="txManager"
		class="org.springframework.orm.hibernate4.HibernateTransactionManager">
		<property name="sessionFactory" ref="sessionFactory" />
	</bean>
	
<tx:annotation-driven transaction-manager="txManager" />

再来看看怎么切得 :

首先,作用的方法名:

</pre><pre name="code" class="html"><tx:advice id="txAdvice" transaction-manager="txManager">
		<tx:attributes>
			<tx:method name="query*" propagation="REQUIRED" />
	       	<span style="white-space:pre">	</span><tx:method name="update*" propagation="REQUIRED"  />
			<tx:method name="add*" propagation="REQUIRED"  />
			<tx:method name="del*" propagation="REQUIRED" />
			<tx:method name="save*" propagation="REQUIRED" />
			<tx:method name="edit*" propagation="REQUIRED" />
			<tx:method name="ceadd*" propagation="REQUIRED" />
            <span style="white-space:pre">		</span><tx:method name="downloadadd*" propagation="REQUIRED" />
            <span style="white-space:pre">		</span><tx:method name="*" propagation="REQUIRED" rollback-for="Exception"/>
		</tx:attributes>
	</tx:advice>

然后是切入的属性(私有?公有? 空格为所有) 包类方法(参数)

<aop:config>
		<aop:pointcut expression="execution(public * com.aaa.bbb..*.*(..))" id="bussinessService" />
		<aop:advisor pointcut-ref="bussinessService" advice-ref="txAdvice" />
	</aop:config>

细心的小伙伴已经发现了既然有这条

<tx:method name="*" propagation="REQUIRED" rollback-for="Exception"/>

要上面的干嘛?

好吧,他的匹配是由上而下的,当他找到上面的了,就不会找下面的了......很强大,但是!!!!!!!!!

是不是每一个方法都特么就有事物了??????????????????????????????????????? 贼烦

有时候,根据业务逻辑,事物自己控制比较好,下面介绍一种在spring 切入的事物下如果手动控制

        @Resource
	private ApplicationContext applicationContext; //注入spring上下文处理类

        HibernateTransactionManager txManager = (HibernateTransactionManager) applicationContext.getBean("txManager");  //这个id是xml中bean的id
	DefaultTransactionDefinition def = null;
	TransactionStatus txStatus = null;
	def = new DefaultTransactionDefinition();
	def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);// 事物隔离级别，开启新事务
	txStatus = txManager.getTransaction(def);// 获得事务状态
	txManager.commit(txStatus);  //提交
	txManager.rollback(txStatus); //回滚

其实就是把原有事物挂起,新开一个事物,

TransactionDefinition.PROPAGATION_REQUIRES_NEW

这个用来藐视事物的类型,全部类型有

PROPAGATION_REQUIRED--支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。

PROPAGATION_SUPPORTS--支持当前事务，如果当前没有事务，就以非事务方式执行。

PROPAGATION_MANDATORY--支持当前事务，如果当前没有事务，就抛出异常。

PROPAGATION_REQUIRES_NEW--新建事务，如果当前存在事务，把当前事务挂起。

PROPAGATION_NOT_SUPPORTED--以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。

PROPAGATION_NEVER--以非事务方式执行，如果当前存在事务，则抛出异常。

PROPAGATION_NESTED--如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似的操作。

解释一下 PROPAGATION_NESTED和PROPAGATION_REQUIRES_NEW

PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 "内部" 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行.

另一方面, PROPAGATION_NESTED 开始一个 "嵌套的" 事务, 它是已经存在事务的一个真正的子事务. 潜套事务开始执行时, 它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交.

由此可见, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于, PROPAGATION_REQUIRES_NEW 完全是一个新的事务, 而 PROPAGATION_NESTED 则是外部事务的子事务, 如果外部事务 commit, 潜套事务也会被 commit, 这个规则同样适用于 roll back.

原文 Juergen Hoeller

Rolling back the entire transaction is the choice of the demarcation code/config that started the outer

transaction. 
So if an inner transaction throws an exception and is supposed to be rolled back (according to the rollback rules)

, the transaction will get rolled back to the savepoint taken at the start of the inner transaction.

The immediate calling code can then decide to catch the exception and proceed down some other path within the

outer transaction. 
If the code that called the inner transaction lets the exception propagate up the call chain, the exception will

eventually reach the demarcation code of the outer transaction. At that point, the rollback rules of the outer

transaction decide whether to trigger a rollback. That would be a rollback of the entire outer transaction then. 
So essentially, it depends on your exception handling. If you catch the exception thrown by the inner

 transaction, you can proceed down some other path within the outer transaction.

If you let the exception propagate up the call chain, it's eventually gonna cause a rollback of

the entire outer transaction.