利用 iBatis 缓存 - zxjava - JavaEye技术网站

来源:百度文库 编辑:神马文学网 时间:2024/03/29 06:40:05

利用 iBatis 缓存

缓存 Mapped Statement结果集
===========================
通过在查询 statement 中指定 cacheModel 属性,可以缓存 Mapped Statement 中得到的查询结果。
Cache model 是在 SQL Map XML 文件中定义的可配置缓存模式,可以使用cacheModel元素来配置。
例子如下:






上面的cache model创建了一个名为“product-cache”的缓存,使用“近期最少使用”(LRU)实现。
Implemention 属性的名称要么是全限定的类名,要么是缓存实现的别名(参见下面的内容)。
根据 cacheModel 中 flush 元素的内容,上面的例子每 24 小时刷新一次。
一个cacheModel只能有一个 flushInteval 元素,它可以使用 hours,minutes,seconds或 milliseconds来设定。
另外,当 insertProduct,updateProduct 或deleteProduct的Mapped Statement 执行时,缓存也被刷新。
cacheModel 可以定义任意多的 flushOnExecute元素。
某些 cache model 的实现可能需要另外的属性,如上面的“cache-size”属性。在 LRU cache model 中,cache-size指定了缓存储存的项数。
一旦配置了 cache model,您可以指定 mapped statement 使用的cache model,例如:

select * from PRODUCT where PRD_CAT_ID = #value#


只读 VS  可读写
---------------
框架同时支持只读和可读写缓存。只读缓存可供所有用户共享,因此性能更好。但是,
只读缓存的数据不应该被修改。相反,要更新数据,必须从数据库(或读写缓存)中读出数
据。因此,如果要读出数据并修改,则需要可读写缓存。要使用只读缓存,在 cacheModel
设置 readOnly=“true”。要使用可读写缓存,则设置readOnly=“false”。缺省为只读缓存(true)。

Serializable可读写缓存
----------------------
正如您所知道的,只对当前 Session 有效的缓存对整体应用性能的提高作用有限。
Serializable 可读写缓存可以提高整体应用(而不仅仅是每个 Session)的性能。这种缓存为
每一个 Session 返回缓存对象不同的实例(复本)。因此每一个 Session 都可以安全修改返回
的对象。不同之处在于,通常您希望从缓存中得到同一个对象,但这种情况下得到的是不同
的对象。还有,每一个缓冲在 Serializable 缓存的对象都必须是 Serializable 的。这意味着不
能同时使用 Serializable 缓存和延迟加载,因为延迟加载代理不是 Serializable 的。想知道如
何把 Serializable 缓存,延迟加载和联合查询结合起来使用,最好的方法是尝试。要使用
Serializable缓存,设置 readOnly=“false”和 serialize=“true”。缺省情况下,缓存是只读模
式,不使用 Serializable 缓存。只读缓存不需要 Serializable。

缓存类型
--------
Cache Model 使用插件方式来支持不同的缓存算法。它的实现在 cacheModel 的用 type属性来指定(如上所示)。
指定的实现类必须实现 CacheController接口,或是下面 4个别名中的其中之一。
Cache Model 实现的其他配置参数通过 cacheModel的 property元素来设置。
目前包括以下的 4 个实现:

"MEMORY" (coibatis.db.sqlmap.cache.memory.MemoryCacheController)
MEMORY cache 实现使用 reference 类型来管理 cache 的行为。
垃圾收集器可以根据 reference类型判断是否要回收 cache 中的数据。
MEMORY实现适用于没有统一的对象重用模式的应用,或内存不足的应用。
MEMORY实现可以这样配置:







MEMORY cache 实现只认识一个元素。这个名为“reference-type”属性
的值必须是 STRONG,SOFT 和 WEAK 三者其一。
这三个值分别对应于 JVM 不同的内存 reference类型。
下面的表格介绍了在 MEMORY 实现中不同的 reference  类型。
要更好地理解reference 类型,请参考 JDK 文档中的 java.lang.ref,以获得更多关于“reachability”的信息。
WEAK(缺省) 大多数情况下,WEAK 类型是最佳选择。如果不指定类型,缺省类型就是 WEAK。
它能大大提高常用查询的性能。但是对于当前不被使用的查询结果数据,将被清除以释放内存用来分配其他对象。
SOFT  在查询结果对象数据不被使用,同时需要内存分配其他对象的情况下,SOFT 类型将减少内存不足的可能性。
然而,这不是最具侵入性的 reference类型,结果数据依然可能被清除。
STRONG  STRONG 类型可以确保查询结果数据一直保留在内存中,除非 Cache被刷新(例如,到了刷新的时间或执行了更新数据的操作)。
对于下面的情况,这是理想的选择:1)结果内容数据很少,2)完全静态的数据,和 3)频繁使用的数据。优点是对于这类查询性能非常好。
缺点是,如果需要分配其他对象,内存无法释放(可能是更重要的数据对象)。

"LRU" (com.ibatis.db.sqlmapache.lru.LruCacheController)
LRU Cache 实现用“近期最少使用”原则来确定如何从 Cache 中清除对象。
当 Cache溢出时,最近最少使用的对象将被从 Cache 中清除。
使用这种方法,如果一个特定的对象总是被使用,它将保留在 Cache 中,而且被清除的可能性最小。
对于在较长的期间内,某些用户经常使用某些特定对象的情况(例如,在 PaginatedList 和常用的查询关键字结果集中翻页),
LRU Cache 是一个不错的选择。
LRU Cache实现可以这样配置:







LRU Cache实现只认可一个 property元素。其名为“cache-size”的属性值必须是整数,代表同时保存在 Cache中对象的最大数目。
值得注意的是,这里指的对象可以是任意的,从单一的 String 对象到 Java Bean 的 ArrayList 对象都可以。
因此,不要 Cache太多的对象,以免内存不足。

"OSCACHE" (com.ibatis.db.sqlmap.cache.oscache.OSCacheController)
OSCACHE Cache 实现是OSCache2.0缓存引擎的一个 Plugin。它具有高度的可配置性,分布式,高度的灵活性。
OSCACHE 实现可以这样配置:






OSCACHE 实现不使用 property 元素,而是在类路径的根路径中使用标准的oscache.properties 文件进行配置。
在 oscache.properties文件中,您可以配置 Cache 的算法(和上面讨论的算法很类似),Cache 的大小,持久化方法(内存,文件等)和集群方法。
要获得更详细的信息,请参考 OSCache 文档。OSCache 及其文档可以从 OpenSymphony网站上获取: http://www.opensymphony.com/oscache/