IBATIS(MyBatis)高速缓存

zzss

一．iBATIS高速缓存介绍
1.1 iBATIS高速缓存只关注如何在持久层对查询结果进行缓存。

1.2 iBATIS带来的好处就是通过配置文件来管理高速缓存，帮助避免因手工管理高速缓存结果及其依赖性而造成的大量繁琐的工作。

1.3 iBATIS高速缓存和传统O/RM高速缓存的区别
iBATIS的思想是建立SQL语句到对象的映射，而不是建立数据库表到对象的映射。传统O/RM工具主要关注数据库表到对象的映射。传统的O/RM高速缓存会为其管理的每个对象维护一个OID[object identification，对象标识]，就像数据库需要管理其表中的每条记录的唯一性一样。这意味着，如果两个不同的结果都返回同一个对象，那么该对象将只被高速缓存一次。iBATIS不这样，关注的是SQL语句的执行结果，我们不会根据对象的唯一性来高速缓存它们iBATIS高速缓存的所有结果，而不考虑所标识的对象是否存在于高速缓存中。

二．配置iBATIS缓存
2.1 、cacheModel标签
cacheModel标签用来配置iBATIS的高速缓存，cacheModel标签的属性包括四个属性
id[必需]
该值用来指定一个唯一的ID，便于为需要使用此高速缓存模型所配置的高速缓存的查询已映射语句使用。
type[必需]
此属性用于指定高速缓存所配置的高速缓存的类型。其有效值包括MEMORY LRU FIFO OSCACHE，该属性也可取值为某个自定义CacheController实现的全限定名。
readOnly[可选]
取值为true时表示高速缓存将仅仅用作只读缓存，从只读高速缓存中读出的对象的特性值不允许修改。
serialize[可选]
该属性用于指定在读取高度缓存内容时是否要进行“深复制”
readOnly、serialize属性经常联合起来使用。

2.2 、iBATIS高速缓存模型的类型
2.2.1 MEMORY
MEMORY高速缓存是一种基于引用的高速缓存。MEMORY高速缓存模型对于那些更关注内存的管理策略而不是对象的访问策略的应用程序而言是完美的。有了STRONG、SOFT、WEAK这三种引用类型，就可以确定哪些结果应该比其他结果保留更长的时间。
2.2.2 LRU
LRU类型的高速缓存模型使用最近最少使用策略来管理高速缓存。该高速缓存的内部机制会在后台记录哪些对象最近最少使用，一旦超过高速缓存大小限制就会废弃它们。大小限制规定了高速缓存中可以存放的对象数目。应避免将那些占用较大内存的对象放置在此类高速缓存中，否则内存会很快耗尽。
LRU高速缓存非常设用于那些需要根据某些特定对象的访问频率来管理的高速缓存的情况。通常这种高速缓存策略试用于那些需要高速缓存用于分页结果或关键词搜索结果的对象应用程序中。
2.2.3 FIFO
FIFO高速缓存模型采用先进先出的管理策略，是一种基于时间的策略，使用于放置那些初放入时使用频率高、随时间流逝访问频率就会降低的对象。如：报表、报告股票价格。
2.2.4 OSCACHE
OSCache是个一个广泛采用的高性能的J2EE缓存框架，OSCache能用于任何Java应用程序的普通的缓存解决方案。OSCache有以下特点：
缓存任何对象，你可以不受限制的缓存部分jsp页面或HTTP请求，任何java对象都可以缓存。
　　拥有全面的API--OSCache API给你全面的程序来控制所有的OSCache特性。
　　永久缓存--缓存能随意的写入硬盘，因此允许昂贵的创建（expensive-to-create）数据来保持缓存，甚至能让应用重启。
　　支持集群--集群缓存数据能被单个的进行参数配置，不需要修改代码。
　　缓存记录的过期--你可以有最大限度的控制缓存对象的过期，包括可插入式的刷新策略（如果默认性能不需要时）
2.2.5自定义高速缓存模型
只需要实现com.ibatis.sqlmap.engine.cache.CacheController接口即可，配置时设定type为全限类名或其别名即可。

2.3 高速缓存的清除
使用flushOnExecute、flushInterval标签可以定义清空缓存触发条件
<flushOnExecute> 定义查询已映射语句，其执行将引起相关高速缓存的清除
<flushInterval> 定义一个时间间隔，高速缓存将以此间隔定期清除
<flushInterval>标签属性如下：
hours(可选) 每次清除高速缓存前应该经过的小时数
minutes（可选） 每次清除高速缓存前应该经过的分钟数
seconds（可选) 每次清除高速缓存前应该经过的秒数
milliseconds（可选） 每次清除高速缓存前应该经过的毫秒数

2.4 设置高速缓存模式实现的特性
由于高速缓存模型只是一些可以插入到iBATIS框架的组件，它甚至允许用户自己定制，因此必须有一种方式能为这些组件提供任意的值。<property>标签就是用来完成此任务的。name ：所设定的特性的名称，value：所设定的特性的值。

2.5 常见问题
2.5.1如何选择iBATIS高速缓存模型类型
如何选择一个适合实际应用情况的高速缓存模型类型是一个很负责的问题，需要考虑诸多因素。
需要考虑的因素：
1.当前应用程序是否是数据库的唯一操作入口
2.读写属性
3.缓存时间间隔
4.失效控制
5.最大保存对象数目　　在你的xml配置文件中，每一个 cacheModel 元素，如下

<cacheModel id=oneday_cache type=LRU readOnly=false serialize=true>
<flushInterval hours=24/>
<flushOnExecute statement=updateMyDate/>
<property name=size value=200/>
</cacheModel>



1 属性readOnly如果不写，默认是true,这时的缓存效果无疑最好，因为系统不需要考虑更新操作引起缓存与实际数据不一致的问题，只读缓存的例子是固化到数据库中的一些配置参数表。但是，通常我们想缓存的数据是需要增删改的，这时务必记得要加上 readOnly = false；
2 属性serialize,如果不写，默认为false, 将它设为true,可以提高整体应用（而不仅仅是每个Session）的性能。 这种缓存为每一个Session返回缓存对象不同的实例（复本）。因此每一个Session都可以安全修改返回的对象. 注意，此时readOnly必须为false。
如果你把它设为 true ,记得检查两件事，一件事是缓存中存放的对象(你想查询的POJO)必须是可序列化的， 即实现Serializable接口。如果你有一个复杂对象属性，它也必须满足这个规则，你的整个对象树必须是可序列化的。
另一件事是关闭sql-map-config中的延迟加载属性，即lazyload=false,原因是，它使用了动态代理机制， 那个代理对象并不是Serializable的。

缓存类型的最佳适应情形：

MEMORY 没有统一的对象重用模式的应用，或内存不足的应用。
LRU 在较长的期间内，用户经常使用某些特定对象。
FIFO 用户在短时间内持续引用特定的查询，而后很可能不再使用。

根据个人实践，内存充足时使用LRU，否则使用MEMORY(WEAK)通常能获得较好的效果。