ehcache作为Mybatis二级缓存的问题

在项目中曾经出现mybatis-ehcache做二级缓存导致数据脏读的问题。在读场景居多的情况下，这种方式可以提高了缓存命中率。但是在实际应用场景下，开发规范不可控，坑可能更多些。。。

<!-- ecache -->        <dependency>            <groupId>com.googlecode.ehcache-spring-annotations</groupId>            <artifactId>ehcache-spring-annotations</artifactId>            <version>1.1.2</version>            <type>jar</type>            <scope>compile</scope>        </dependency>        <dependency>            <groupId>net.sf.ehcache</groupId>            <artifactId>ehcache-core</artifactId>            <version>2.1.0</version>        </dependency>        <!-- https://mvnrepository.com/artifact/org.mybatis.caches/mybatis-ehcache -->        <dependency>            <groupId>org.mybatis.caches</groupId>            <artifactId>mybatis-ehcache</artifactId>            <version>1.0.3</version>        </dependency>        <!-- ecache -->

一般会配置如下的pom，然后配置好ehcache与Mapper文件就可以了。这里边会引用mybatis-ehcache。

<cache type="org.mybatis.caches.ehcache.EhcacheCache"/>

Mybatis本身只支持一级缓存，提供二级缓存的接入能力。当有更新产生时，会清空一二级缓存，借个网上的图说明下缓存架构

这里有个关键点二级缓存是基于mapper映射文件的namespace。可以查看org.mybatis.caches.ehcache.EhcacheCache源码

public final class EhcacheCache implements Cache {    /**     * The cache manager reference.     */    private static final CacheManager CACHE_MANAGER = CacheManager.create();    /**     * The cache id (namespace)     */    private final String id;    /**     * The cache instance     */    private final Ehcache cache;    /**     * Dummy lock that actually does not lock.      * As of 3.2.6 MyBatis does not call locking methods.      */    private final ReadWriteLock readWriteLock = new DummyReadWriteLock();

EhcacheCache继承了Mybatis的org.apache.ibatis.cache.Cache接口。其中的cacheId即为Mapper文件的namespace。而mybatis 对cache的管理是通过cacheId来做的。

我们看下Mybatis创建cache，此部分在org.apache.ibatis.builder.MapperBuilderAssistant。

public Cache useNewCache(Class<? extends Cache> typeClass,      Class<? extends Cache> evictionClass,      Long flushInterval,      Integer size,      boolean readWrite,      Properties props) {    typeClass = valueOrDefault(typeClass, PerpetualCache.class);    evictionClass = valueOrDefault(evictionClass, LruCache.class);    Cache cache = new CacheBuilder(currentNamespace)        .implementation(typeClass)        .addDecorator(evictionClass)        .clearInterval(flushInterval)        .size(size)        .readWrite(readWrite)        .properties(props)        .build();    configuration.addCache(cache);    currentCache = cache;    return cache;  }

configuration.addCache(cache)是在org.apache.ibatis.session.Configuration中添加cache的

public void addCache(Cache cache) {    caches.put(cache.getId(), cache);  }

此处的cacheId即为org.mybatis.caches.ehcache.EhcacheCache中的id值。

在org.apache.ibatis.executor.CachingExecutor可以看到Mybatis的清除cache执行方法。

private void flushCacheIfRequired(MappedStatement ms) {    Cache cache = ms.getCache();    if (cache != null && ms.isFlushCacheRequired()) {            tcm.clear(cache);    }  }

cache从属于MappedStatement，每个ms对应一个mapper文件的命名空间。Mybatis是在不同的namesapce下对各自的cache进行操作的。
从而mybatis在ehcache作为缓存情况下出现多表或者关联查询时，将很可能出现脏数据。那位同学就是因为在一个mapper中关联查询，关联表更新，但是对应这个mapper 中的cache还是原来的导致的脏读问题。

总的来看这种二级缓存方式弊要大于利。
1、这种方式基于mapper的namespace区分，要能确保开发人员在一个mapper中不引入其他的表。如果出现关联查询则更难处理。
2、使用场景非常有限，需要读远超过其他三种方式。

综上，建议还是在业务逻辑层加入缓存，而尽量谨慎选择Mybatis的二级缓存方式。