SpringBoot中事务执行原理分析(五)

简介: SpringBoot中事务执行原理分析(五)

我们分析过方法正常执行完事务提交后,本文我们继续分析目标方法抛出异常后事务的回滚流程,即 completeTransactionAfterThrowing(txInfo, ex)。


TransactionAspectSupport的completeTransactionAfterThrowing方法如下。

protected void completeTransactionAfterThrowing(@Nullable TransactionInfo txInfo, Throwable ex) {
//如果事务信息对象或者事务状态对象为空,则不作处理
  if (txInfo != null && txInfo.getTransactionStatus() != null) {
    if (logger.isTraceEnabled()) {
      logger.trace("Completing transaction for [" + txInfo.getJoinpointIdentification() +
          "] after exception: " + ex);
    }
    //判断当前异常类型是否需要回滚
    if (txInfo.transactionAttribute != null && txInfo.transactionAttribute.rollbackOn(ex)) {
      try {
      //回滚动作的触发--交给事务管理器
        txInfo.getTransactionManager().rollback(txInfo.getTransactionStatus());
      }
      catch (TransactionSystemException ex2) {
        logger.error("Application exception overridden by rollback exception", ex);
        ex2.initApplicationException(ex);
        throw ex2;
      }
      catch (RuntimeException | Error ex2) {
        logger.error("Application exception overridden by rollback exception", ex);
        throw ex2;
      }
    }
    else {
      // We don't roll back on this exception.
      // Will still roll back if TransactionStatus.isRollbackOnly() is true.
      try {
      //如果当前异常类型不需要回滚,则直接触发提交动作
        txInfo.getTransactionManager().commit(txInfo.getTransactionStatus());
      }
      catch (TransactionSystemException ex2) {
        logger.error("Application exception overridden by commit exception", ex);
        ex2.initApplicationException(ex);
        throw ex2;
      }
      catch (RuntimeException | Error ex2) {
        logger.error("Application exception overridden by commit exception", ex);
        throw ex2;
      }
    }
  }
}

这里首先对事务信息对象和事务状态对象做了判断,如果其中有一个为 null 则直接跳过不做处理。然后对异常类型做了判断,判断当前异常类型时触发 rollback 还是 commit动作。关于commit动作我们前面已经分析过了,本文我们分析rollback动作。


AbstractPlatformTransactionManager的rollback方法

@Override
public final void rollback(TransactionStatus status) throws TransactionException {
//判断事务状态是否为已完成,已完成则抛出异常
  if (status.isCompleted()) {
    throw new IllegalTransactionStateException(
        "Transaction is already completed - do not call commit or rollback more than once per transaction");
  }
  DefaultTransactionStatus defStatus = (DefaultTransactionStatus) status;
  //交给了processRollback
  processRollback(defStatus, false);
}


可以看到其rollback方法只是对status做了是否已经完成的状态校验,然后交给了processRollback方法。

AbstractPlatformTransactionManager的processRollback方法。

