1. 事务概述
先回顾一下基本概念吧，事务的概念咱都很清楚了，简单地说，事务就是一组逻辑操作的组合，它们执行的结果要么全部成功，要么全部失败。
事务有 4 个特性ACID：
原子性：一个事务就是一个不可再分解的单位，事务中的操作要么全部做，要么全部不做。原子性强调的是事务的整体。
一致性：事务执行后，所有的数据都应该保持一致状态。一致性强调的是数据的完整。
隔离性：多个数据库操作并发执行时，一个请求的事务操作不能被其它操作干扰，多个并发事务执行之间要相互隔离。隔离性强调的是并发的隔离。
持久性：事务执行完成后，它对数据的影响是永久性的。持久性强调的是操作的结果。
针对数据库的并发操作，可能会出现一些事务的并发问题。事务并发操作中会出现三种问题：
不可重复读：一个事务读到了另一个事务已提交修改的数据。
针对上述三个问题，由此引出了事务的隔离级别：
read uncommitted 读未提交 —— 不解决任何问题
read committed 读已提交 —— 解决脏读
repeatable read 可重复读 —— 解决脏读、不可重复读
serializable 可串行化 —— 解决脏读、不可重复读、幻读
四种隔离级别，自上而下级别逐级增高，但并发性能逐级降低。MySQL 中默认的事务隔离级别是 repeatable read ，Oracle 、PostgresSQL 的默认事务隔离级别是 read committed 。
对于 jdbc 的事务操作而言，无非就是开启事务、提交事务、回滚事务三个操作罢了，既然用了 MyBatis ，那这些操作肯定是 MyBatis 帮我们做了而已。
2. MyBatis的事务控制
其实在之前的很多案例中，我们都有意或者无意的使用到了 MyBatis 的事务控制，比方说之前写的新增、更新、删除数据：
SqlSession sqlSession = sqlSessionFactory.openSession();
DepartmentMapper departmentMapper = sqlSession.getMapper(DepartmentMapper.class);
Department department = departmentMapper.findById("11c8cdec37e041cf8476c86d46a42dd3");
department.setName("测测试试");
departmentMapper.updateById(department);
departmentMapper.deleteById("11c8cdec37e041cf8476c86d46a42dd3");
sqlSession.commit();
sqlSession.close();
而这种写法能得以生效，主要是因为 MyBatis 全局配置文件中配置了事务管理器：
<environments default="development">
<environment id="development">
<!-- 配置了事务管理器 -->
<transactionManager type="JDBC"/>
<dataSource type="POOLED">
<property name="driver" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://localhost:3306/mybatis?characterEncoding=utf-8"/>
<property name="username" value="root"/>
<property name="password" value="123456"/>
</dataSource>
</environment>
</environments>
2.1 事务管理器的类型
在 MyBatis 中有两种事务管理器：
JDBC – 这个配置直接使用了 JDBC 的提交和回滚方法，它依赖从数据源获得的连接来管理事务作用域。
MANAGED – 使用外置的事务管理器（如 WebLogic 、JBOSS 等），这种情况下几乎不作任何操作，只预留了是否关闭连接的配置
前一种就是我们一直在用的，相信各位走过这么十几章了也应该觉得，事务管理器就应该是这样才对的，但 MyBatis 还考虑到一些特殊的情况，所以他还准备了事务管理器外置的这么一种设计。不过由于这种情况实在太罕见了，所以我们也不去探究 MANAGED 类型了。
除此之外，MyBatis 还提供了对 SpringFramework 的支持，有关这部分内容，我们放在整合 SpringFramework 的章节再讲解。
2.2 SqlSession控制事务
咱们目前的重点还是基于 jdbc 的事务控制哈，MyBatis 框架帮我们做了事务控制，而最终落实的操作上还是 SqlSession 上的几个方法，以及由 SqlSessionFactory 创建 SqlSession 上：
SqlSession sqlSession = sqlSessionFactory.openSession();
SqlSession sqlSessionAutoCommit = sqlSessionFactory.openSession(true);
注意看细节，openSession 方法有一个重载的可以传入 boolean 参数的方法，这个参数最终会落实到原生 jdbc 操作的如下语句：
Connection connection = DriverManager.getConnection(......);
connection.setAutoCommit(autoCommit);
如果在开启新的 SqlSession 时，传入的 autoCommit 为 true ，那就意味着该 SqlSession 不参与任何事务操作了，具体我们可以简单测试一下：
public class OpenSessionAutoCommitApplication {
public static void main(String[] args) throws Exception {
InputStream xml = Resources.getResourceAsStream("mybatis-config.xml");
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(xml);
SqlSession sqlSession = sqlSessionFactory.openSession();
// 注意此处先传入false
SqlSession sqlSession2 = sqlSessionFactory.openSession(false);
DepartmentMapper departmentMapper = sqlSession.getMapper(DepartmentMapper.class);
DepartmentMapper departmentMapper2 = sqlSession2.getMapper(DepartmentMapper.class);
Department department = departmentMapper2.findById("53e3803ebbf4f97968e0253e5ad4cc83");
// 刚查出来的数据中，name为"测试产品部"
department.setName("测试部部");
departmentMapper2.update(department);
List<Department> departmentList = departmentMapper.findAll();
departmentList.forEach(System.out::println);
sqlSession.close();
sqlSession2.close();
}
}
如上述代码所示，sqlSession 是带事务的，根据 MySQL 的默认事务隔离级别 repeatable read ，它应该读不到其它事务修改的数据，而此 sqlSession2 传入了 false ，代表着它也开启了事务，那下面 departmentMapper2 更新部门信息时， departmentMapper 查出来的数据就应该是修改之前的 “测试产品部” 。我们运行 main 方法，观察控制台的数据打印：
Department{id='00000000000000000000000000000000', name='全部部门', tel='-'}
Department{id='18ec781fbefd727923b0d35740b177ab', name='开发部', tel='123'}
Department{id='53e3803ebbf4f97968e0253e5ad4cc83', name='测试产品部', tel='789'}
Department{id='ee0e342201004c1721e69a99ac0dc0df', name='运维部', tel='456'}
果然是可重复读，sqlSession2 的事务中修改没有丝毫干扰到 sqlSession 。
接下来，我们把上面 sqlSession2 的开启中，参数改为 true ，这样就意味着查询也好、修改也好，都不在事务中操作了，这次我们再观察运行结果：（已提前把数据库的数据改回了 “测试产品部” ）
Department{id='00000000000000000000000000000000', name='全部部门', tel='-'}
Department{id='18ec781fbefd727923b0d35740b177ab', name='开发部', tel='123'}
Department{id='53e3803ebbf4f97968e0253e5ad4cc83', name='测试部部', tel='789'}
Department{id='ee0e342201004c1721e69a99ac0dc0df', name='运维部', tel='456'}
可见这样操作之后，sqlSession 可以查询到修改之后的数据了。
至于剩下的 commit 和 rollback 方法，实在是老生常谈了，小册也就不多啰嗦了。
3. MyBatis事务控制的模型与设计
3.1 从environments标签解析开始说起
乍一看，好像我们不是很好下手去探究，那就不妨从 MyBatis 的全局配置文件开始吧。MyBatis 全局配置文件中，解析 <environments> 标签时会处理 <transactionManager> 子标签：
private void environmentsElement(XNode context) throws Exception {
if (context != null) {
// ......
// 只会构造默认的数据库环境配置
if (isSpecifiedEnvironment(id)) {
// 解析transactionManager标签，生成TransactionFactory
TransactionFactory txFactory = transactionManagerElement(child.evalNode("transactionManager"));
// ......
}
}
这里会直接解析 <transactionManager> 标签，并生成 TransactionFactory 对象。我们先不去探究方法的实现，先搞明白 TransactionFactory 是个什么东西吧。
3.1.1 TransactionFactory与Transaction
还记得之前在 MyBatis 全局配置文件中提到的 ObjectFactory 吗？它是用来创建结果集模型对象的工厂，那自然 TransactionFactory 的含义也就很好理解了：它是创建具体事务的工厂咯。
3.1.1.1 接口定义
这个接口的方法定义非常简单：
public interface TransactionFactory {
default void setProperties(Properties props) {
// NOP
}
Transaction newTransaction(Connection conn);
Transaction newTransaction(DataSource dataSource, TransactionIsolationLevel level, boolean autoCommit);
}
刨去上面的空方法不看，合着它就一个方法：开启新的事务，方法的返回值是一个 **Transaction** 对象。正好我们都看到另一个核心接口了，那就捎带着看看 Transaction 接口的方法定义吧：
public interface Transaction {
Connection getConnection() throws SQLException;
void commit() throws SQLException;
void rollback() throws SQLException;
void close() throws SQLException;
Integer getTimeout() throws SQLException;
}
可以发现，一个事务应该有的方法，在这里面统统包含了。
看完了接口，那必然的要一起看看实现类咯。
3.1.1.2 具体实现
针对 MyBatis 本身内置的两种事务管理器 JDBC 和 MANAGED ，MyBatis 分别有对应的两个落地实现：JdbcTransactionFactory 和 ManagedTransactionFactory 。而两个事务管理器的本质区别，就是创建出来的 Transaction 的实现类对象不同：
// JdbcTransactionFactory
public Transaction newTransaction(Connection conn) {
return new JdbcTransaction(conn);
}
// ManagedTransactionFactory
public Transaction newTransaction(Connection conn) {
return new ManagedTransaction(conn, closeConnection);
}
得了，又是一一对应了，合着最后都变成了 JdbcTransaction 和 ManagedTransaction 的研究了。
JdbcTransaction
基于 jdbc 的事务模型，那它其实就应该是 Connection 套层壳了，看似神秘，实则相当的朴实无华：
public Connection getConnection() throws SQLException {
if (connection == null) {
openConnection();
}
return connection;
}
@Override
public void commit() throws SQLException {
if (connection != null && !connection.getAutoCommit()) {
connection.commit();
}
}
@Override
public void rollback() throws SQLException {
if (connection != null && !connection.getAutoCommit()) {
connection.rollback();
}
}
@Override
public void close() throws SQLException {
if (connection != null) {
resetAutoCommit();
connection.close();
}
}
具体这些方法会在什么时机下触发，我们下面马上就会研究。
ManagedTransaction
上一章咱就说过，MANAGED 类型的事务几乎不会有任何操作，所以看一下它的方法实现，简直是简单的不要再简单：
@Override
public void commit() throws SQLException {
// Does nothing
}
@Override
public void rollback() throws SQLException {
// Does nothing
}
@Override
public void close() throws SQLException {
if (this.closeConnection && this.connection != null) {
this.connection.close();
}
}
protected void openConnection() throws SQLException {
this.connection = this.dataSource.getConnection();
if (this.level != null) {
this.connection.setTransactionIsolation(this.level.getLevel());
}
}
好家伙，除了控制一下 Connection 要不要关闭，其余的活你是一点也不干了啊！不过人家这么干也是合理的，你都让人家外置的事务管理器控制了，那 MyBatis 理所应当的就不应该管了。
3.1.2 解析transactionManager标签
了解了 MyBatis 封装的这两个事务核心 API ，下面我们就看看解析全局配置文件中的 <transactionManager> 标签逻辑：
private TransactionFactory c(XNode context) throws Exception {
if (context != null) {
// 取出配置的事务管理器类型
String type = context.getStringAttribute("type");
Properties props = context.getChildrenAsProperties();
// 解析类型，并调用默认无参构造器创建对象
TransactionFactory factory = (TransactionFactory) resolveClass(type).getDeclaredConstructor().newInstance();
factory.setProperties(props);
return factory;
}
throw new BuilderException("Environment declaration requires a TransactionFactory.");
}
可见这个逻辑是非常简单的哈，它会读取到 MyBatis 全局配置文件中配置好的事务管理器类型，之后解析类型，调用默认的无参构造器创建出对象，完事。
3.2 事务的作用位置
了解了 TransactionFactory 和 Transaction 的设计，下面我们再回到测试代码的开始，我们看看 TransactionFactory 是在什么位置起的作用，以及事务控制都是在哪里调用的。
3.2.1 开启SqlSession
之前写的测试代码中，我们都是使用默认的 openSession 开启新的 SqlSession ，而这个 openSession 会调用到下面的一个 openSessionFromDataSource 方法：
public SqlSession openSession() {
return openSessionFromDataSource(configuration.getDefaultExecutorType(), null, false);
}
private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) {
Transaction tx = null;
try {
final Environment environment = configuration.getEnvironment();
final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment);
// 此处创建新的事务
tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit);
final Executor executor = configuration.newExecutor(tx, execType);
return new DefaultSqlSession(configuration, executor, autoCommit);
} catch (Exception e) {
closeTransaction(tx); // may have fetched a connection so lets call close()
throw ExceptionFactory.wrapException("Error opening session. Cause: " + e, e);
} finally {
ErrorContext.instance().reset();
}
}
注意观察 try 块的逻辑，开启事务的步骤是先获取当前 **Environment** → 事务管理器 → 事务，事务信息也在这里被创建了。
注意，创建出来的事务传入 Executor 对象了，它就是实际负责执行 statement 的核心组件，非常重要，后面我们在生命周期中会详细讲解它，这里我们先混个脸熟就行。
3.2.2 提交/回滚
SqlSession 的提交或回滚，最终还是调用到 Executor 了，我们直接来到 Executor 的实现父类 BaseExecutor 中看一下它的逻辑：
protected Transaction transaction;
@Override
public void commit(boolean required) throws SQLException {
// ......
if (required) {
// 此处提交事务
transaction.commit();
}
}
@Override
public void rollback(boolean required) throws SQLException {
if (!closed) {
try {
clearLocalCache();
flushStatements(true);
} finally {
if (required) {
// 此处回滚事务
transaction.rollback();
}
}
}
}
可以发现，在 commit 和 rollback 中都有对应的事务操作，非常简单。
这样下来，事务的底层细节我们也就扒的差不多了，相对于前面的模块来讲，事务部分算是比较简单的了，小伙伴们通读一遍有一个印象就好。
我们看下doUpdate方法，首先要构建一个StatementHandler，然后通过StatementHandler的prepare方法构建Statement。
@Override
public int doUpdate(MappedStatement ms, Object parameter) throws SQLException {
Statement stmt = null;
try {
Configuration configuration = ms.getConfiguration();
StatementHandler handler = configuration.newStatementHandler(this, ms, parameter, RowBounds.DEFAULT, null, null);
// 在这里
stmt = prepareStatement(handler, ms.getStatementLog());
return handler.update(stmt);
} finally {
closeStatement(stmt);
}
}
private Statement prepareStatement(StatementHandler handler, Log statementLog) throws SQLException {
Statement stmt;
Connection connection = getConnection(statementLog);
stmt = handler.prepare(connection, transaction.getTimeout());
handler.parameterize(stmt);
return stmt;
}
组装Statement所用的connection就是通过Executor的getConnection方法。
protected Connection getConnection(Log statementLog) throws SQLException {
Connection connection = transaction.getConnection();
if (statementLog.isDebugEnabled()) {
return ConnectionLogger.newInstance(connection, statementLog, queryStack);
} else {
return connection;
}
}
