浅谈Spring嵌套事务是怎么回滚的

目录
  • 源码解析
    • TransactionAspectSupport.invokeWithinTransaction()
  • 内层事务
    • TransactionAspectSupport.completeTransactionAfterThrowing()
    • AbstractPlatformTransactionManager rollback()
    • DataSourceTransactionManager#doSetRollbackOnly
    • DataSourceTransactionObject#setRollbackOnly()
  • 外层事务
    • TransactionAspectSupport#commitTransactionAfterReturning()
    • AbstractPlatformTransactionManager#commit
    • DataSourceTransactionObject#isRollbackOnly()
  • 修正

更深入理解 Spring 事务。

用户注册完成后,需要给该用户登记一门PUA必修课,并更新该门课的登记用户数。
为此,我添加了两个表。
课程表 course,记录课程名称和注册的用户数。

用户选课表 user_course,记录用户表 user 和课程表 course 之间的多对多关联。

同时为课程表初始化了一条课程信息

接下来我们完成用户的相关操作,主要包括两部分:

新增用户选课记录

课程登记学生数 + 1

新增业务类 CourseService实现相关业务逻辑,分别调用了上述方法保存用户与课程的关联关系,并给课程注册人数+1

为避免注册课程的业务异常导致用户信息无法保存,这里 catch 注册课程方法中抛出的异常。希望当注册课程发生错误时,只回滚注册课程部分,保证用户信息依然正常。

为验证异常是否符合预期,在 regCourse() 里抛一个注册失败异常:

执行代码:

注册失败部分的异常符合预期,但是后面又多了一个这样的错误提示:Transaction rolled back because it has been marked as rollback-only

最后用户和选课的信息都被回滚了,显然这不符预期。
期待结果是即便内部事务regCourse()发生异常,外部事务saveStudent()俘获该异常后,内部事务应自行回滚,不影响外部事务。
这是什么原因造成的呢?

源码解析

伪代码梳理整个事务的结构:

整个业务包含2层事务:

  • 外层 saveUser() 的事务
  • 内层 regCourse() 事务

Spring声明式事务中的propagation属性,表示对这些方法使用怎样的事务,即:
一个带事务的方法调用了另一个带事务的方法,被调用的方法它怎么处理自己事务和调用方法事务之间的关系。

propagation 有7种配置:

  • REQUIRED:默认值,如果本来有事务,则加入该事务,如果没有事务,则创建新的事务。
  • SUPPORTS
  • MANDATORY
  • REQUIRES_NEW
  • NOT_SUPPORTED
  • NEVER
  • NESTED

因为:

  • 在 saveUser() 上声明了一个外部的事务,就已经存在一个事务了
  • 在propagation值为默认REQUIRED时

regCourse() 就会加入到已有的事务中,两个方法共用一个事务。

Spring 事务处理的核心:

TransactionAspectSupport.invokeWithinTransaction()

protected Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass,
      final InvocationCallback invocation) throws Throwable {

   TransactionAttributeSource tas = getTransactionAttributeSource();
   final TransactionAttribute txAttr = (tas != null ? tas.getTransactionAttribute(method, targetClass) : null);
   final PlatformTransactionManager tm = determineTransactionManager(txAttr);
   final String joinpointIdentification = methodIdentification(method, targetClass, txAttr);
   if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) {
      // 是否需要创建一个事务
      TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
      Object retVal = null;
      try {
         // 调用具体的业务方法
         retVal = invocation.proceedWithInvocation();
      }
      catch (Throwable ex) {
         // 当发生异常时进行处理
         completeTransactionAfterThrowing(txInfo, ex);
         throw ex;
      }
      finally {
         cleanupTransactionInfo(txInfo);
      }
      // 正常返回时提交事务
      commitTransactionAfterReturning(txInfo);
      return retVal;
   }
   //......省略非关键代码.....
}

整个方法完成了事务的一整套处理逻辑,如下:

  • 检查是否需要创建事务
  • 调用具体的业务方法进行处理
  • 提交事务
  • 处理异常

当前案例是两个事务嵌套,外层事务 saveUser()和内层事务 regCourse(),每个事务都会调用到这个方法。所以,该方法会被调两次。

内层事务