private void processRollback(DefaultTransactionStatus status, boolean unexpected) {
  try {
  //初值false 
    boolean unexpectedRollback = unexpected;
    try {
    //遍历触发TransactionSynchronization的beforeCompletion方法
      triggerBeforeCompletion(status);
//如果有savepoint则首先回滚到savepoint位置然后释放savepoint
      if (status.hasSavepoint()) {
        if (status.isDebug()) {
          logger.debug("Rolling back transaction to savepoint");
        }
        status.rollbackToHeldSavepoint();
      }
//如果事务是新事务,则触发rollBack动作
      else if (status.isNewTransaction()) {
        if (status.isDebug()) {
          logger.debug("Initiating transaction rollback");
        }
        doRollback(status);
      }
      //如果当前事务是一个已经存在的事务
      else {
        // Participating in larger transaction
        if (status.hasTransaction()) {
          if (status.isLocalRollbackOnly() || isGlobalRollbackOnParticipationFailure()) {
            if (status.isDebug()) {
              logger.debug("Participating transaction failed - marking existing transaction as rollback-only");
            }
            //修改rollbackOnly状态为true
            doSetRollbackOnly(status);
          }
          else {
            if (status.isDebug()) {
              logger.debug("Participating transaction failed - letting transaction originator decide on rollback");
            }
          }
        }
        else {
          logger.debug("Should roll back transaction but cannot - no transaction available");
        }
        // Unexpected rollback only matters here if we're asked to fail early
        if (!isFailEarlyOnGlobalRollbackOnly()) {
          unexpectedRollback = false;
        }
      }
    }
    catch (RuntimeException | Error ex) {
//遍历触发TransactionSynchronization 的afterCompletion  状态是STATUS_UNKNOWN
      triggerAfterCompletion(status, TransactionSynchronization.STATUS_UNKNOWN);
      throw ex;
    }
//遍历触发TransactionSynchronization 的afterCompletion  状态是STATUS_ROLLED_BACK
    triggerAfterCompletion(status, TransactionSynchronization.STATUS_ROLLED_BACK);
    // Raise UnexpectedRollbackException if we had a global rollback-only marker
    if (unexpectedRollback) {
      throw new UnexpectedRollbackException(
          "Transaction rolled back because it has been marked as rollback-only");
    }
  }
  finally {
  // 完成后清理事务信息
    cleanupAfterCompletion(status);
  }
}

方法流程梳理如下:


遍历触发TransactionSynchronization的beforeCompletion方法

如果有savepoint则首先回滚到savepoint位置然后释放savepoint

如果事务是新事务,则触发rollBack动作

如果当前事务是一个已经存在的事务,则可能设置事务状态rollbackOnly为true

遍历触发TransactionSynchronization 的afterCompletion

完成后清理事务信息-cleanupAfterCompletion

可以看到,这里同前文提交分析流程类型,同样触发了TransactionSynchronization的钩子函数,对事务进行了判断处理最后清理事务资源。


cleanupAfterCompletion同前文一致,TransactionSynchronization我们另起篇章分析。我们接下来看下核心方法doRollback(status);。


DataSourceTransactionManager的doRollback方法

@Override
protected void doRollback(DefaultTransactionStatus status) {
  DataSourceTransactionObject txObject = (DataSourceTransactionObject) status.getTransaction();
  Connection con = txObject.getConnectionHolder().getConnection();
  if (status.isDebug()) {
    logger.debug("Rolling back JDBC transaction on Connection [" + con + "]");
  }
  try {
    con.rollback();
  }
  catch (SQLException ex) {
    throw new TransactionSystemException("Could not roll back JDBC transaction", ex);
  }
}


方法如上所示其从事务对象里面获取到连接对象,然后触发数据库连接对象的rollback方法。


本文这里获取到的数据库连接对象是:HikariProxyConnection@2062395789 wrapping com.mysql.cj.jdbc.ConnectionImpl@12ee6186。可以看到其内有委派对象delegate=ConnectionImpl


36337dd0d3b1489b95b393dcdf9a857e.png

ProxyConnection 的rollback方法

@Override
public void rollback() throws SQLException
{
   delegate.rollback();
   isCommitStateDirty = false;
   lastAccess = currentTime();
}


再往下就交给了MySQL驱动来实现这个功能,如下所示,其最终触发了this.session.execSQL(null, "rollback", -1, null, false, this.nullStatementResultSetFactory, null, false);



