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

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

本文我们分析一下事务处理过程中的事务同步管理器TransactionSynchronizationManager与事务同步对象TransactionSynchronization

【1】事务同步管理器


这里指的是TransactionSynchronizationManager。管理每个线程的资源和事务同步的中央委托。


通常用于资源管理代码,但不用于应用程序代码。其支持一个资源一个key,不支持覆盖。也就是说即使对于同一个key,资源的更新只能是先remove后set。如果synchronization是激活的,那么支持多个事务同步对象。


资源管理代码应该通过 getResource 检查线程绑定的资源,例如JDBC连接或Hibernate会话。这种代码通常不应该将资源绑定到线程,因为这是事务管理器的责任。另一种选择是,如果事务同步处于活动状态,则在首次使用时延迟绑定,以执行跨越任意数量资源的事务。


事务同步必须由事务管理器通过initSynchronization()和clearSynchronization()进行激活和停用。这由 AbstractPlatformTransactionManager 自动支持,因此所有标准的Spring事务管理器自动支持,例如org.springframework.transaction.jta.JtaTransactionManager和org.springframework.jdbc.datasource.DataSourceTransactionManager。


资源管理代码只应在该管理器处于活动状态时注册事务同步对象,可以通过isSynchronizationActive进行检查;否则非活动状态它应该立即执行资源清理。如果事务同步未处于活动状态,则表示当前没有事务,或者事务管理器不支持事务同步。


举例来说事务同步用于在JTA事务中始终返回相同的资源,例如,对于任何给定的数据源DataSource或SessionFactory,分别返回JDBC Connection或Hibernate Session。


如下所示在TransactionSynchronizationManager中持有了几个静态常量ThreadLocal对象。

public abstract class TransactionSynchronizationManager {
     //线程上下文中保存着【DataSource:ConnectionHolder】的Map对象。线程可以通过该属性获取到同一个Connection对象。
    private static final ThreadLocal<Map<Object, Object>> resources = new NamedThreadLocal<>("Transactional resources");
    //事务同步器,是Spring交由程序员进行扩展的代码,每个线程可以注册N个事务同步器。
    //这是一个Set哦
    private static final ThreadLocal<Set<TransactionSynchronization>> synchronizations = new NamedThreadLocal<>("Transaction synchronizations");
    // 保存当前事务的名称  
    private static final ThreadLocal<String> currentTransactionName = new NamedThreadLocal<>("Current transaction name");
    // 保存只读状态-- 当前事务是否是只读  
    private static final ThreadLocal<Boolean> currentTransactionReadOnly = new NamedThreadLocal<>("Current transaction read-only status");
    // 保存当前事务的隔离级别
    private static final ThreadLocal<Integer> currentTransactionIsolationLevel = new NamedThreadLocal<>("Current transaction isolation level");
    // 保存标志 - 事务是否开启
    private static final ThreadLocal<Boolean> actualTransactionActive = new NamedThreadLocal<>("Actual transaction active");
}


该资源管理器还提供了许多资源管理、事务名称|状态等的管理,其中对资源管理的核心方法则是bindResource(绑定资源)和doUnbindResource(解绑资源)

绑定资源


如下所示,其尝试从线程上下文本地对象resources中获取map,如果map为null则实例化map并放入Object key, Object value

//这里key通常是DataSource
public static void bindResource(Object key, Object value) throws IllegalStateException {
  Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary(key);
  Assert.notNull(value, "Value must not be null");
  Map<Object, Object> map = resources.get();
  // set ThreadLocal Map if none found
  if (map == null) {
    map = new HashMap<>();
    resources.set(map);
  }
  Object oldValue = map.put(actualKey, value);
  // Transparently suppress a ResourceHolder that was marked as void...
  if (oldValue instanceof ResourceHolder && ((ResourceHolder) oldValue).isVoid()) {
    oldValue = null;
  }
  if (oldValue != null) {
    throw new IllegalStateException("Already value [" + oldValue + "] for key [" +
        actualKey + "] bound to thread [" + Thread.currentThread().getName() + "]");
  }
  if (logger.isTraceEnabled()) {
    logger.trace("Bound value [" + value + "] for key [" + actualKey + "] to thread [" +
        Thread.currentThread().getName() + "]");
  }
}


