MySQL中Spring管理的事务开启后不提交引起的事故

adrninistrat0r

已于 2023-02-20 19:10:18 修改

阅读量7.9k

点赞数 11

于 2023-01-28 21:53:13 首次发布

本文链接：https://blog.csdn.net/a82514921/article/details/128782544

版权

Java 同时被 2 个专栏收录

72 篇文章 13 订阅

订阅专栏

MySQL

25 篇文章 0 订阅

订阅专栏

1. 前言

了解到一个事故，在MySQL数据库中，使用Spring管理的事务在开启以后没有在操作结束时提交或回滚，使得原有线程在后续执行数据库操作时可能继续使用原有事务，且不会提交，导致对数据库的修改在Java应用层认为是成功，但在数据库层最终是没有生效的，产生了比较严重的后果

与“数据源使用错误导致MySQL事务失效分析”https://blog.csdn.net/a82514921/article/details/126563573的原因类似，但更加复杂

以下对这个问题进行了分析，涉及的技术背景比较多，由几方面的原因导致了最后的事故

2. 问题分析

2.1. 出现问题的相关代码

transaction.start();
try {
    // 新增的代码-开始
    if(xxx){
        // 以下return导致没有执行后续的commit或rollback
        return;
    }
    // 新增的代码-结束

    // 执行数据库操作的代码，略

    transaction.commit();
} catch (Exception e) {
    transaction.rollback();
    throw e;
}

以上的transaction对象是项目中封装的Transaction类，底层通过Spring对事务进行管理

在用于开启事务的start()方法中，会调用Spring的org.springframework.transaction.PlatformTransactionManager类的getTransaction()方法，开启事务，使用的Spring事务传播行为是REQUIRES_NEW

2.2. 问题根本原因

以上新增的代码会导致事务开启后不提交/回滚，由Spring管理事务时，当前线程的上下文ThreadLocal中会保留当前使用的数据库连接信息

当前线程的当前操作执行完毕后，当前线程会回到线程池中，当前线程后续还会执行其他的操作，由于线程的上下文中已有数据库连接信息，因此后续的处理若不使用事务，或使用默认的Spring事务传播行为，会继续使用原有的连接执行，且该连接对应的事务一直没有提交

当前线程执行的后续数据库操作都在原有的事务中执行，且不会提交，最终事务会回滚（应用停止时关闭数据库连接，或事务超时后触发），导致相关的数据库操作都没有生效

2.3. 可能产生的影响

在线程中开启事务后未提交/回滚，可能产生以下影响：

后续使用原有线程执行数据库操作时，若不使用事务，或使用事务且使用特定的Spring事务传播行为时，后续的数据库操作执行时会返回成功，但不会提交，最终会回滚，不会生效
线程池的最大线程数通常配置为几百，例如线程池中共有200个线程，有2个线程开启事务后未提交/回滚时，对应实例约1%的交易执行的数据库操作最终可能不会生效
通常大部分的数据库操作是不使用事务的；使用事务执行数据库操作时，也可能使用默认的Spring事务传播行为。在以上情况下，对应的数据库操作最终不会生效
后续使用其他线程执行数据库操作时，可能出现无法获取可用数据库连接的问题，导致数据库操作无法执行

2.4. 相关组件及版本

组件	版本
spring	5.3.20
mybatis	3.5.9
mybatis-spring	2.0.6
druid	1.2.8
mysql-connector-java	8.0.27

2.5. 事务未提交/回滚的直接影响

开启事务后未提交/回滚，假如当前事务有执行sql语句，则不会被立即提交/回滚

同时，当前事务对应的数据库连接会被当前线程占用，其他线程无法再获取到

2.6. 事务未提交/回滚的后续影响

开启事务后未提交/回滚，对于后续其他线程的影响，需要分情况进行分析

2.6.1. 后续使用原有线程、不使用事务

开启事务后未提交/回滚，假如后续使用线程池中原有的线程，执行数据库操作时不使用事务，情况如下：

分析

后续使用线程池中原有的线程进行操作时，执行数据库操作的过程中，由于ThreadLocal仍然记录有对应的数据库连接信息，因此会继续使用原有的数据库连接执行数据库操作

由于原有的数据库连接已开启事务，不会自动提交，因此后续不使用事务的数据库操作也不会被自动提交

由于后续数据库操作不使用事务，因此也不会执行commit/rollback语句。后续数据库操作，以及原有线程对应的数据库连接事务中累积的数据库操作，都不会被立即提交或回滚

结论

后续使用原有线程、不使用事务时，新执行的数据库操作，及原有事务中的数据库操作，都不会被提交或回滚

2.6.2. 后续使用原有线程、使用事务

开启事务后未提交/回滚，假如后续使用线程池中原有的线程，执行数据库操作时使用事务，情况如下：

分析

后续使用线程池中原有的线程进行操作时，执行数据库操作的过程中，由于ThreadLocal仍然记录有对应的数据库连接信息，会进行已经存在事务情况下的处理，需要根据新事务的Spring事务传播行为决定对应的操作：