目录
相关文章
|
2月前
|
安全 NoSQL Java
SpringBoot接口安全:限流、重放攻击、签名机制分析
本文介绍如何在Spring Boot中实现API安全机制,涵盖签名验证、防重放攻击和限流三大核心。通过自定义注解与拦截器,结合Redis,构建轻量级、可扩展的安全防护方案,适用于B2B接口与系统集成。
503 3
|
2月前
|
人工智能 Java 开发者
【Spring】原理解析:Spring Boot 自动配置
Spring Boot通过“约定优于配置”的设计理念,自动检测项目依赖并根据这些依赖自动装配相应的Bean,从而解放开发者从繁琐的配置工作中解脱出来,专注于业务逻辑实现。
|
4月前
|
Java Spring 容器
SpringBoot自动配置的原理是什么?
Spring Boot自动配置核心在于@EnableAutoConfiguration注解,它通过@Import导入配置选择器,加载META-INF/spring.factories中定义的自动配置类。这些类根据@Conditional系列注解判断是否生效。但Spring Boot 3.0后已弃用spring.factories,改用新格式的.imports文件进行配置。
887 0
|
1月前
|
JavaScript Java Maven
【SpringBoot(二)】带你认识Yaml配置文件类型、SpringMVC的资源访问路径 和 静态资源配置的原理!
SpringBoot专栏第二章,从本章开始正式进入SpringBoot的WEB阶段开发,本章先带你认识yaml配置文件和资源的路径配置原理,以方便在后面的文章中打下基础
274 3
|
1月前
|
XML Java 应用服务中间件
【SpringBoot(一)】Spring的认知、容器功能讲解与自动装配原理的入门,带你熟悉Springboot中基本的注解使用
SpringBoot专栏开篇第一章,讲述认识SpringBoot、Bean容器功能的讲解、自动装配原理的入门,还有其他常用的Springboot注解!如果想要了解SpringBoot,那么就进来看看吧!
358 2
|
4月前
|
前端开发 Java 数据库连接
SpringBoot参数校验底层原理和实操。深度历险、深度解析(图解+秒懂+史上最全)
SpringBoot参数校验底层原理和实操。深度历险、深度解析(图解+秒懂+史上最全)
SpringBoot参数校验底层原理和实操。深度历险、深度解析(图解+秒懂+史上最全)
|
3月前
|
JavaScript Java 应用服务中间件
基于springboot的学生成绩分析和弱项辅助系统
本系统旨在解决学生成绩分析与弱项辅助信息管理效率低下的问题,通过软件技术实现数据处理的高效化、流程化与规范化,提升管理质量与便捷性。
|
4月前
|
XML 人工智能 IDE
Springboot整合SSMP报错分析
本文介绍了Springboot整合SSMP框架时常见的报错及解决方案,包括MyBatis-Plus版本不兼容导致的Lambda表达式条件构造器报错及表名不匹配问题。通过升级或降级MyBatis-Plus版本、使用@TableName注解或配置table-prefix属性,可有效解决上述问题,帮助开发者避免在整合SSMP时出现不必要的错误。
263 0
|
7月前
|
SQL 前端开发 Java
深入分析 Spring Boot 项目开发中的常见问题与解决方案
本文深入分析了Spring Boot项目开发中的常见问题与解决方案,涵盖视图路径冲突(Circular View Path)、ECharts图表数据异常及SQL唯一约束冲突等典型场景。通过实际案例剖析问题成因,并提供具体解决方法,如优化视图解析器配置、改进数据查询逻辑以及合理使用外键约束。同时复习了Spring MVC视图解析原理与数据库完整性知识,强调细节处理和数据验证的重要性,为开发者提供实用参考。
332 0
|
7月前
|
安全 前端开发 Java
Spring Boot 项目中触发 Circular View Path 错误的原理与解决方案
在Spring Boot开发中,**Circular View Path**错误常因视图解析与Controller路径重名引发。当视图名称(如`login`)与请求路径相同,Spring MVC无法区分,导致无限循环调用。解决方法包括:1) 明确指定视图路径,避免重名;2) 将视图文件移至子目录;3) 确保Spring Security配置与Controller路径一致。通过合理设定视图和路径,可有效避免该问题,确保系统稳定运行。
514 0