MyBatis在Spring环境下的事务管理

26次阅读

共计 7938 个字符，预计需要花费 20 分钟才能阅读完成。

MyBatis 的设计思想很简单，可以看做是对 JDBC 的一次封装，并提供强大的动态 SQL 映射功能。但是由于它本身也有一些缓存、事务管理等功能，所以实际使用中还是会碰到一些问题——另外，最近接触了 JFinal，其思想和 Hibernate 类似，但要更简洁，和 MyBatis 的设计思想不同，但有一点相同：都是想通过简洁的设计最大限度地简化开发和提升性能——说到性能，前段时间碰到两个问题：

  1. 在一个上层方法（DAO 方法的上层）内删除一条记录，然后再插入一条相同 主键 的记录时，会报主键冲突的错误。
  2. 某些项目中的 DAO 方法平均执行时间会是其他一些项目中的 2 倍。

第一个问题是偶尔会出现，在实验环境无论如何也重现不了，经过分析 MyBatis 的逻辑，估计是两个 DAO 分别拿到了两个不同的 Connection，第二个语句比第一个更早的被提交，导致了主键冲突，有待进一步的分析和验证。对于第二个问题，本文将尝试通过分析源代码和实验找到它的 root cause，主要涉及到以下内容：

  1. 问题描述与分析
  2. MyBatis 在 Spring 环境下的载入过程
  3. MyBatis 在 Spring 环境下事务的管理
  4. 实验验证

项目环境

整个系统是微服务架构，这里讨论的「项目」是指一个单独的服务。单个项目的框架基本是 Spring+MyBatis，具体版本如下：

Spring 3.2.9/4.3.5 + Mybatis 3.2.6 + mybatis-spring 1.2.2 + mysql connector 5.1.20 + commons-dbcp 1.4

与 MyBatis 和事务相关的配置如下：

// 代码 1
<!-- bean#1-->
 <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
        destroy-method="close">
        <!-- 一些数据库信息配置 -->
        <!-- 一些 DBCP 连接池配置 -->
         // 在这里设置是否自动提交
        <property name="defaultAutoCommit" value="${dbcp.defaultAutoCommit}" />
  </bean>
<!-- bean#2-->
  <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="mapperLocations" value="classpath*:path/to/mapper/**/*.xml" />
  </bean>
<!-- bean#3 -->
  <bean id="transactionManager"
        class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSource" />
  </bean>
<!-- bean#4-->
  <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
        <property name="basePackage" value=".path.to.mapper" />
        <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/>
  </bean>
 <!-- bean5 -->
  <tx:annotation-driven transaction-manager="transactionManager" />

问题描述与分析

一倍的时间差挺严重的，平均到每次调用，正常的大约在 6 到 10 几 ms，慢的要近 20 ms，由于调用次数很多，导致整体性能会有很大的差别。经过仔细比对这几个项目，发现 DAO 执行慢的项目的数据源配置（bean#1）中 defaultAutoCommit的配置都是 false。而且将此配置改为 true之后就恢复了正常。

由此推断是在 MyBatis 在执行「非自动提交」语句时，进行等待，或者多提交了一次，导致实际调用数据库 API 次数增多。但是这个推断也有个问题，由于整个项目是在 Spring 环境中运行的，而且也开启了 Spring 的事务管理，所以还是需要详细的看一下 MyBatis 到底是如何装配 DAO 方法与管理事务的，才能彻底解开谜团。

问题重现

首先写一个 Service，其中调用了同一个 mapper 类的两个方法分别 2 次， insertModelList()会在数据库中插入两条记录， delModels()方法会删除这两条记录，代码如下：

// 代码 2
//@Transactional
public void testIS(){List<Model> models= new ArrayList<>();
    // 省略一些数据工作。。。modelMapper.insertModelList(50001l, models);
    modelMapper.delModels(50001);
    if (CollectionUtils.isNotEmpty(models))
        modelMapper.insertModelList(50001, models);
    modelMapper.delModels(50001);
}
public void testOther(){System.out.println("加载类：");
    System.out.println(modelMapper.getClass().getClassLoader());
    modelMapper.delModels(50001);
}

实际项目中使用 cat 来进行执行时间的统计，这里也仿照 cat，使用一个单独的 AOP 类实现时间的计算：

// 代码 3
public class DaoTimeAdvice {

  private long time = 0;
  private long num = 0;

