深入iBatis的Cache

  概述

• iBatis對查詢結果集進行本地緩存。
• Cache的key由haskcode、checksum、查詢參數、sqlmap Id、sql語句、調用方法名等構成。由此可以看出，不同的參數會有不同的Key。注意，他不是以查詢參數的Class的hashcode或toString方法作爲key的一部分，而是以在sqlmap使用的變量的集合。
• queryForObject和queryForList都可以緩存。其它片斷不支持。
• 可以設定爲定時刷新或受條件觸發刷新Key。如：在執行Update的時候，可以刷新Cache。
  刷新Cache時，無法手動控制刷新單條記錄。只能刷新該Cache ID的全部Cache。
• 目前有4種Cache實現，但是無法自定義擴展Cache。
• Cache的數量可以指定。
• Cache的put和get方法內有同步，外部無。所以同一參數同時查詢時，Cache是不能命中的。在有一個結果put到Cache後，後續查詢才能命中。 

相關示例代碼如下： 

<cacheModel id="lruCache" type="LRU" serialize="true" readOnly="false">
        <property name="reference-type" value="WEAK"/>
        <flushOnExecute statement="insertAccount"/>
        <flushOnExecute statement="updateAccount"/>  
        <flushOnExecute statement="deleteAccountById"/>
    </cacheModel>

 <select id="selectAccountById" parameterClass="int" resultClass="Account" cacheModel="lruCache">
    select      ACC_ID as id,      ACC_FIRST_NAME as firstName,
      ACC_LAST_NAME as lastName,      ACC_EMAIL as emailAddress    from ACCOUNT    where ACC_ID = #id# 
  </select>

  <update id="updateAccount" parameterClass="Account">
  update ACCOUNT set ACC_FIRST_NAME=#firstName# , ACC_LAST_NAME = #lastName# ,  ACC_EMAIL =#emailAddress# where ACC_ID = #id# 
  </update>

 

Cache規則

• Type 目前有4種實現。建議用LRU或者OsCache
• readOnly，表示Cache對象是否只讀。False，表示外部更改cache內容無效。
• Serialize，是否序列化。true，表示存貯到cache中的是系列化後的對象。
• 組合：
  • readOnly=false, Serialize=false：Cache Session有效。如:1+n時，下次1+n將會失效。 不系列化，外部更改有效。
  • readOnly=true, Serialize=false：所有session共享Cache，取出時實例是同一個。不系列化，外部更改有效。默認的
  • readOnly=false, Serialize=true：所有session共享Cache，取出時實例不一樣，但是內容一樣。 系列化，外部更改無效
  • readOnly=true, Serialize=true： 同默認效果一樣。
  • 看得出，主要是通過系列化來保證外部更改屬性後不影響其它session的取出的結果。 

4種Cache實現

1. LRU，最後使用的排到前面。Cache溢出時，最遠被使用的就被clear。
2. FIFO，先進先出。
3. Memory，內存引用。該實現無數量限制。前兩種是基於jvm實現。
   • WEAK，產生內存回收動作時，失效。
   • SOFT，內存不足時，失效。
   • STRONG，顯式刷新時，失效。
4. OsCache(支持分佈式)。通過oscahce.properties控制。 

適應範圍

1. 頻繁查詢，很少更改的內容。如：分類等。
2. 1+n查詢。n是父類，數據量較少。如：查詢Spu信息時，同意需要獲得其品類信息。
3. 效率低，執行頻率高的SQL。如統計一類的SQL。
4. 有了Cache機制後，1+n不再可怕。

原創文章，需要轉載需經本人同意！