Spring事务传播行为	含义	对数据库连接的使用	事务执行结果
REQUIRED	支持现有的事务，若不存在则创建新事务（默认的Spring事务传播行为）	使用原有连接	新事务及原有事务均不会提交
SUPPORTS	支持现有的事务，若不存在则不创建新事务	使用原有连接	新事务及原有事务均不会提交
MANDATORY	支持现有的事务，若不存在事务则抛出异常	使用原有连接	新事务及原有事务均不会提交
REQUIRES_NEW	创建新的事务，若已存在事务则将其暂停	使用新的连接	1. 新的事务会使用新的连接执行数据库操作，若能成功获取到连接则可以正常执行 2. 原有事务不会提交
NOT_SUPPORTED	不支持现有的事务，若存在则以不开启事务方式执行	使用新的连接	1. 新的数据库操作会使用新的连接执行，若能成功获取到连接则可以正常执行 2. 原有事务不会提交
NEVER	不支持现有的事务，若存在则抛出异常	会抛出异常，因此不需要考虑	新的数据库操作不会执行，会抛出异常原有事务不会提交
NESTED	假如现有存在事务，则在嵌套的事务中执行行为与REQUIRED类似	使用原有连接	新事务及原有事务均不会提交

结论

后续使用原有线程、使用事务时，无论新事务使用哪种Spring事务传播行为，原有事务均不会提交

若新事务使用的事务传播行为是REQUIRED、SUPPORTS、MANDATORY、NESTED、NEVER，则新的事务也不会提交

若新事务使用的事务传播行为是REQUIRES_NEW、NOT_SUPPORTED，则新的事务（或不使用事务）成功获取到连接时可以提交

2.6.3. 后续使用其他线程

开启事务后未提交/回滚，假如后续使用线程池中其他线程（开启事务后有执行提交/回滚操作），执行数据库操作时无论是否使用事务，情况如下：

后续使用线程池中其他线程进行操作时，执行数据库操作的过程中，由于ThreadLocal中没有对应的数据库连接信息，因此会从数据源获取可用的连接，假如能够获取到可用的连接，则可以正常执行数据库操作

当有线程开启事务后未提交/回滚时，数据库连接会被相关的线程占用，不会归还到数据库连接池，也无法被其他线程获取到。由于线程池中配置的线程数通常比数据库连接池的连接数大，当线程开启事务后未提交/回滚发生次数超过数据源连接池最大允许连接数时，会导致所有的连接都被相关线程占用，其他线程无法获取到可用连接，无法执行数据库操作

3. 事务相关的技术背景

3.1. MySQL事务能够提交成功的前提

在Java应用中访问MySQL服务时，涉及的内容如下图所示：

在这里插入图片描述

3.1.1. MySQL事务相关内容说明

在MySQL服务中，由连接管理线程处理客户端连接请求，每个客户端连接都会关联到一个MySQL服务线程，每个客户端提交的SQL语句都在对应的MySQL服务线程中执行。

默认情况下，MySQL的自动提交模式是启用的，即不使用事务时，每条SQL语句是原子的，执行后就会生效，就好像SQL语句被包含在START TRANSACTION与COMMIT中执行一样。不使用事务时，无法使用ROLLBACK撤销SQL语句的执行结果。当SQL语句执行过程中出现异常时，才会被回滚。

使用START TRANSACTION可以隐示地禁用自动提交，执行START TRANSACTION后，在执行COMMIT或ROLLBACK结束事务之前，自动提交都会保持禁用；结束事务之后，自动提交模式会恢复为之前的状态。

使用SET autocommit=0;语句可以显式地禁用自动提交，autocommit是一个会话变量，必须对每个会话进行设置。

在InnoDB存储引擎中，所有的用户行为都在一个事务中发生，假如启用了自动提交模式，则每条SQL语句都会形成一个独立的事务。
在MySQL服务中，thd代表线程结构，MySQL服务将事务相关的数据保存在thd->transaction结构中。

当新的连接建立时，thd->transaction中的成员变量会初始化为空状态。假如SQL语句中使用了某个数据库表，则相关的存储引擎都会记录下来。

在SQL语句执行结束时，MySQL服务调用所有相关存储引擎的提交或回滚；当提交或回滚结束后，以上信息会被清空。

对于每个客户端连接，MySQL服务创建一个单独的线程，使用THD类作为线程/连接的描述符。

MySQL服务需要调用存储引擎的start_stmt()或external_lock()，以使存储引擎开始事务。

存储引擎在每个连接的内存中保存了事务信息，也在MySQL服务中注册了事务信息，以使MySQL服务随后能够发起COMMIT或ROLLBACK操作。

在事务需要结束时，MySQL服务会调用存储引擎的commit()或rollback()方法。

MySQL事务在执行时，需要MySQL客户端连接上MySQL服务器，客户端与服务器都知道当前事务的存在，此时在客户端与服务器都存在一个对应的连接，连接在事务执行期间是独占的；在服务器中还存在一个对应的线程，线程也是事务执行期间独占的。

连接ID与线程ID是相同的，因此可以认为，在某个时间点，连接ID（线程ID）可以唯一确定一个事务。

MySQL客户端与服务器通信使用TCP/IP协议（大部分使用场景下），根据RFC793，“TRANSMISSION CONTROL PROTOCOL”https://datatracker.ietf.org/doc/html/rfc793，在TCP连接中，IP地址加端口形成的套接字在连接中是唯一的。

MySQL事务在执行时，客户端IP、服务器IP、服务器端口是固定的，因此可以认为，在某个时间点，客户端端口可以唯一确定一个连接，也就是可以唯一确定一个事务。

3.1.2. MySQL事务总结