当捕获了异常,会调用

TransactionAspectSupport.completeTransactionAfterThrowing()

进行异常处理:

对异常类型做了一些检查,当符合声明中的定义后,执行具体的 rollback 操作,这个操作是通过如下方法完成:

AbstractPlatformTransactionManager rollback()

该回滚实现负责处理正参与到已有事务集的事务。委托执行Rollback和doSetRollbackOnly。

继续调用

processRollback()

该方法里区分了三种场景:

  • 是否有保存点
  • 是否为一个新的事务
  • 是否处于一个更大的事务中

因为默认传播类型REQUIRED,嵌套的事务并未开启一个新事务,所以属于当前事务处于一个更大事务中,所以会走到分支1。

如下的判断条件确定是否设置为仅回滚:

if (status.isLocalRollbackOnly() ||
	 isGlobalRollbackOnParticipationFailure())

满足任一,都会执行 doSetRollbackOnly():

isLocalRollbackOnly

默认 false,当前场景为 falseisGlobalRollbackOnParticipationFailure()

所以,就只由该方法来确定了,默认值为 true, 即是否回滚交由外层事务统一决定

条件得到满足,执行

DataSourceTransactionManager#doSetRollbackOnly

最终调用

DataSourceTransactionObject#setRollbackOnly()

内层事务操作执行完毕。

外层事务

外层事务中,业务代码就捕获了内层所抛异常,所以该异常不会继续往上抛,最后的事务会在 TransactionAspectSupport.invokeWithinTransaction() 中的

TransactionAspectSupport#commitTransactionAfterReturning()

该方法里执行了commit 操作:

AbstractPlatformTransactionManager#commit

当满足 !shouldCommitOnGlobalRollbackOnly() &&defStatus.isGlobalRollbackOnly(),就会回滚,否则继续提交事务:

shouldCommitOnGlobalRollbackOnly()
若发现事务被标记了全局回滚,且在发生全局回滚时,判断是否应该提交事务,这个方法的默认返回 false,这里无需关注

isGlobalRollbackOnly()

该方法最终进入

DataSourceTransactionObject#isRollbackOnly()

之前内部事务处理最终调用到DataSourceTransactionObject#setRollbackOnly()

public void setRollbackOnly() {
   getConnectionHolder().setRollbackOnly();
}
  • isRollbackOnly()
  • setRollbackOnly()

两个方法本质都是对ConnectionHolder.rollbackOnly属性标志位的存取
但ConnectionHolder则存在于DefaultTransactionStatus#transaction属性。

综上:外层事务是否回滚的关键,最终取决于DataSourceTransactionObject#isRollbackOnly(),该方法返回值正是在内层异常时设置的。
所以最终外层事务也被回滚,从而在控制台中打印上述日志。

这就明白了,Spring默认事务传播属性为REQUIRED:若已有事务,则加入该事务,若无事务,则创建新事务,因而内外两层事务都处于同一事务。
在 regCourse()中抛异常,并触发回滚操作时,这个回滚会继续传播,从而把 saveUser() 也回滚,最终整个事务都被回滚!

修正

Spring事务默认传播属性 REQUIRED,在整个事务的调用链上,任一环节抛异常都会导致全局回滚。

所以只需将传播属性改成 REQUIRES_NEW

运行:

异常正常抛出,注册课程部分的数据没有保存,但用户还是正常注册成功。这意味着此时Spring 只对注册课程这部分的数据进行了回滚,并没有传播到外层:

当子事务声明为 Propagation.REQUIRES_NEW 时,在 TransactionAspectSupport.invokeWithinTransaction() 中调用 createTransactionIfNecessary() 就会创建一个新的事务,独立于外层事务而在 AbstractPlatformTransactionManager.processRollback() 进行 rollback 处理时,因为 status.isNewTransaction() 会因为它处于一个新的事务中而返回 true,所以它走入到了另一个分支,执行了 doRollback() 操作,让这个子事务单独回滚,不会影响到主事务。

