MyBatis in Action——MyBatis事务管理和缓存机制

MyBatis的事务管理

众所周知，事务的四个特性ACID。持久性、原子性、隔离性以及一致性。

Transaction接口
mybatis的事务设计重点就是Transaction接口，它有两个实现类，分别是JdbcTransaction和ManagedTransaction。同时MyBatis还设计了TransactionFactory接口，和工厂类的实现类JdbcTransactionFactory以及ManagedTransactionFactory来获取事务的实例对象。

对事务而言，应该具有如下几个动作：

• create
• commit
• rollback
• close

MyBatis将事务抽象成Transaction接口，该接口源代码如下：

• 通过JDBC的事务管理机制是通过java.sql.Connection对象完成对事务的提交回滚和关闭等操作。
• 通过Managed的事务管理机制，MyBatis本身不会去实现事务管理，而是委托容器如WebLogic、JBoss等来实现对事务的管理。

事务的配置创建和使用
我们在使用MyBatis的时候，会在mybatis-config.xml中，使用如下的信息：

<environment id="mysql">
            <!--指定事务管理类型，type="JDBC"指直接简单的使用JDBC的提交和回滚设置-->
            <transactionManager type="JDBC"/>
            <!--dataSource指数据源配置，POOLED是JDBC连接对象的数据源连接池的实现-->
            <dataSource type="POOLED">
                <property name="driver" value="com.mysql.jdbc.Driver"/>
                <property name="url" value="jdbc:mysql://localhost:3306/mybatis?useSSL=false"/>
                <property name="username" value="root"/>
                <property name="password" value="woshixiao"/>
            </dataSource>
        </environment>

<transactionManager>就告诉我们使用哪种类型的事务管理机制。

MyBatis事务的创建是交给工厂来完成的，如果我们将<transactionManager>的type配置为JDBC，那么，在myBatis初始化解析<environment>节点的时候，会根据type='JDBC’来创建一个JdbcTransactionFactory工厂。
其源码如下：

这是一个很典型的工厂模式。
我们看看怎么得到的Transaction对象实例的。拿JDBC举例：

我们再来看看Transaction是怎么工作的，同样拿jdbc举例 :（这里只展示commit和rollback）

哇，居然这么赖皮，这不就是使用了connection的两个函数么，是的JdbcTransaction就是使用java.sql.Connection上的commit和rollback等函数来工作的，正如前面所说。

那么你可能会疑问，Managed是如何让容器来管理事务Transaction的整个生命周期的呢？
意思是ManagedTransaction的commit和rollback功能，不会对事务有任何影响，它什么都不会做，它只是将事务管理的权力移交给了容器来实现。

MyBatis的缓存机制

一级缓存(SqlSession级别)
MyBatiss的一级缓存是SqlSession级别的缓存，在操作数据库时需要构造SqlSession对象，在对象中有一个HashMap用于存储缓存数据。不同的SqlSession之间的缓存是互不影响的。
当 同一个 SqlSession执行两次相同的sql语句时，第一次执行完毕将会写入缓存，第二次就不再去数据库查询了。需要注意的是，如果SqlSession执行了DML操作（insert、update和delete），那么MyBatis会清空SqlSession中的缓存，避免出现脏读和不可重复读等情况。
以下是两次重复的sql select语句：

以下是两次重复的sql select语句，但是中间插入了delete语句：

结果显而易见吧，第一次只在数据库里查询了一次，第二次由于执行了删除操作，所以在数据库里查询了两次。（当然前提是sqlsession没有关闭，是同一个sqlsession）

二级缓存（mapper级别）
二级缓存是mapper级别的缓存，使用二级缓存的时候，多个SqlSession使用同一个Mapper的sql语句去操作数据库，得到的数据库会存在二级缓存区域。它同样是HashMap进行数据存储。
二级缓存是共享的，其作用域是mapper的同一个Namespace。 不同的SqlSession两次执行相同的namespace下的sql语句，且传递的参数也相同，那么第一次执行完毕会写入缓存，第二次查询会从缓存中获取数据。
但是MyBatis默认不开启二级缓存，需要在setting全局参数中配置开启二级缓存。<setting name="cacheEnabled" value="true"/>
在Mapper.xml创建LRU缓存：

<cache eviction="LRU" flushInterval="60000"
	size="512" readOnly="true"/>

cahce元素用来开启mapper的namespace下的二级缓存，该元素的属性设置如下：

• flushInterval：刷新间隔。默认是没有刷新间隔，只有在调用语句时刷新。
• size：缓存数目。默认1024。
• readOnly：只读。只读的缓存汇给所有调用者返回缓存对象的相同实例。因此这些对象不能被修改。这提供了很重要的性能优势。可读写的缓存会返回缓存对象的拷贝（通过序列化），这虽然会慢一些，但是安全。因此默认是false。
• eviction：收回策略。也可以理解为替换策略：
  包括LRU FIFO SOFT WEAK。

我们之前两次select查询中间插入delete，通过这个方法，可以不用再去数据库查询。

为什么避免使用二级缓存
在符合【Cache使用时的注意事项】的要求时，并没有什么危害。
其他情况就会有很多危害了。
针对一个表的某些操作不在他独立的namespace下进行。
例如在UserMapper.xml中有大多数针对user表的操作。但是在一个XXXMapper.xml中，还有针对user单表的操作。
这会导致user在两个命名空间下的数据不一致。如果在UserMapper.xml中做了刷新缓存的操作，在XXXMapper.xml中缓存仍然有效，如果有针对user的单表查询，使用缓存的结果可能会不正确。
更危险的情况是在XXXMapper.xml做了insert,update,delete操作时，会导致UserMapper.xml中的各种操作充满未知和风险。