在MySQL中，为了使用事务执行sql语句，步骤如下：

MySQL客户端首先需要与MySQL服务器建立TCP连接，MySQL服务器使用单独的线程处理当前事务；
在当前连接中执行“set autocommit=0;”语句，将对应的会话级系统变量由默认值1修改为0，即关闭自动提交，以开启事务；
后续执行sql语句时，需要在同一个连接中执行，可以执行一条或多条sql语句；
所有sql语句执行完毕后，再执行commit/rollback语句，以提交或回滚事务；
最后需要执行“set autocommit=1;”语句，将自动提交恢复为默认值开启。

以上所有的操作都需要在同一个数据库连接中执行，事务才能够生效

在事务执行的过程中，MySQL服务器是使用一个单独的线程执行的，在此期间这个线程被当前事务独占，不会被其他线程使用，这样才能保证不同事务之间的操作不会相互影响

MySQL服务器使用一个线程执行对应的事务，在MySQL客户端也有维护对应事务，双方通信时使用TCP连接，一个事务对应一个TCP连接，因此通过MySQL服务器的线程ID、连接ID，或者MySQL客户端连接的客户端端口，可以确定当前sql语句在哪个事务中执行

3.2. 不使用事务执行SQL语句的过程

3.2.1. 过程分析

详细内容可参考“Spring、MyBatis、Druid、MySQL不使用事务执行SQL语句分析” https://blog.csdn.net/a82514921/article/details/126563515

不使用事务执行SQL语句，每次执行SQL语句时的大致阶段如下：

从连接池借出连接（可能需要创建新连接）
执行SQL语句
归还连接至连接池

如下图所示：

在这里插入图片描述

不使用事务执行SQL语句时，主要由MyBatis完成，与Spring关系不大。

3.3. 使用事务执行SQL语句的过程

3.3.1. 过程分析

详细内容可参考“Spring、MyBatis、Druid、MySQL使用事务执行SQL语句分析” https://blog.csdn.net/a82514921/article/details/126563542

在使用事务执行SQL语句时，每次执行SQL语句时的大致阶段如下：

从连接池借出连接（可能需要创建新连接）
关闭自动提交
执行SQL语句1
执行SQL语句n
提交/回滚事务
开启自动提交
归还连接至连接池

如下图所示：

在这里插入图片描述

使用事务执行SQL语句时，事务管理主要通过Spring完成，SQL语句执行主要通过MyBatis完成

使用事务执行数据库操作时的步骤及作用如下：

首先需要从连接池借出连接
再关闭当前连接的自动提交标志，以使事务开启
之后执行对应的sql语句，可能有一条或多条
在此之后根据需要对事务进行提交或回滚
无论是对事务执行了提交还是回滚，都需要开启当前连接自动提交标志，使当前连接归还到连接池之前恢复默认的自动提交标志（默认自动提交，即不使用事务）
完成以上操作之后，再将连接归还到连接池，在归还之前，对应的连接是被Java应用相关线程独占的，其他线程无法使用（保证不同的线程、事务、连接之间的数据库操作不会相互影响）

3.3.2. 记录ThreadLocal的时间点

Spring在开启事务时，会调用AbstractPlatformTransactionManager.getTransaction()方法（使用@Transactional注解或TransactionTemplate时都会调用），在TransactionSynchronizationManager.bindResource()方法中会在ThreadLocal中记录当前线程对应的连接信息，对应的调用堆栈如下：

org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager:373)
org.springframework.transaction.support.AbstractPlatformTransactionManager.startTransaction(AbstractPlatformTransactionManager:400)
org.springframework.jdbc.datasource.DataSourceTransactionManager.doBegin(DataSourceTransactionManager:300)
org.springframework.transaction.support.TransactionSynchronizationManager.bindResource(TransactionSynchronizationManager:168)

TransactionSynchronizationManager.bindResource()方法中会向ThreadLocal类型的resources字段中记录指定的数据，resources字段及相关代码如下：

private static final ThreadLocal<Map<Object, Object>> resources =
        new NamedThreadLocal<>("Transactional resources");

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);

3.3.3. 清理ThreadLocal的时间点

Spring在提交及清理事务时，均会清理ThreadLocal中的连接信息

提交事务时清理ThreadLocal的调用堆栈如下：

org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager:711)
org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager:790)
org.springframework.transaction.support.AbstractPlatformTransactionManager.cleanupAfterCompletion(AbstractPlatformTransactionManager:992)
org.springframework.jdbc.datasource.DataSourceTransactionManager.doCleanupAfterCompletion(DataSourceTransactionManager:371)
org.springframework.transaction.support.TransactionSynchronizationManager.unbindResource(TransactionSynchronizationManager:197)

回滚事务时清理ThreadLocal的调用堆栈如下：

org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager:809)
org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager:875)
org.springframework.transaction.support.AbstractPlatformTransactionManager.cleanupAfterCompletion(AbstractPlatformTransactionManager:992)
org.springframework.jdbc.datasource.DataSourceTransactionManager.doCleanupAfterCompletion(DataSourceTransactionManager:371)
org.springframework.transaction.support.TransactionSynchronizationManager.unbindResource(TransactionSynchronizationManager:195)

可以看到，提交及回滚事务时，均是调用TransactionSynchronizationManager.unbindResource()方法清理ThreadLocal中的连接信息

