Spring事务传递性探讨

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Spring事务传递性探讨相关的知识,希望对你有一定的参考价值。

本篇主要讨论下面几点获取【下载地址】  

一: Spring 事务的传递性介绍

二: 第三方调用含有事务的Service抛异常方法探讨

 

一: Spring 事务的传递性介绍

    事务传播行为,所谓事务的传播行为是指,如果在开始当前事务之前,一个事务上下文已经存在,此时有若干选项可以指定一个事务性方法的执行行为。在TransactionDefinition定义中包括了如下几个表示传播行为的常量:

    TransactionDefinition.PROPAGATION_REQUIRED:如果当前存在事务,则加入该事务;如果当前没有事务,则创建一个新的事务。

    TransactionDefinition.PROPAGATION_REQUIRES_NEW:创建一个新的事务,如果当前存在事务,则把当前事务挂起。

    TransactionDefinition.PROPAGATION_SUPPORTS:如果当前存在事务,则加入该事务;如果当前没有事务,则以非事务的方式继续运行。

    TransactionDefinition.PROPAGATION_NOT_SUPPORTED:以非事务方式运行,如果当前存在事务,则把当前事务挂起。

    TransactionDefinition.PROPAGATION_NEVER:以非事务方式运行,如果当前存在事务,则抛出异常。

    TransactionDefinition.PROPAGATION_MANDATORY:如果当前存在事务,则加入该事务;如果当前没有事务,则抛出异常。

    TransactionDefinition.PROPAGATION_NESTED:如果当前存在事务,则创建一个事务作为当前事务的嵌套事务来运行;如果当前没有事务,则该取值等价TransactionDefinition.PROPAGATION_REQUIRED。

    这里需要指出的是,前面的六种事务传播行为是 Spring 从 EJB 中引入的,他们共享相同的概念。而 PROPAGATION_NESTED是 Spring 所特有的。以 PROPAGATION_NESTED 启动的事务内嵌于外部事务中(如果存在外部事务的话),此时,内嵌事务并不是一个独立的事务,它依赖于外部事务的存在,只有通过外部的事务提交,才能引起内部事务的提交,嵌套的子事务不能单独提交。如果熟悉 JDBC 中的保存点(SavePoint)的概念,那嵌套事务就很容易理解了,其实嵌套的子事务就是保存点的一个应用,一个事务中可以包括多个保存点,每一个嵌套子事务。另外,外部事务的回滚也会导致嵌套子事务的回滚。

 

二: 第三方调用含有事务的Service抛异常方法探讨

    假设术语如下:调用方Conumer,  调用Service的methodA, methodA调用Service的 methodB

    a)methodA 传播属性为required, methodB传播属性为required, 代码如下

     

Java代码  技术分享

  1. public void methodA() {  

  2.     try {  

  3.        methodB();  

  4.     } catch(Exception e) {  

  5.        process();  

  6.     }  

  7.     otherOperation;  

  8. }  

 

    假设MethodB抛出异常,则Consumer调用MethodA会发生怎样的情形? 

    发现Consumer调用MethodA的时候出现了运行时异常,UnexpectedRollbackException: “Transaction rolled back because it has been marked as rollback-only”。这是为什么呢?

    网上搜索了下,终于发现了一个合理的解释。当MethodA调用MethodB的时候,且两个方法都为required属性,则methodA和methodB共享一个事务,当methodB抛出了异常,则共享事务回滚,但是被MethodA catch了,而MethodA又没有及时抛出异常,则MethodA正常执行到最后的时候,则会做提交事务的操作,但是事务已经被回滚了,所以才出现了上面的异常。

 

    既然这样,小弟就开始YY了一下,哪些情况会使调用方没有这个异常呢?经过与小伙伴们的思维碰撞,发现有一下几个方法。

   b) MethodA 不加事务,所以执行到最后就不会commit,SUPPORTS和NOT_SUPPORTED都可以实现这种功能。

   c) MethodB 设置不共享事务,拥有自己单独的事务。验证发现,REQUIRES_NEW可以实现这种功能。

   

   然后又YY了下,既然一个回滚的事务不能提交了,那么这个回滚的事务可以重复回滚吗?

   d) MethodA 调用MethodB,如果MethodA不catch MethodB,则调用方会怎么样?很简单当然直接捕获到MethodB的异常了,但是感觉这个场景不能完全反应初回滚的事务是否可以重复回滚。代码如下:

Java代码  技术分享

  1. public void methodA() {  

  2.     methodB();  

  3.     otherOperation;  

  4. }  

 

  e) 还有什么场景可以模拟回滚的事务是否可以再回滚呢?看,代码如下:

     

Java代码  技术分享

  1. public void methodA() {  

  2.     try {  

  3.        methodB();  

  4.     } catch(Exception e) {  

  5.        process();  

  6.     }  

  7.     try {  

  8.        methodB();  

  9.     } catch(Exception e) {  

  10.        process();  

  11.     }  

  12.     System.out.println("**************");  

  13.     otherOperation;  

  14. }  

   第一个MethodB已经回滚了共享的事务,第二个MethodB同样会抛出异常回滚共享的事务,如果执行了后面的System.out,则说明事务可以多次回滚。测试发现打印出来了后面的SysOut的内容,所以猜测可能是这样回滚事务的时候如果发现事务已经回滚,则直接跳过。


以上是关于Spring事务传递性探讨的主要内容,如果未能解决你的问题,请参考以下文章

Spring事务的隔离级别

Spring中的事务

「Spring」事务失效的场景

spring事务传播性理解

Spring 事务失效的7种场景

实战Spring事务传播性与隔离性