解绑资源

如下所示简单来讲就是其从线程本地对象resources中获取map,从中移除actualKey并返回。

private static Object doUnbindResource(Object actualKey) {
  Map<Object, Object> map = resources.get();
  if (map == null) {
    return null;
  }
  Object value = map.remove(actualKey);
  // Remove entire ThreadLocal if empty...
  if (map.isEmpty()) {
    resources.remove();
  }
  // Transparently suppress a ResourceHolder that was marked as void...
  if (value instanceof ResourceHolder && ((ResourceHolder) value).isVoid()) {
    value = null;
  }
  if (value != null && logger.isTraceEnabled()) {
    logger.trace("Removed value [" + value + "] for key [" + actualKey + "] from thread [" +
        Thread.currentThread().getName() + "]");
  }
  return value;
}


【2】事务同步对象

在前面我们分析提交或者回滚过程中,常常看到beforeCommit、beforeCompletion、afterCommit以及afterCompletion这几个钩子函数。其就是TransactionSynchronization 提供的,用来在事务提交/回滚前后做一些处理工作。

public interface TransactionSynchronization extends Flushable {
  // 正确提交时的完成状态
  int STATUS_COMMITTED = 0;
  // 正确回滚时的完成状态
  int STATUS_ROLLED_BACK = 1;
//启发式混合完成或系统错误情况下
  int STATUS_UNKNOWN = 2;
   //挂起同步,如果TransactionSynchronizationManager 有管理资源则接触资源绑定
  default void suspend() {
  }
   //恢复同步,如果事务同步管理器有管理资源则重新绑定
  default void resume() {
  }
//   如果适用,将底层会话刷新到数据存储:例如,Hibernate/JPA会话。
  @Override
  default void flush() {
  }
   //在事务提交前触发 RuntimeException 将会传播给调用方,
   //不要在此处抛出TransactionException的子类
  default void beforeCommit(boolean readOnly) {
  }
   //在事务提交/回滚前触发
  default void beforeCompletion() {
  }
   //事务成功提交后触发
  default void afterCommit() {
  }
   //在事务提交/回滚后触发
  default void afterCompletion(int status) {
  }
}

beforeCommit

在事务提交之前(在“完成之前”)调用。例如,可以将事务性O/R映射会话刷新到数据库。


此回调并不意味着事务将实际提交。调用此方法后,仍可能发生回滚决策。这种回调是为了执行只有在提交仍然有机会发生时才相关的工作,例如将SQL语句刷新到数据库。


请注意,异常将传播到提交调用方,并导致事务回滚。

beforeCompletion


在事务提交/回滚之前调用。可以在事务完成之前执行资源清理。

即使beforeCommit引发异常,此方法也将在beforeCommit之后调用。此回调允许在事务完成之前关闭资源,以获得任何结果。


afterCommit

在事务提交后调用。在主事务成功提交后,可以立即执行进一步的操作。例如,可以在主事务成功提交后应执行的进一步操作,如确认消息或电子邮件。


事务已经提交,但事务资源可能仍然处于活动状态并且可以访问。因此,此时触发的任何数据访问代码仍将“参与”原始事务,允许执行一些清理(不再执行提交!),除非它明确声明需要在单独的事务中运行。因此:对于从这里调用的任何事务操作,使用PROPAGATION_REQUIRES_NEW。

afterCompletion


在事务提交/回滚后调用。可以在事务完成后执行资源清理。


与afterCommit相同的是,这里事务已经提交(或者回滚),但事务资源可能仍然处于活动状态并且可以访问。因此,此时触发的任何数据访问代码仍将“参与”原始事务,允许执行一些清理(不再执行提交!),除非它明确声明需要在单独的事务中运行。因此:对于从这里调用的任何事务操作,使用PROPAGATION_REQUIRES_NEW。

【3】SqlSessionSynchronization

SqlSessionSynchronization是SqlSessionUtils的静态内部类,继承自TransactionSynchronizationAdapter,后置实现了TransactionSynchronization接口。


我们以SqlSessionSynchronizationw为例分析其做了哪些事情。