在TransactionSynchronizationManager.unbindResource()方法中，会调用doUnbindResource()方法，对应代码如下：

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();
}

3.4. MySQL事务隐式提交的场景

参考“Transaction Life Cycle”https://dev.mysql.com/doc/internals/en/transactions-life-cycle.html。

在以下情况下，事务会被提交：

当用户执行COMMIT语句时；
MySQL事务隐式提交，当MySQL服务开始处理DDL或SET AUTOCOMMIT={0|1}语句时。

关于会导致事务隐式提交的SQL语句，在“Statements That Cause an Implicit Commit”https://dev.mysql.com/doc/refman/5.6/en/implicit-commit.html中有详细说明，包括DDL等。

在以上事务开启后未提交/回滚的场景下，对应的连接不会被其他线程再获取到，因此也不会触发MySQL事务隐式提交

3.5. 事务隐式回滚的场景

3.5.1. MySQL事务隐式回滚

除了在MySQL客户端执行ROLLBACK语句进行显式回滚外，以下情况下MySQL服务也会进行隐式回滚。

3.5.1.1. 连接断开与事务回滚

参考“LOCK TABLES and UNLOCK TABLES Statements”https://dev.mysql.com/doc/refman/5.6/en/lock-tables.html。

当一个客户端会话的连接断开时，假如存在活动的事务，则MySQL服务会将事务回滚。

3.5.1.2. 连接超时与事务回滚

参考https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_wait_timeout。

MySQL系统变量wait_timeout用于设置MySQL服务在关闭非交互式连接之前等待其活动的时间，单位为秒。默认值为28800，即8小时。可能需要同时修改全局系统变量wait_timeout与interactive_timeout，才能使会话系统wait_timeout的修改生效。

即MySQL连接不活动超过该时间后，MySQL服务会将该连接断开，对应的事务也会被回滚。

3.5.1.3. 行锁超时与事务回滚

参考“InnoDB Error Handling”https://dev.mysql.com/doc/refman/5.6/en/innodb-error-handling.html，https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_lock_wait_timeout。

InnoDB在等待获取行锁时，假如超过了一定的时间，则会进行回滚。

系统变量innodb_lock_wait_timeout用于设置以上获取行锁超时时间，单位为秒，默认为50。

当系统变量innodb_rollback_on_timeout为假时，InnoDB会将当前语句（即等待行锁并导致超时的语句）进行回滚（此时整个事务还是活动状态）；当该系统变量为真时，InnoDB会将整个事务进行回滚。

该变量值默认值为假，即默认情况下，事务中执行的语句获取行锁超时，对应语句会被InnoDB回滚。

3.5.1.4. 死锁与事务回滚

参考“Deadlock Detection”https://dev.mysql.com/doc/refman/5.6/en/innodb-deadlock-detection.html，“InnoDB Error Handling”https://dev.mysql.com/doc/refman/5.6/en/innodb-error-handling.html。

InnoDB会自动检测事务死锁，当出现死锁时，会将一个或多个事务回滚以打破死锁。InnoDB尝试将“小”的事务回滚，事务的大小由插入、更新或删除的行数决定。

3.5.1.5. InnoDB其他错误与事务回滚

参考“InnoDB Error Handling”https://dev.mysql.com/doc/refman/5.6/en/innodb-error-handling.html。

假如在SQL语句中没有指定IGNORE，则出现重复键错误时，InnoDB会将对应的SQL语句回滚；

出现行太长错误时，InnoDB会将对应的SQL语句回滚；

其他错误大多由InnoDB存储引擎层之上的MySQL服务层检测，并将对应的SQL语句回滚。

3.5.2. Druid事务隐式回滚

MySQL connector中，用于回滚事务的方法为com.mysql.cj.jdbc.ConnectionImpl类，rollback()方法

在Druid中，com.alibaba.druid.pool.DruidPooledConnection类，rollback()方法，会调用以上方法，即调用Druid的回滚事务方法时，Druid会执行MySQL connector中回滚事务的方法

除此之外，com.alibaba.druid.pool.DruidDataSource类，recycle()方法中，也会调用以上方法，相关代码如下：

final boolean isAutoCommit = holder.underlyingAutoCommit;
final boolean isReadOnly = holder.underlyingReadOnly;

