Mybatis(九) - 事务

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