为什么要缓存:一句话,减少服务器处理次数,加快访问速度
Ibatis的缓存代码
使用ibatis缓存的方法:
在对应每个表的xml中加入一个cacheModel模块,例如:
<cacheModel id="user-cache" type="LRU" readOnly="false" serialize="true"><flushInterval hours="24"/>
<flushOnExecute statement="getUser"/>
<property value="600" name="size"/>
</cacheModel>
id :cacheModel的id.。
type :cache的类型.。
ibatis目前提供了LRU,MEMORY,FIFO,OSCACHE这四种.
FIFO:com.ibatis.sqlmap.engine.cache.fifo.FifoCacheController
LRU:com.ibatis.sqlmap.engine.cache.fifo.LruCacheController
MEMORY:com.ibatis.sqlmap.engine.cache.fifo.MemoryCacheController
OSCACHE:com.ibatis.sqlmap.engine.cache.fifo.OSCacheController
当然,你也可以自己来实现Cache, 你需要做的是让你的Cache类 implements com.ibatis.sqlmap.engine.cache.CacheController.
readOnly:是否只读. 默认为true, 只读。
Serialize:是否从Cache中读取同一个对象,还是对象的副本。只有在readOnly=false才有效.
因为Cache是只读的,那么为不同session返回的对象肯定是一个.
只有在Cache是可读写的时候,才需要为每个session返回对象的副本.
flushInterval:Cache刷新间隔. 可以配置hours,minutes,seconds,milliseconds.
注: 不是说,间隔时间到了,在Cache的statement会自己刷新,而是说,在间隔时间过了后,下次的查询
将不会从Cache中直接取值,而会用SQL去查.也就是: 如果,间隔时间过了,还没有Cache对应的statement执行
的话,那么Cache中就会一直是旧的,不用担心Cache数据是旧的,因为下次的查询将会直接从SQL查询,而非Cache,查询的结果也会去更新Cache的值.
flushOnExecute :当这些statement被执行了,那么下次的查询将会通过SQL去查,同时用查询结果更新Cache.
注: 和flushInterval的刷新一样,不是主动刷新,而是由下次查询来触发被动刷新。
在一个cacheModel中可以指定多个flushOnExecute。
property:这是针对cacheModel的额外的一些属性配置.不同type的cacheModel将会有自己专有的一些property配置.
FIFO: <property name="size" value="100" />
LRU: <property name="cache-size" value="100" />
MEMORY: <property name="reference-type" value="WEAK" />
在statment的使用上,直接加一个cacheModel属性指向id即可。
<select id="getAllUser" resultClass="user" cacheModel="user-cache">select * from user;
</select>
总结:
1、 感觉ibatis的缓存到了一定的时候就会有瓶颈,在实际应用中如果把数据层的cache做到应用层效果应该会更好。
2、 Ibatis设置cache,当session设为 true 的时候,缓存中存放的对象(你想查询的POJO)必须是可序列化的,即实现Serializable接口,而且只能是jdk自带的序列化。如果你有一个复杂对象属性,它也必须满足这个规则,你的整个对象树必须是可序列化的。