try {
    // check need to rollback?
    if ((!isAutoCommit) && (!isReadOnly)) {
        pooledConnection.rollback();
    }

recycle()方法在归还数据库连接至连接池时会被执行，isAutoCommit代表当前连接是否启用autocommit（未开启事务），isReadOnly代表数据库是否只读

以上执行回滚的场景，是归还数据库连接至Druid连接池时，假如有开启事务，且数据库非只读，则会执行事务回滚操作

3.6. 分析不同线程是否使用相同数据库连接的方式

在Java应用中访问MySQL服务时，涉及Java应用、网络传输、MySQL服务这三层，在每一层都可以对执行的SQL语句与事务操作进行监控与观测

3.6.1. 数据库层

可在MySQL数据库中通过一般查询日志分析对应的SQL使用哪个线程/连接执行

可参考“MySQL SQL语句与事务执行及日志分析”https://blog.csdn.net/a82514921/article/details/126563449

需要DBA开启对应的日志，且一般查询日志的数据量太大，因此该方法不可行

3.6.2. 网络层

可对Java应用与MySQL服务器之间的数据进行抓包分析，检查执行SQL语句时使用的本地端口（可反映对应哪个连接）

可参考“tcpdump、Wireshark抓包分析MySQL SQL语句与事务执行”https://blog.csdn.net/a82514921/article/details/126563471

需要有服务器root权限才能执行相关命令，执行不方便

3.6.3. Java应用层

在Java应用层分析执行SQL语句时使用的连接是比较方便的

可参考“Spring、MyBatis、Druid、MySQL执行SQL语句与事务监控” https://blog.csdn.net/a82514921/article/details/126563558

为了分析事务开启后未提交/回滚时，相关线程后续是否使用原有连接继续执行sql语句，可以通过以下方式实现：

观察数据库操作各个重要节点的情况

使用Druid提供的Filter：stat、log4j2，内容略

确认使用事务执行sql语句时是否使用新连接

在spring-jdbc的org.springframework.jdbc.datasource.DataSourceTransactionManager类中，doBegin()方法会执行开启事务的操作

在以上方法中，若当前事务没有已存在的数据库连接，需要从数据库连接池中获取连接时，会在日志中打印DEBUG级别的日志“Acquired Connection … for JDBC transaction”

确认不使用事务执行sql语句时是否使用新连接

在spring-jdbc的org.springframework.jdbc.datasource.DataSourceUtils类中，doGetConnection()方法会执行获取数据库连接的操作

在以上方法中，若没有使用当前线程ThreadLocal中对应的数据库连接，而是从数据库连接池中获取连接时，会在日志中打印DEBUG级别的日志“Fetching JDBC Connection from DataSource”

确认现有事务是否被暂停或恢复

当前线程已存在对应的事务时，使用新事务（REQUIRES_NEW），或不使用事务（NOT_SUPPORTED）执行sql语句时，会对现有事务执行暂停及恢复，可通过以下方式观察日志

在spring-tx的org.springframework.transaction.support.AbstractPlatformTransactionManager类中，handleExistingTransaction()方法用于处理已存在的事务

在以上方法中，若需要暂停当前线程，会在日志中打印DEBUG级别的日志“Suspending current transaction”

cleanupAfterCompletion()方法用于在事务提交/回滚后进行清理操作

在以上方法中，若发现之前的事务被暂停后需要恢复，会在日志中打印DEBUG级别的日志“Resuming suspended transaction after completion of inner transaction”

3.7. Spring提供的主要的事务使用方式

@Transactional注解

属于声明式事务，某些场景下无法实现编程式事务的效果

事务模板

属于编程式事务，主要是使用TransactionTemplate类

事务管理器

属于编程式事务，主要是使用PlatformTransactionManager接口的实例

以上接口提供了三个方法，分别用于开启事务、提交事务、回滚事务，由于开启事务与提交/回滚事务是需要分别调用的，因此有可能出现漏调用的情况

4. 细节分析

4.1. 为什么不使用事务时会使用ThreadLocal中的数据库连接

开启事务后未提交/回滚，后续使用线程池中原有的线程，执行数据库操作时不使用事务，会使用原有的连接，原因如下：

不使用事务执行数据库操作时，会调用org.springframework.jdbc.datasource.DataSourceUtils类的doGetConnection()方法获取连接，从MyBatis的Mapper接口对应类开始，到以上方法的调用堆栈如下：

com.sun.proxy.$Proxy37.updateByPrimaryKeySelective(Unknown Source)
org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy:86)
org.apache.ibatis.binding.MapperProxy$PlainMethodInvoker.invoke(MapperProxy:145)
org.apache.ibatis.binding.MapperMethod.execute(MapperMethod:67)
org.mybatis.spring.SqlSessionTemplate.update(SqlSessionTemplate:288)
com.sun.proxy.$Proxy35.update(Unknown Source)
org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate:427)
java.lang.reflect.Method.invoke(Method:498)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl:43)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl:62)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession:194)
org.apache.ibatis.executor.CachingExecutor.update(CachingExecutor:76)
org.apache.ibatis.executor.BaseExecutor.update(BaseExecutor:117)
org.apache.ibatis.executor.SimpleExecutor.doUpdate(SimpleExecutor:49)
org.apache.ibatis.executor.SimpleExecutor.prepareStatement(SimpleExecutor:86)
org.apache.ibatis.executor.BaseExecutor.getConnection(BaseExecutor:337)
org.mybatis.spring.transaction.SpringManagedTransaction.getConnection(SpringManagedTransaction:67)
org.mybatis.spring.transaction.SpringManagedTransaction.openConnection(SpringManagedTransaction:80)
org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils:80)
org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils:112)

DataSourceUtils.doGetConnection()方法的相关代码如下：

ConnectionHolder conHolder = (ConnectionHolder) TransactionSynchronizationManager.getResource(dataSource);
if (conHolder != null && (conHolder.hasConnection() || conHolder.isSynchronizedWithTransaction())) {
    conHolder.requested();
    if (!conHolder.hasConnection()) {
        logger.debug("Fetching resumed JDBC Connection from DataSource");
        conHolder.setConnection(fetchConnection(dataSource));
    }
    return conHolder.getConnection();
}

在调用TransactionSynchronizationManager.getResource()方法获取ConnectionHolder类型的对象conHolder后，会判断conHolder是否满足非空，且hasConnection()或isSynchronizedWithTransaction()方法返回值为真，若满足则返回conHolder.getConnection()方法的返回值，即使用以上获取的连接