到此这篇关于浅谈Spring嵌套事务是怎么回滚的的文章就介绍到这了,更多相关Spring嵌套事务回滚内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Java Spring 事务回滚详解

    spring 事务回滚 1.遇到的问题 当我们一个方法里面有多个数据库保存操作的时候,中间的数据库操作发生的错误.伪代码如下: public method() { Dao1.save(Person1); Dao1.save(Person2); Dao1.save(Person2);//假如这句发生了错误,前面的两个对象会被保存到数据库中 Dao1.save(Person2); } 期待的情况:发生错误之前的所有数据库保存操作都回滚,即不保存 正常情况:前面的数据库操作会被执行,而发生数据库操作错

  • spring事务异常回滚实例解析

    最近遇到了事务不回滚的情况,我还考虑说JPA的事务有bug?我想多了....... 为了打印清楚日志,很多方法我都加tyrcatch,在catch中打印日志.但是这边情况来了,当这个方法异常时候日志是打印了,但是加的事务却没有回滚. 例: 类似这样的方法不会回滚(一个方法出错,另一个方法不会回滚): if(userSave){ try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (Exce

  • SpringBoot事务使用及回滚实现代码详解

    Springboot中事务的使用: 1.启动类加上@EnableTransactionManagement注解,开启事务支持(其实默认是开启的). 2.在使用事务的public(只有public支持事务)方法(或者类-相当于该类的所有public方法都使用)加上@Transactional注解. 在实际使用中一般是在service中使用@Transactional,那么对于controller->service流程中: 如果controller未开启事务,service中开始了事务,servic

  • Spring事务管理只对出现运行期异常进行回滚

    一.结论 Spring的事务管理默认只对出现运行期异常(java.lang.RuntimeException及其子类)进行回滚. 如果一个方法抛出Exception或者Checked异常,Spring事务管理默认不进行回滚. 关于异常的分类一下详细介绍: 1.基本概念 看java的异常结构图  Throwable是所有异常的根,java.lang.Throwable Error是错误,java.lang.Error Exception是异常,java.lang.Exception 2.Excep

  • 使用SpringBoot注解方式处理事务回滚实现

    我们在SpringBoot和MyBatis整合的时候,需要在SpringBoot中通过注解方式配置事务回滚 1 Pojo类 package com.zxf.domain; import java.util.Date; public class User { private Integer id; private String name; private String pwd; private String head_img; private String phone; private Date

  • Spring异常捕获且回滚事务解决方案

    默认spring只在发生未被捕获的runtimeexcetpion时才回滚. 最笨的办法:代码级控制:TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); 为何在aop advitor中配置rollba-for="java.lang.Exception"异常时不回滚呢? 问题已解决: 原理:spring aop 异常捕获原理:被拦截的方法需显式抛出异常,并不能经任何处理,这样aop代理才能捕获到方法

  • 完美解决Spring声明式事务不回滚的问题

    疑问,确实像往常一样在service上添加了注解 @Transactional,为什么查询数据库时还是发现有数据不一致的情况,想想肯定是事务没起作用,出现异常的时候数据没有回滚.于是就对相关代码进行了一番测试,结果发现一下踩进了两个坑,确实是事务未回滚导致的数据不一致. 下面总结一下经验教训: Spring事务的管理操作方法 编程式的事务管理 实际应用中很少使用 通过使用TransactionTemplate 手动管理事务 声明式的事务管理 开发中推荐使用(代码侵入最少) Spring的声明式事

  • springboot手动事务回滚的实现代码

    亲测在使用@Transactional.@Transactional(rollbackFor = Exception.class)及catch异常之后 throw new RuntimeException();仍然不能解决线程中的事务回滚.下面使用线程所机制,进行整体的事务提交及事务回滚,代码如下: 在springboot启动类上加  @EnableTransactionManagement  注解 线程类中添加以下代码 @Autowired private PlatformTransactio

  • 浅谈Spring嵌套事务是怎么回滚的

    目录 源码解析 TransactionAspectSupport.invokeWithinTransaction() 内层事务 TransactionAspectSupport.completeTransactionAfterThrowing() AbstractPlatformTransactionManager rollback() DataSourceTransactionManager#doSetRollbackOnly DataSourceTransactionObject#setRo

  • 浅谈Spring中@Transactional事务回滚及示例(附源码)

    一.使用场景举例 在了解@Transactional怎么用之前我们必须要先知道@Transactional有什么用.下面举个栗子:比如一个部门里面有很多成员,这两者分别保存在部门表和成员表里面,在删除某个部门的时候,假设我们默认删除对应的成员.但是在执行的时候可能会出现这种情况,我们先删除部门,再删除成员,但是部门删除成功了,删除成员的时候出异常了.这时候我们希望如果成员删除失败了,之前删除的部门也取消删除.这种场景就可以使用@Transactional事物回滚. 二.checked异常和unc

  • 浅谈spring 常用注解

    我们不妨先将spring常用的注解按照功能进行分类 1 .将普通类加入容器形成Bean的注解 日常开发中主要使用到的定义Bean的注解包括(XML方式配置bean暂不讨论): @Component.@Repository.@Service.@Controller.@Bean 其中@Component.@Repository.@Service.@Controller实质上属于同一类注解,用法相同,功能相同,区别在于标识组件的类型.当一个组件代表数据访问层(Dao)时,你可以给它加上@Reposit

  • 浅谈Spring的两种事务定义方式

    一.声明式 这种方法不需要对原有的业务做任何修改,通过在XML文件中定义需要拦截方法的匹配即可完成配置,要求是,业务处理中的方法的命名要有规律,比如setXxx,xxxUpdate等等.详细配置如下: <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="

  • 浅谈spring中isolation和propagation的用法

    可以在XML文件中进行配置,下面的代码是个示意代码 <tx:advice id="txAdvice" transaction-manager="txManager"> <tx:attributes> <tx:method name="add*" propagation="REQUIRED" isolation="READ_COMMITTED"/>增加记录的方法 <t

  • 浅谈spring容器中bean的初始化

    当我们在spring容器中添加一个bean时,如果没有指明它的scope属性,则默认是singleton,也就是单例的. 例如先声明一个bean: public class People { private String name; private String sex; public String getName() { return name; } public void setName(String name) { this.name = name; } public String get

  • 浅谈Spring的两种配置容器

    Spring提供了两种容器类型 SpringIOC容器是一个IOC Service Provider.提供了两种容器类型:BeanFactory和ApplicationContext.Spring的IOC容器是一个提供IOC支持的轻量级容器.除了基本的ioc支持,它作为轻量级容器还提供了IOC之外的支持. BeanFactory BeanFactory是基础类型IOC容器.顾名思义,就是生产Bean的工厂.能够提供完整的IOC服务.没有特殊指定的话,其默认采用延迟初始化策略.只有当客户端对象需要

  • 浅谈spring中用到的设计模式及应用场景

    1.工厂模式,在各种BeanFactory以及ApplicationContext创建中都用到了 2.模版模式,在各种BeanFactory以及ApplicationContext实现中也都用到了 3.代理模式,Spring AOP 利用了 AspectJ AOP实现的! AspectJ AOP 的底层用了动态代理 动态代理有两种 目标方法有接口时候自动选用 JDK 动态代理 目标方法没有接口时候选择 CGLib 动态代理 4.策略模式,加载资源文件的方式,使用了不同的方法,比如:ClassPa

  • 浅谈spring中的default-lazy-init参数和lazy-init

    在spring的配置中的根节点上有个  default-lazy-init="true"配置: 1.spring的default-lazy-init参数 此参数表示延时加载,即在项目启动时不会实例化注解的bean,除非启动项目时需要用到,未实例化的注解对象在程序实际访问调用时才注入调用 spring在启动的时候,default-lazy-init参数默认为false,会默认加载整个对象实例图,从初始化ACTION配置.到 service配置到dao配置.乃至到数据库连接.事务等等.这样

  • 浅谈spring和spring MVC的区别与关系

    spring是一个开源框架,功能主要是依赖注入和控制反转. 依赖注入有三种形式 1.构造注入(bytype) 2.setter注入 3.接口注入(byname) 而控制反转则主要是起到操控作用,把对象的创建,初始化,销毁交给spring容器来处理.面向切面(把功能分离出来)实现共用. spring MVC类似于struts是负责前台和后台的交互,还有就是spring可以集成许多工具,像数据库配置,缓存配置,定时器配置等等都是在spring中完成的,而spring MVC是做不到的. 以上这篇浅谈

随机推荐