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();
  }
}
目录
相关文章
|
1月前
|
XML Java 开发者
Spring Boot开箱即用可插拔实现过程演练与原理剖析
【11月更文挑战第20天】Spring Boot是一个基于Spring框架的项目,其设计目的是简化Spring应用的初始搭建以及开发过程。Spring Boot通过提供约定优于配置的理念,减少了大量的XML配置和手动设置,使得开发者能够更专注于业务逻辑的实现。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,为开发者提供一个全面的理解。
36 0
|
3天前
|
Java 数据库连接 Maven
最新版 | 深入剖析SpringBoot3源码——分析自动装配原理(面试常考)
自动装配是现在面试中常考的一道面试题。本文基于最新的 SpringBoot 3.3.3 版本的源码来分析自动装配的原理,并在文未说明了SpringBoot2和SpringBoot3的自动装配源码中区别,以及面试回答的拿分核心话术。
最新版 | 深入剖析SpringBoot3源码——分析自动装配原理(面试常考)
|
10天前
|
NoSQL Java Redis
Spring Boot 自动配置机制:从原理到自定义
Spring Boot 的自动配置机制通过 `spring.factories` 文件和 `@EnableAutoConfiguration` 注解,根据类路径中的依赖和条件注解自动配置所需的 Bean,大大简化了开发过程。本文深入探讨了自动配置的原理、条件化配置、自定义自动配置以及实际应用案例,帮助开发者更好地理解和利用这一强大特性。
55 14
|
1月前
|
Java Spring
SpringBoot自动装配的原理
在Spring Boot项目中,启动引导类通常使用`@SpringBootApplication`注解。该注解集成了`@SpringBootConfiguration`、`@ComponentScan`和`@EnableAutoConfiguration`三个注解,分别用于标记配置类、开启组件扫描和启用自动配置。
59 17
|
1月前
|
Java 容器
springboot自动配置原理
启动类@SpringbootApplication注解下,有三个关键注解 (1)@springbootConfiguration:表示启动类是一个自动配置类 (2)@CompontScan:扫描启动类所在包外的组件到容器中 (3)@EnableConfigutarion:最关键的一个注解,他拥有两个子注解,其中@AutoConfigurationpackageu会将启动类所在包下的所有组件到容器中,@Import会导入一个自动配置文件选择器,他会去加载META_INF目录下的spring.factories文件,这个文件中存放很大自动配置类的全类名,这些类会根据元注解的装配条件生效,生效
|
2月前
|
Java Spring 容器
springboot @RequiredArgsConstructor @Lazy解决循环依赖的原理
【10月更文挑战第15天】在Spring Boot应用中,循环依赖是一个常见问题,当两个或多个Bean相互依赖时,会导致Spring容器陷入死循环。本文通过比较@RequiredArgsConstructor和@Lazy注解,探讨它们解决循环依赖的原理和优缺点。@RequiredArgsConstructor通过构造函数注入依赖,使代码更简洁;@Lazy则通过延迟Bean的初始化,打破创建顺序依赖。两者各有优势,需根据具体场景选择合适的方法。
121 4
|
3月前
|
Java 应用服务中间件 API
Vertx高并发理论原理以及对比SpringBoot
Vertx 是一个基于 Netty 的响应式工具包,不同于传统框架如 Spring,它的侵入性较小,甚至可在 Spring Boot 中使用。响应式编程(Reactive Programming)基于事件模式,通过事件流触发任务执行,其核心在于事件流 Stream。相比多线程异步,响应式编程能以更少线程完成更多任务,减少内存消耗与上下文切换开销,提高 CPU 利用率。Vertx 适用于高并发系统,如 IM 系统、高性能中间件及需要较少服务器支持大规模 WEB 应用的场景。随着 JDK 21 引入协程,未来 Tomcat 也将优化支持更高并发,降低响应式框架的必要性。
Vertx高并发理论原理以及对比SpringBoot
|
2月前
|
Java BI API
spring boot 整合 itextpdf 导出 PDF,写入大文本,写入HTML代码,分析当下导出PDF的几个工具
这篇文章介绍了如何在Spring Boot项目中整合iTextPDF库来导出PDF文件,包括写入大文本和HTML代码,并分析了几种常用的Java PDF导出工具。
650 0
spring boot 整合 itextpdf 导出 PDF,写入大文本,写入HTML代码,分析当下导出PDF的几个工具
|
2月前
|
XML Java 应用服务中间件
【Spring】运行Spring Boot项目,请求响应流程分析以及404和500报错
【Spring】运行Spring Boot项目,请求响应流程分析以及404和500报错
234 2
|
2月前
|
JavaScript 安全 Java
如何使用 Spring Boot 和 Ant Design Pro Vue 实现动态路由和菜单功能,快速搭建前后端分离的应用框架
本文介绍了如何使用 Spring Boot 和 Ant Design Pro Vue 实现动态路由和菜单功能,快速搭建前后端分离的应用框架。首先,确保开发环境已安装必要的工具,然后创建并配置 Spring Boot 项目,包括添加依赖和配置 Spring Security。接着,创建后端 API 和前端项目,配置动态路由和菜单。最后,运行项目并分享实践心得,包括版本兼容性、安全性、性能调优等方面。
190 1