在org.springframework.transaction.support.TransactionSynchronizationManager类的getResource()方法中，会调用doGetResource()方法，在该方法中会从ThreadLocal类型的resources字段中获取对应的连接对象，resources字段及相关代码如下：

private static final ThreadLocal<Map<Object, Object>> resources =
        new NamedThreadLocal<>("Transactional resources");
...
Map<Object, Object> map = resources.get();
if (map == null) {
    return null;
}
Object value = map.get(actualKey);
// Transparently remove ResourceHolder that was marked as void...
if (value instanceof ResourceHolder && ((ResourceHolder) value).isVoid()) {
    map.remove(actualKey);
    // Remove entire ThreadLocal if empty...
    if (map.isEmpty()) {
        resources.remove();
    }
    value = null;
}
return value;

通过以上代码可知，不使用事务执行数据库操作时，若当前线程的ThreadLocal中的resources存在对应的连接时，会使用对应的连接执行数据库操作

当使用事务执行数据库操作时，会在ThreadLocal中设置以上信息，具体过程见后续内容

4.2. 为什么事务不提交/回滚时ThreadLocal会保持

在事务执行的正常流程中，开启事务时在ThreadLocal记录对应的连接信息，提交/回滚事务时进行清理

若开启事务后不执行提交/回滚事务的操作，则ThreadLocal中的连接信息会保持，直到对应的线程被线程池回收，或应用退出时被清理

4.3. 为什么使用事务时可能使用ThreadLocal中的数据库连接

4.3.1. 开启事务获取数据库连接阶段

org.springframework.transaction.support.AbstractPlatformTransactionManager类的getTransaction()方法用于开启事务，在该方法中，首先调用doGetTransaction()方法获取当前存在的事务

项目中实际使用的事务管理器类型为子类org.springframework.jdbc.datasource.DataSourceTransactionManager，该类的doGetTransaction()方法代码如下：

DataSourceTransactionObject txObject = new DataSourceTransactionObject();
txObject.setSavepointAllowed(isNestedTransactionAllowed());
ConnectionHolder conHolder =
        (ConnectionHolder) TransactionSynchronizationManager.getResource(obtainDataSource());
txObject.setConnectionHolder(conHolder, false);
return txObject;

以上方法调用了TransactionSynchronizationManager.getResource()方法，获取ThreadLocal中的数据库连接（前文有分析）

后续会根据Spring事务传播行为进行处理，部分事务传播行为会使用现有的事务执行后续的数据库操作

4.3.2. 执行sql语句阶段

与前文“为什么不使用事务时会使用ThreadLocal中的数据库连接”原因相同，略

4.4. 为什么不同Spring事务传播行为使用的连接不同

AbstractPlatformTransactionManager类用于开启事务的getTransaction()方法中，判断是否已存在事务及相关的处理代码如下：

if (isExistingTransaction(transaction)) {
    // Existing transaction found -> check propagation behavior to find out how to behave.
    return handleExistingTransaction(def, transaction, debugEnabled);
}

isExistingTransaction()方法用于判断当前是否已存在事务，项目中实际使用的事务管理器类型为子类org.springframework.jdbc.datasource.DataSourceTransactionManager，该类的isExistingTransaction()方法代码如下：

DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction;
return (txObject.hasConnectionHolder() && txObject.getConnectionHolder().isTransactionActive());

开启事务后未提交/回滚事务，后续使用原有线程执行时，以上txObject对象的hasConnectionHolder()及getConnectionHolder().isTransactionActive()方法均返回真，因此会执行handleExistingTransaction()方法

handleExistingTransaction()方法用于在存在事务时进行处理，定义在AbstractPlatformTransactionManager类中，部分代码如下，可以看到有根据事务传播行为进行对应的处理

if (definition.getPropagationBehavior() == TransactionDefinition.NEVER) {
    throw new IllegalTransactionStateException(
            "Existing transaction found for transaction marked with propagation 'never'");
}

if (definition.getPropagationBehavior() == TransactionDefinition.NOT_SUPPORTED) {
    return prepareTransactionStatus(
            definition, null, false, newSynchronization, debugEnabled, suspendedResources);
}

if (definition.getPropagationBehavior() == TransactionDefinition.REQUIRES_NEW) {
    return startTransaction(definition, transaction, debugEnabled, suspendedResources);
}

if (definition.getPropagationBehavior() == TransactionDefinition.NESTED) {
    if (useSavepointForNestedTransaction()) {
        DefaultTransactionStatus status =
                prepareTransactionStatus(definition, transaction, false, false, debugEnabled, null);
        status.createAndHoldSavepoint();
        return status;
    }
    else {
        return startTransaction(definition, transaction, debugEnabled, null);
    }
}
...
return prepareTransactionStatus(definition, transaction, false, newSynchronization, debugEnabled, null);

部分事务传播行为会调用startTransaction()方法时，会创建新的事务，即需要从数据库连接池获取可用的连接

部分事务传播行为会调用prepareTransactionStatus()方法时，若传入的参数2 transaction为null，则代表不使用事务执行数据库操作；若非null，则代表使用指定的当前事务执行数据库操作

4.5. 为什么部分Spring事务传播行为使用原有连接时不会提交事务