  public Object calcTime(ProceedingJoinPoint joinPoint) throws Throwable {long then = System.nanoTime();
    Object object = joinPoint.proceed();
    long now = System.nanoTime();
    setTime(getTime() + (now-then));
    setNum(getNum() + 1);
    return object;
  }
  // 省略 getter & setter。。。public void printInfo() {System.out.println("总共次数：" + num);
    System.out.println("总共时间：" + time);
    System.out.println("平均时间：" + time / num);
  }
}

测试代码：

// 代码 4
public static void test(){System.out.println(new SimpleDateFormat("[yyyy-MM-dd HH:mm:ss]").format(new Date())
            + "开始测试!");
    for (int i = 0; i < TEST_NUM; i++) {ItemStrategyServiceTest ist = (ItemStrategyServiceTest) context.getBean("isTS");
        ist.testIS();
        if (i % 1000 == 0) {System.out.println("1000 次");
        }
    }
    DaoTimeAdvice ad = (DaoTimeAdvice) context.getBean("daoTimeAdvice");
    ad.printInfo();
    ItemStrategyServiceTest ist = (ItemStrategyServiceTest) context.getBean("isTS");
    ist.testOther();
    System.exit(1);
}

测试结果：

defaultAutoCommit 循环次数 共消耗时间(ns) 平均时间(ns)
true 40000 17831088316 445777
true 40000 17881589992 447039
false 40000 27280458229 682011
false 40000 27237413893 680935

defaultAutoCommit 为 false时的执行时间是 true的近 1.5 倍，并没有重现 2 倍的时间消耗，估计是在 cat 统计或者其他 AOP 方法的执行时还有其他消耗，从而扩大了 false和 true之间的区别。

MyBatis 在 Spring 环境下的载入过程

按照第一节中的配置文件，整个 MyBatis 中 DAO 的 bean 的装配应该是这样的：

  1. 先使用 BasicDataSource 装配一个数据源的 bean（bean#1），名字叫做 dataSource。

    这个 bean 很简单，就是实例化并注册到 Spring 的上下文中。

  2. 使用 dataSource来创建 sqlSessionFactory（bean#2)，这个 bean 创建时会扫描 MyBatis 的语句映射文件并解析。

    在 MyBatis 中，真正的数据库读写操作是通过 SqlSession 的实例来实现的，而 SqlSession 要通过 SQLSessionFactory 来管理。这里的 org.mybatis.spring.SqlSessionFactoryBean实现了 FactoryBean 类（这个类比较特殊，与主题无关，这里不再赘述），Spring 会从这个 bean 中会获取真正的 SQLSessionFactory 的实例，源代码中显示，实际返回的对象是 DefaultSqlSessionFactory 的实例。

  3. 使用 sqlSessionFactory这个工厂类来创建 mapper 扫描器（bean#4），并创建含有 DAO 方法的实例。

    为了让上层方法可以通过普通的方法调用来使用 DAO 方法，需要往 Spring 上下文里注册相应的 bean，而在 MyBatis 的普通使用场景中是没有 mapper 的实现类的（具体的 SQL 语句映射通过注解或者 XML 文件来实现），只有接口，在 MyBatis 中这些接口是通过动态代理实现的。这里使用的类是 org.mybatis.spring.mapper.MapperScannerConfigurer，它实现了 org.springframework.beans.factory.support.BeanDefinitionRegistryPostProcessor接口，所以会在 Spring 中「所有的 bean 定义全部注册完成，但还没有实例化」之前，调用方法向 Spring 上下文注册 mapper 实现类（动态代理的对象）。具体代码如下：

     // 代码 5
 @Override
 public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {if (this.processPropertyPlaceHolders) {processPropertyPlaceHolders();
   }

   ClassPathMapperScanner scanner = new ClassPathMapperScanner(registry);
   // 设置一些属性

   scanner.scan(StringUtils.tokenizeToStringArray(this.basePackage, ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS));
 }

 /**
* Perform a scan within the specified base packages.
* @param basePackages the packages to check for annotated classes

*/

public int scan(String... basePackages) {int beanCountAtScanStart = this.registry.getBeanDefinitionCount();

  doScan(basePackages);

  // Register annotation config processors, if necessary.
  if (this.includeAnnotationConfig) {AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);
  }

  return (this.registry.getBeanDefinitionCount() - beanCountAtScanStart);
}