private static final class SqlSessionSynchronization extends TransactionSynchronizationAdapter {
//持有SqlSession
  private final SqlSessionHolder holder;
  private final SqlSessionFactory sessionFactory;
  private boolean holderActive = true;
  public SqlSessionSynchronization(SqlSessionHolder holder, SqlSessionFactory sessionFactory) {
    notNull(holder, "Parameter 'holder' must be not null");
    notNull(sessionFactory, "Parameter 'sessionFactory' must be not null");
    this.holder = holder;
    this.sessionFactory = sessionFactory;
  }
   //获取其执行顺序
  @Override
  public int getOrder() {
    // order right before any Connection synchronization
    return DataSourceUtils.CONNECTION_SYNCHRONIZATION_ORDER - 1;
  }
   // 挂起,实际是解除资源绑定,这里key就是this.sessionFactory
  @Override
  public void suspend() {
    if (this.holderActive) {
      LOGGER.debug(() -> "Transaction synchronization suspending SqlSession [" + this.holder.getSqlSession() + "]");
      TransactionSynchronizationManager.unbindResource(this.sessionFactory);
    }
  }
   //恢复,实际是绑定资源,key -sessionFactory ,value - holder
  @Override
  public void resume() {
    if (this.holderActive) {
      LOGGER.debug(() -> "Transaction synchronization resuming SqlSession [" + this.holder.getSqlSession() + "]");
      TransactionSynchronizationManager.bindResource(this.sessionFactory, this.holder);
    }
  }
//核心是触发sqlsession的commit
  @Override
  public void beforeCommit(boolean readOnly) {
    // Connection commit or rollback will be handled by ConnectionSynchronization or
    // DataSourceTransactionManager.
    // But, do cleanup the SqlSession / Executor, including flushing BATCH statements so
    // they are actually executed.
    // SpringManagedTransaction will no-op the commit over the jdbc connection
    // TODO This updates 2nd level caches but the tx may be rolledback later on!
    //如果线程本地对象actualTransactionActive 储存资源不为null
    if (TransactionSynchronizationManager.isActualTransactionActive()) {
      try {
      //触发sqlsession的commit,将会清理本地缓存,flushStatements
        this.holder.getSqlSession().commit(); 
      } catch (PersistenceException p) {
        if (this.holder.getPersistenceExceptionTranslator() != null) {
          DataAccessException translated = this.holder.getPersistenceExceptionTranslator()
              .translateExceptionIfPossible(p);
          if (translated != null) {
            throw translated;
          }
        }
        throw p;
      }
    }
  }
//如果referenceCount小于1,则关闭SqlSession,重置holder、holderActive 
  @Override
  public void beforeCompletion() {
    // Issue #18 Close SqlSession and deregister it now
    // because afterCompletion may be called from a different thread
    //也就是referenceCount小于1
    if (!this.holder.isOpen()) {
  //解除资源绑定,key是sessionFactory
      TransactionSynchronizationManager.unbindResource(sessionFactory);
      //重置holderActive为false
      this.holderActive = false;
     //触发sqlsession的close方法
      this.holder.getSqlSession().close();
    }
  }
   //如果holderActive为true,则关闭SqlSession,重置holder、holderActive 
  @Override
  public void afterCompletion(int status) {
  //如果holderActive为true
    if (this.holderActive) {
      // afterCompletion may have been called from a different thread
      // so avoid failing if there is nothing in this one
          //尝试解除资源绑定
      TransactionSynchronizationManager.unbindResourceIfPossible(sessionFactory);
     //重置holderActive为false
      this.holderActive = false;
      //触发sqlsession的close方法
      this.holder.getSqlSession().close();
    }
    this.holder.reset();
  }
}
目录
打赏
0
0
0
0
34
分享
相关文章
|
7天前
|
SpringBoot自动配置的原理是什么?
Spring Boot自动配置核心在于@EnableAutoConfiguration注解,它通过@Import导入配置选择器,加载META-INF/spring.factories中定义的自动配置类。这些类根据@Conditional系列注解判断是否生效。但Spring Boot 3.0后已弃用spring.factories,改用新格式的.imports文件进行配置。
51 0
微服务——SpringBoot使用归纳——Spring Boot事务配置管理——常见问题总结
本文总结了Spring Boot中使用事务的常见问题,虽然通过`@Transactional`注解可以轻松实现事务管理,但在实际项目中仍有许多潜在坑点。文章详细分析了三个典型问题:1) 异常未被捕获导致事务未回滚,需明确指定`rollbackFor`属性;2) 异常被try-catch“吃掉”,应避免在事务方法中直接处理异常;3) 事务范围与锁范围不一致引发并发问题,建议调整锁策略以覆盖事务范围。这些问题看似简单,但一旦发生,排查难度较大,因此开发时需格外留意。最后,文章提供了课程源代码下载地址,供读者实践参考。
86 0
微服务——SpringBoot使用归纳——Spring Boot事务配置管理——Spring Boot 事务配置
本文介绍了 Spring Boot 中的事务配置与使用方法。首先需要导入 MySQL 依赖,Spring Boot 会自动注入 `DataSourceTransactionManager`,无需额外配置即可通过 `@Transactional` 注解实现事务管理。接着通过创建一个用户插入功能的示例,展示了如何在 Service 层手动抛出异常以测试事务回滚机制。测试结果表明,数据库中未新增记录,证明事务已成功回滚。此过程简单高效,适合日常开发需求。
203 0
微服务——SpringBoot使用归纳——Spring Boot事务配置管理——事务相关
本文介绍Spring Boot事务配置管理,阐述事务在企业应用开发中的重要性。事务确保数据操作可靠,任一异常均可回滚至初始状态,如转账、购票等场景需全流程执行成功才算完成。同时,事务管理在Spring Boot的service层广泛应用,但根据实际需求也可能存在无需事务的情况,例如独立数据插入操作。
56 0
Springboot整合SSMP报错分析
本文介绍了Springboot整合SSMP框架时常见的报错及解决方案,包括MyBatis-Plus版本不兼容导致的Lambda表达式条件构造器报错及表名不匹配问题。通过升级或降级MyBatis-Plus版本、使用@TableName注解或配置table-prefix属性,可有效解决上述问题,帮助开发者避免在整合SSMP时出现不必要的错误。
|
4月前
|
SpringBoot自动配置原理
本文深入解析了SpringBoot的核心功能——自动配置,重点探讨了`org.springframework.boot.autoconfigure`及相关注解的工作机制。通过分析`@SpringBootApplication`、`@EnableAutoConfiguration`等注解,揭示了SpringBoot如何基于类路径和条件自动装配Bean
163 7
SpringBoot自动装配的原理
在SpringBoot项目的启动引导类上都有一个注解@SpringBootApplication 这个注解是一个复合注解, 其中有三个注解构成 , 分别是 ● @SpringBootConfiguration : 是@Configuration的派生注解 , 标注当前类是一个SpringBoot的配置类 ● @ComponentScan : 开启组件扫描, 默认扫描的是当前启动引导了所在包以及子包 ● @EnableAutoConfiguration : 开启自动配置(自动配置核心注解) 2.在@EnableAutoConfiguration注解的内容使用@Import注解导入了一个AutoC
Idea启动SpringBoot程序报错:Veb server failed to start. Port 8082 was already in use;端口冲突的原理与解决方案
本文解决了Idea启动SpringBoot程序报错:Veb server failed to start. Port 8082 was already in use的问题,并通过介绍端口的使用原理和操作系统的端口管理机制,可以更有效地解决端口冲突问题,并确保Web服务器能够顺利启动和运行。 只有锻炼思维才能可持续地解决问题,只有思维才是真正值得学习和分享的核心要素。如果这篇博客能给您带来一点帮助,麻烦您点个赞支持一下,还可以收藏起来以备不时之需,有疑问和错误欢迎在评论区指出~
深入分析 Spring Boot 项目开发中的常见问题与解决方案
本文深入分析了Spring Boot项目开发中的常见问题与解决方案,涵盖视图路径冲突(Circular View Path)、ECharts图表数据异常及SQL唯一约束冲突等典型场景。通过实际案例剖析问题成因,并提供具体解决方法,如优化视图解析器配置、改进数据查询逻辑以及合理使用外键约束。同时复习了Spring MVC视图解析原理与数据库完整性知识,强调细节处理和数据验证的重要性,为开发者提供实用参考。
164 0
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问