若开启事务后不执行提交/回滚事务的操作，后续使用原有线程执行，新事务使用的事务传播行为是REQUIRED、SUPPORTS、MANDATORY、NESTED时，新的事务也不会提交，原因如下：

AbstractPlatformTransactionManager.commit()方法用于提交事务，该方法会调用processCommit()方法

在processCommit()方法中，仅当当前事务为新事务时，才会执行实际提交事务的doCommit()方法，相关代码如下：

else if (status.isNewTransaction()) {
    if (status.isDebug()) {
        logger.debug("Initiating transaction commit");
    }
    unexpectedRollback = status.isGlobalRollbackOnly();
    doCommit(status);
}

以上isNewTransaction()方法在org.springframework.transaction.support.DefaultTransactionStatus类中，当其transaction字段非null，且newTransaction字段为真时，isNewTransaction()方法会返回真

DefaultTransactionStatus的newTransaction字段只能在构造函数中赋值

AbstractPlatformTransactionManager.newTransactionStatus()方法中会创建DefaultTransactionStatus对象

以上方法只有以下两种调用情况：

在startTransaction()方法中调用newTransactionStatus()方法，传入的参数3 newTransaction为true
在prepareTransactionStatus()方法中调用newTransactionStatus()方法，传入的参数3 newTransaction为prepareTransactionStatus()方法的参数3newTransaction

根据上一部分拷贝的Spring代码可知，当Spring事务传播行为是REQUIRES_NEW时，会调用startTransaction()方法，即newTransaction为true，最终可以提交事务

Spring事务传播行为是其他值时，会调用prepareTransactionStatus()方法，且参数3 newTransaction为false，最终不会提交事务

4.6. 为什么使用事务传播行为REQUIRES_NEW之后ThreadLocal中的连接不会被修改

4.6.1. 假设

事务开启后不提交/回滚，对应线程的ThreadLocal中就保留了对应的数据库连接信息

原有线程后续使用事务执行数据库操作，Spring事务传播行为使用REQUIRES_NEW，假如使用新的事务执行数据库操作后，会将ThreadLocal中的数据库连接信息清空，则当前线程就能够恢复正常，之后执行的数据库操作能够正常提交

（不能将ThreadLocal中保留为新事务对应的数据库连接信息，否则还是有类似的问题）

4.6.2. 分析

以上假设不满足，不符合Spring事务传播行为的设计

Spring的TransactionDefinition类中对REQUIRES_NEW事务传播行为的说明如下：

Create a new transaction, suspending the current transaction if one exists.

使用REQUIRES_NEW事务传播行为时，会创建新的事务，假如存在当前事务则暂停当前事务，当前事务还会在随后被恢复

暂停当前事务

AbstractPlatformTransactionManager.handleExistingTransaction()用于对现有事务进行处理，若事务传播行为是NOT_SUPPORTED、REQUIRES_NEW时，会调用suspend()方法暂停当前事务，相关代码如下：

if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NOT_SUPPORTED) {
    if (debugEnabled) {
        logger.debug("Suspending current transaction");
    }
    Object suspendedResources = suspend(transaction);
}

if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW) {
    if (debugEnabled) {
        logger.debug("Suspending current transaction, creating new transaction with name [" +
                definition.getName() + "]");
    }
    SuspendedResourcesHolder suspendedResources = suspend(transaction);
}

suspend()方法中调用doSuspend()方法执行暂停当前事务的操作，并将当前事务的相关资源保存在suspendedResources对象中，相关代码如下：

Object suspendedResources = doSuspend(transaction);
return new SuspendedResourcesHolder(suspendedResources);

以上方法调用的是子类org.springframework.jdbc.datasource.DataSourceTransactionManager的doSuspend()方法，该方法中会调用TransactionSynchronizationManager.unbindResource()方法将ThreadLocal中当前事务的数据库连接信息清空，相关代码如下：

DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction;
txObject.setConnectionHolder(null);
return TransactionSynchronizationManager.unbindResource(obtainDataSource());

执行到此后，当前线程ThreadLocal中的连接信息已被清空

后续会将新创建事务的连接信息记录在ThreadLocal中

恢复当前事务

AbstractPlatformTransactionManager类中，执行提交事务的方法为processCommit()，执行回滚事务的方法为processRollback()，以上两个方法都会在最后finally中调用cleanupAfterCompletion()方法，在事务结束后执行清理操作

在cleanupAfterCompletion()方法中，假如DefaultTransactionStatus类型的status对象的getSuspendedResources()方法返回值非空，即存在被暂停的事务相关资源时，会调用resume()方法对被暂停的事务进行恢复，相关代码如下：

if (status.getSuspendedResources() != null) {
    if (status.isDebug()) {
        logger.debug("Resuming suspended transaction after completion of inner transaction");
    }
    Object transaction = (status.hasTransaction() ? status.getTransaction() : null);
    resume(transaction, (SuspendedResourcesHolder) status.getSuspendedResources());
}

在resume()方法中会调用doResume()方法，对应子类DataSourceTransactionManager的doResume()方法，在该方法中会调用TransactionSynchronizationManager.bindResource()方法，将原有事务的数据库连接信息恢复到ThreadLocal中

4.7. 为什么Druid数据源中活跃连接的事务不能被其他线程提交

4.7.1. 假设

假如Druid数据源会将活跃连接放回连接池中，则后续有其他线程获取到原有的数据库连接时，可以将之前的会话提交

4.7.2. 分析

