ibatis缓存

最近开始重构公司一套手机论坛系统（为什么我不说wap论坛，是因为需要针对不同的手机浏览器，实现自动适配成wap、html以及wap2.0版本的页面）。原系统存在架构层次不清晰（表现层全jsp，直接配合数据层获取数据），访问速度慢的问题。其使用的OR映射框架是Hibernate，鉴于Hibernate的一些不满足需要情况下，我们在重构的时候换成了iBatis，为了加快访问速度，采用了iBatis的缓存技术。

      iBatis的缓存配置比较简单易懂，以我使用的iBatis2.3为例，做以下配置即可实现对某些查询进行缓存：

      1、在sqlMap文件中加入cacheModel的配置:

    <cacheModel id="model-cache" type="MEMORY" >

     <flushInterval seconds="60"/>
     <flushOnExecute statement="insertProduct"/>
     <flushOnExecute statement="updateProduct"/>
     <flushOnExecute statement="deleteProduct"/>

     <property name="size" value="1000" />
    </cacheModel>

      这个地方要注意的是，如果在sqlMapConfig里面设置了useStatementNamespaces="true"，那么上面的flushOnExecute中的statement里面需要带上namespace，如<flushOnExecute statement="Product.insertProduct"/>，如果useStatementNamespaces="false"，则可以直接按上面的写。

     2、配置需要进行cache的sql statment：

      <statement id="getProductList" parameterClass="int" cacheModel="model-cache">
        select * from PRODUCT where PRD_CAT_ID = #value#
      </statement>

     配置好这两步就可实现iBatis的缓存了，下面解释一下含义：

     1步中，cacheModel的id属性用于后面的statement引用，type属性标识采用何种cache方式，可选的有：

“MEMORY” (com.ibatis.db.sqlmap.cache.memory.MemoryCacheController) 。MEMORY cache 实现使用 reference 类型来管理 cache 的行为。垃圾收集器可以根据 reference类型判断是否要回收 cache 中的数据。MEMORY实现适用于没有统一的对象重用模式的应用，或内存不足的应用。
“LRU” (com.ibatis.db.sqlmap.cache.lru.LruCacheController) 。LRU Cache 实现用“近期最少使用”原则来确定如何从 Cache 中清除对象。当 Cache溢出时，最近最少使用的对象将被从 Cache 中清除。使用这种方法，如果一个特定的对象总是被使用，它将保留在 Cache 中，而且被清除的可能性最小。对于在较长的期间内，某些用户经常使用某些特定对象的情况（例如，在 PaginatedList 和常用的查询关键字结果集中翻页） ，LRU Cache 是一个不错的选择。  
“FIFO” (com.ibatis.db.sqlmap.cache.fifo.FifoCacheController) 。FIFO Cache 实现用“先进先出”原则来确定如何从 Cache 中清除对象。当 Cache 溢出时，最先进入 Cache 的对象将从 Cache 中清除。对于短时间内持续引用特定的查询而后很可能不再使用的情况，FIFO Cache 是很好的选择。
“OSCACHE” (com.ibatis.db.sqlmap.cache.oscache.OSCacheController)  。OSCACHE Cache 实现是OSCache2.0缓存引擎的一个 Plugin。它具有高度的可配置性，分布式，高度的灵活性。
       flushInterval 属性是配置自动更新缓存的周期，可以是hours，minutes，seconds或milliseconds。这一点我测试了一下，设置的60秒更新，通过观察日志，在60秒内，第一次查询数据库，之后iBatis会对同样的sql查询直接返回。超过60秒后的第一次查询，又会执行一次查询。这样看了，这个更新的周期可理解为第一次同样的查询可维持在cache中的时长，超过这个时长的第一次查询会触发实际的数据库操作。

      flushOnExecute这是标识什么时候触发更新，statement的名字就是后面的statement的id。

      statement节中设置了cacheModel，就会把这个sql跟cache关联起来。

      是不是很简单呢，这里面我觉得比较关键的地方就是cacheModel的type选择，一般来说用memory就可以了，但一些特殊的应用，需要根据情况需要配置不同的更适合的cache，以进一步提高查询效率。

最好不要用memory cache。看了下源码其实现原理就是用hashmap作为缓存容器，value用weak-reference，这样虽然在GC时如果内存不足可以释放value，可是其key值还是在数量很多导致内存溢出。

ibatis替换了hibernate  速度不一定就能上来... 

同意,关键还是看对hibernate的理解程度

赞同，出过这种问题...

但ibatis维护简单

==============================================================
如果公司没有dba，再没有明确的sql书写规范，会发现各种各样的sql，维护并不是那么的简单...
感觉最主要的是分析瓶颈出在什么地方，有针对性的优化...用ibatis还是hibernate也要看看具体的业务哈...

若需缓存的数据量大到内置的3种Cache都不能满足，可以自己包装一下xmemcache，后接入一memcache集群，淘宝这样的在线规模，这个模式也够了。

缓存不在于是ibatis还hibernate

在于你是否需要缓存,哪些地方需要缓存,使用率高吗?瓶颈是这里吗?

看来lz对ibatis缓存理解还比较浅，搞不太清楚的技术直接拿来用是比较危险的