在源代码里可以看到，真正的 mapper 实现类是             ` org.mybatis.spring.mapper.MapperFactoryBean<Object>`，具体的逻辑在方法             ` org.mybatis.spring.mapper.ClassPathMapperScanner.processBeanDefinitions(Set<BeanDefinitionHolder>)` 里。最后，每一个方法的执行，最终落入了             ` org.mybatis.spring.SqlSessionTemplate` 的某个方法中，并被如下这个拦截器拦截：
// 代码 6
  /**
   * Proxy needed to route MyBatis method calls to the proper SqlSession got
   * from Spring's Transaction Manager
   * It also unwraps exceptions thrown by {@code Method#invoke(Object, Object...)} to
   * pass a {@code PersistenceException} to the {@code PersistenceExceptionTranslator}.
   */
private class SqlSessionInterceptor implements InvocationHandler {
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
  SqlSession sqlSession = getSqlSession(
      SqlSessionTemplate.this.sqlSessionFactory,
      SqlSessionTemplate.this.executorType,
      SqlSessionTemplate.this.exceptionTranslator);
  try {Object result = method.invoke(sqlSession, args);
    if (!isSqlSessionTransactional(sqlSession, SqlSessionTemplate.this.sqlSessionFactory)) {
      // force commit even on non-dirty sessions because some databases require
      // a commit/rollback before calling close()
      sqlSession.commit(true);
    }
    return result;
  } catch (Throwable t) {
    // 省略一些错误处理
    throw unwrapped;
  } finally {if (sqlSession != null) {closeSqlSession(sqlSession, SqlSessionTemplate.this.sqlSessionFactory);
    }
  }
}
}

4. MyBatis 在 Spring 环境下事务的管理         

从源代码中知道真正的 SqlSessionFactory 使用的是             ` org.apache.ibatis.session.defaults.DefaultSqlSessionFactory` 的实例，同时，事务管理使用             ` org.mybatis.spring.transaction.SpringManagedTransactionFactory`。但是在代码 1 的配置中，还添加了 Spring 事务管理的配置，就是在某个 Service 方法（或某个其他可被扫描到的方法）上加上             ` @Transactional` 注解，那么 Spring 的事务管理会自动创建事务，那么它和 MyBatis 的事务之间是怎么协作的呢？可以看到在代码 6 中的方法             ` isSqlSessionTransactional()`，它会返回上层代码中是否有 Spring 的事务，如果有，将不会执行下边的             ` commit()`。在我的项目中的实际情况是没有 Spring 事务，所以肯定是走到了下面的             ` commit()`，这个方法最终落到了             ` SpringManagedTransactionFactory` 中的             ` commit()`，看代码：
// 代码 7
private void openConnection() throws SQLException {this.connection = DataSourceUtils.getConnection(this.dataSource);
  this.autoCommit = this.connection.getAutoCommit();
  this.isConnectionTransactional = DataSourceUtils.isConnectionTransactional(this.connection, this.dataSource);

}
public void commit() throws SQLException {if (this.connection != null && !this.isConnectionTransactional && !this.autoCommit) {if (LOGGER.isDebugEnabled()) {LOGGER.debug("Committing JDBC Connection [" + this.connection + "]");
    }
    this.connection.commit();}
}

可以看到，此处是否要执行             ` commit()` 操作是由 3 个变量决定的，如果 DataSource 的             ` autoCommit` 是             ` false`，则其结果一定为             ` true`，控制台也会看到一行日志：` Committing JDBC Connection [xxxxxx]`，刚好与项目中遇到的情况相同。这个提交动作是需要和数据库交互的，比较耗时。### 实验验证 

由上一节分析得出，造成 DAO 方法执行时间变长的原因是会多执行一次提交，那么如果上层方法被 Spring 事务管理器托管（或者数据源的     ` defaultAutoCommit` 为     ` true`，这个条件已经在刚开始的问题重现被验证），则不会执行 MyBatis 的提交动作，DAO 方法应该相应的执行时间会变短。于是将 Service 方法加上     ` @transactional` 注解，分别测试     ` true` 和     ` false` 的情况。结果：![](https://ws1.sinaimg.cn/large/005BVorrgy1g5iw155o3oj31b007q0ui.jpg)

正文完
发表至： java
2019-07-31
 0
关于java:进大厂也就这回事工作后2到3年进大厂操作指南
关于java:switch-是如何支持-String-的为什么不支持-long
关于java:ZooKeeper特性简介
关于java:字节跳动面经总结都是套路新鲜出炉