以上假设不成立，原因如下

Druid不会自动提交事务

MySQL connector中，用于提交事务的方法为com.mysql.cj.jdbc.ConnectionImpl类，commit()方法

以上方法在com.alibaba.druid.pool.DruidPooledConnection类，commit()方法中被调用，即只有在调用Druid的提交事务方法时，Druid才会执行MySQL connector中提交事务的方法

即Druid不会自动提交事务

Druid不会将活跃连接放回连接池

未发现Druid将活跃连接放回连接池的相关参数配置及代码

Druid归还连接时会对事务隐式回滚

Druid将数据库连接归还到连接池时，会对事务隐式回滚，说明见前文

即使Druid会将活跃连接放回连接池，也会将对应的事务回滚，后续无法再提交

4.8. 为什么事务开启后不提交/回滚时后续不会被提交

事务开启后不提交/回滚，则对应的数据库连接在Druid数据源中会处于活动状态，无法被其他线程获取到，因此无法被其他线程提交

当前线程的ThreadLocal中有记录对应的数据库连接信息，假如当前线程后续又执行了其他数据库操作，分以下情况考虑

不使用事务

当前线程后续不使用事务，执行其他数据库操作时，会使用原有的连接，但因为不使用事务，不会执行commit，即不会提交原有事务

使用事务，使用原有连接

当前线程后续使用事务，使用原有连接（对应REQUIRED等Spring事务传播行为），执行其他数据库操作时，因为此时事务不属于新事务，在尝试提交事务的过程中，不会实际执行提交事务的操作

使用事务，使用新的连接

当前线程后续使用事务，使用新的连接（对应REQUIRES_NEW等Spring事务传播行为），会使用新的连接提交事务，与原有事务不属于同一个数据库连接，不会提交原有事务

根据以上内容可知，事务开启后不提交/回滚，不管是其他线程还是原有线程，后续都不会提交原有事务

以上情况可总结为如下表格：

执行操作的线程	是否使用事务	Spring事务传播行为	不提交原有事务的原因
其他线程	无论是否使用事务	无论哪种Spring事务传播行为	无法从数据源连接池中获取到原有连接，无法对原有连接执行提交事务操作
原有线程	不使用事务	-	不使用事务时不会执行commit
原有线程	使用事务	REQUIRED SUPPORTS MANDATORY NESTED	使用原有事务，但不属于新事务，不会实际执行提交事务的操作
原有线程	使用事务	REQUIRES_NEW NOT_SUPPORTED	使用新的事务/连接提交，与原有事务无关
原有线程	使用事务	NEVER	新的事务会抛出异常，不会提交原有事务

4.9. 为什么事务开启后不提交/回滚时最终会被回滚

结合前文可知，经过一段时间后，在以下情况下，原有的事务会被回滚

当Java应用进程结束时，会关闭所有的数据库连接，原有的事务会回滚
当MySQL服务器kill对应的线程时，也会关闭对应的数据库连接，原有的事务会回滚
当事务超时（默认8小时），或在事务中获取行锁超时（默认50秒）时，原有的事务会回滚

因此事务开启后不提交/回滚时，最终会被回滚

4.10. Spring事务传播行为对事务嵌套执行的影响

以下分析Spring事务传播行为对事务嵌套执行的影响，即一个线程已开启一个事务后，又尝试开启事务的情况

4.10.1. 使用现有事务

一个线程已开启一个事务后，又使用事务传播行为REQUIRED开启事务，情况如下：

第二个（及之后）事务开启时，不会开启新的事务，实际上还是使用现有事务；

第二个（及之后）事务执行完毕进行提交时，不会提交现有事务；

第一个事务执行完毕进行提交时，会对事务执行提交

即：使用现有的事务时，由第一次开启事务的代码最后对事务执行提交，后续的事务（没有开启新事务）不会对事务执行提交

以上流程如下所示：

在这里插入图片描述

4.10.2. 使用新的事务

一个线程已开启一个事务后，又使用事务传播行为REQUIRES_NEW开启事务，情况如下：

第二个（及之后）事务开启时，会开启新的事务；

第二个（及之后）事务执行完毕进行提交时，只提交当前开启的事务，不会提交原有事务；

第一个事务执行完毕进行提交时，会对原有事务执行提交

即：使用新的事务时，每一次事务的开启后都由当前事务进行提交，不会提交原有事务

以上流程如下所示：

在这里插入图片描述

5. 编程式事务的建议使用方式

需要使用编程式事务时，建议使用Spring事务模板TransactionTemplate

5.1. Spring事务模板怎样保证事务提交/回滚

org.springframework.transaction.support.TransactionTemplate类的execute()方法用于通过事务执行数据库操作

setPropagationBehavior()方法可以用于设置TransactionTemplate对应的Spring事务传播行为

execute()方法部分代码如下：

TransactionStatus status = this.transactionManager.getTransaction(this);
T result;
try {
    result = action.doInTransaction(status);
}
catch (RuntimeException | Error ex) {
    // Transactional code threw application exception -> rollback
    rollbackOnException(status, ex);
    throw ex;
}
catch (Throwable ex) {
    // Transactional code threw unexpected exception -> rollback
    rollbackOnException(status, ex);
    throw new UndeclaredThrowableException(ex, "TransactionCallback threw undeclared checked exception");
}
this.transactionManager.commit(status);
return result;