MyBatis在Spring环境下的事务管理

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

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

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

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

项目环境

整个系统是微服务架构，这里讨论的「项目」是指一个单独的服务。单个项目的框架基本是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//代码1
2<!-- bean#1-->
3 <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
4        destroy-method="close">
5        <!-- 一些数据库信息配置-->
6        <!-- 一些DBCP连接池配置 -->
7         //在这里设置是否自动提交
8        <property name="defaultAutoCommit" value="${dbcp.defaultAutoCommit}" />
9  </bean>
10<!-- bean#2-->
11  <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
12        <property name="dataSource" ref="dataSource" />
13        <property name="mapperLocations" value="classpath*:path/to/mapper/**/*.xml" />
14  </bean>
15<!-- bean#3 -->
16  <bean id="transactionManager"
17        class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
18        <property name="dataSource" ref="dataSource" />
19  </bean>
20<!-- bean#4-->
21  <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
22        <property name="basePackage" value=".path.to.mapper" />
23        <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/>
24  </bean>
25 <!-- bean5 -->
26  <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()方法会删除这两条记录，代码如下：

1//代码2
2//@Transactional
3public void testIS(){
4    List<Model> models= new ArrayList<>();
5    //省略一些数据工作。。。
6    modelMapper.insertModelList(50001l, models);
7    modelMapper.delModels(50001);
8    if (CollectionUtils.isNotEmpty(models))
9        modelMapper.insertModelList(50001, models);
10    modelMapper.delModels(50001);
11}
12public void testOther(){
13    System.out.println("加载类：");
14    System.out.println(modelMapper.getClass().getClassLoader());
15    modelMapper.delModels(50001);
16}

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

1//代码3
2public class DaoTimeAdvice {
3
4  private long time = 0;
5  private long num = 0;
6
7  public Object calcTime(ProceedingJoinPoint joinPoint) throws Throwable {
8    long then = System.nanoTime();
9    Object object = joinPoint.proceed();
10    long now = System.nanoTime();
11    setTime(getTime() + (now-then));
12    setNum(getNum() + 1);
13    return object;
14  }
15  //省略getter & setter。。。
16  public void printInfo() {
17    System.out.println("总共次数：" + num);
18    System.out.println("总共时间：" + time);
19    System.out.println("平均时间：" + time / num);
20  }
21}

测试代码：

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

测试结果：

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的装配应该是这样的：

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

这个bean很简单，就是实例化并注册到Spring的上下文中。
使用 dataSource来创建 sqlSessionFactory（bean#2)，这个bean创建时会扫描MyBatis的语句映射文件并解析。

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

使用 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实现类（动态代理的对象）。具体代码如下：

1 //代码5
2 @Override
3 public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
4   if (this.processPropertyPlaceHolders) {
5     processPropertyPlaceHolders();
6   }
7
8   ClassPathMapperScanner scanner = new ClassPathMapperScanner(registry);
9   //设置一些属性
10
11   scanner.scan(StringUtils.tokenizeToStringArray(this.basePackage, ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS));
12 }
13
14 /**
15* Perform a scan within the specified base packages.
16* @param basePackages the packages to check for annotated classes
17* @return number of beans registered
18*/
19 public int scan(String... basePackages) {
20   int beanCountAtScanStart = this.registry.getBeanDefinitionCount();
21
22   doScan(basePackages);
23
24   // Register annotation config processors, if necessary.
25   if (this.includeAnnotationConfig) {
26     AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);
27   }
28
29   return (this.registry.getBeanDefinitionCount() - beanCountAtScanStart);
30 }

在源代码里可以看到，真正的mapper实现类是 org.mybatis.spring.mapper.MapperFactoryBean<Object>，具体的逻辑在方法 org.mybatis.spring.mapper.ClassPathMapperScanner.processBeanDefinitions(Set<BeanDefinitionHolder>)里。最后，每一个方法的执行，最终落入了 org.mybatis.spring.SqlSessionTemplate的某个方法中，并被如下这个拦截器拦截：

1 //代码6
2   /**
3    * Proxy needed to route MyBatis method calls to the proper SqlSession got
4    * from Spring's Transaction Manager
5    * It also unwraps exceptions thrown by {@code Method#invoke(Object, Object...)} to
6    * pass a {@code PersistenceException} to the {@code PersistenceExceptionTranslator}.
7    */
8 private class SqlSessionInterceptor implements InvocationHandler {
9 @Override
10 public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
11   SqlSession sqlSession = getSqlSession(
12       SqlSessionTemplate.this.sqlSessionFactory,
13       SqlSessionTemplate.this.executorType,
14       SqlSessionTemplate.this.exceptionTranslator);
15   try {
16     Object result = method.invoke(sqlSession, args);
17     if (!isSqlSessionTransactional(sqlSession, SqlSessionTemplate.this.sqlSessionFactory)) {
18       // force commit even on non-dirty sessions because some databases require
19       // a commit/rollback before calling close()
20       sqlSession.commit(true);
21     }
22     return result;
23   } catch (Throwable t) {
24     //省略一些错误处理
25     throw unwrapped;
26   } finally {
27     if (sqlSession != null) {
28       closeSqlSession(sqlSession, SqlSessionTemplate.this.sqlSessionFactory);
29     }
30   }
31 }
32 }

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()，看代码：
```
1 //代码7
2 private void openConnection() throws SQLException {
3   this.connection = DataSourceUtils.getConnection(this.dataSource);
4   this.autoCommit = this.connection.getAutoCommit();
5   this.isConnectionTransactional = DataSourceUtils.isConnectionTransactional(this.connection, this.dataSource);
6
7 }
8 public void commit() throws SQLException {
9   if (this.connection != null && !this.isConnectionTransactional && !this.autoCommit) {
10     if (LOGGER.isDebugEnabled()) {
11       LOGGER.debug("Committing JDBC Connection [" + this.connection + "]");
12     }
13     this.connection.commit();
14   }
15 }
```
可以看到，此处是否要执行 commit()操作是由3个变量决定的，如果DataSource的 autoCommit是 false，则其结果一定为 true，控制台也会看到一行日志： Committing JDBC Connection [xxxxxx]，刚好与项目中遇到的情况相同。这个提交动作是需要和数据库交互的，比较耗时。

实验验证

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

可以看到执行的时间已经基本接近，由此基本可以确定是这个原因造成的。这里仍然有几个疑点，尤其是问题重现时没有出现2倍的时间消耗，如果你有别的想法，也欢迎提出来讨论。

MyBatis在Spring环境下的事务管理

项目环境

问题描述与分析

问题重现

MyBatis在Spring环境下的载入过程

实验验证

评论区

相关推荐