前兩天，又看了一下原作《ibatis in action》，對快取(cache)一節又仔細閱讀了一次，感覺 ibatis 的 cache 設計有點雞肋的感覺，企業級應用基本不會採用。
[b]1. 快取什麼？[/b]
書中寫道，一般orm框架，如hibernate等，採用物件快取，而ibatis採用的是簡單查詢快取。
簡單 query 快取，意即:
cache.key = sql語句串
cache.value = 查詢結果記錄集合(list等)
對於一條 對映sql語句，執行時其條件值的集合，理論上是乙個無限集，至少條件集會非常大。因此 sql + 條件值的組合數量非常龐大，按結果集合作為 cache.value 的方式快取，可以預計，記憶體消耗非常巨大。
從快取的物件來講，hibernate 等的兩級快取是一種更好的設計( session級快取屬於第一種 )。
物件快取(object cache)，將物件像庫表記錄一樣，按主鍵進行快取，相當於建立乙個簡單的記憶體資料庫；
查詢快取(query cache), 與 ibatis 的快取所指相同，但它只快取結果集的主鍵，因此 cache.value 空間消耗大大減少。
這樣對比可見，ibatis 的cache 不太適合資料量龐大的企業級應用，大型**應用。
[b]2. 快取到哪兒？[/b]
應該說，如果 ibatis沒有提供對 oscache 的預設支援，那麼ibatis的cache僅僅適合單機部署的小型應用。
但 oscache 作為分布式快取的一種，在實際應用中僅佔不大的比例。
對於集群部署的大型應用，如果 ibatis 能提供對 whalin memached, spy memcached,coherence 等提供支援，將是一種更好的選擇。
幸好，ibatis 還提供了 cache 的擴充套件點，可以整合自定義的 cache 方案。 ^_^
寫在iBATIS3 GA之前 Cache
快取，也就是cache 在ibatis2中以其較粗的粒度而為人們所詬病，ibatis3做了哪些改變呢？ibatis為大家帶來了更易於定製和配置的快取 預設地，除了本地的 session 快取外 有點象hibernate的一級快取，系統自己實現 沒有啟用快取。如果啟用二級快取，只要簡單地加一句配置 有...
寫在iBATIS3 GA之前 Cache
快取，也就是cache 在ibatis2中以其較粗的粒度而為人們所詬病，ibatis3做了哪些改變呢？ibatis為大家帶來了更易於定製和配置的快取 預設地，除了本地的 session 快取外 有點象hibernate的一級快取，系統自己實現 沒有啟用快取。如果啟用二級快取，只要簡單地加一句配置 有...
Cache 設計概要
cache設計需要考慮以下問題 1.cache的資料同步問題 2.cache的更新問題 對於資料同步，必須考慮多執行緒相關技術，要點有 1.lock關鍵字 2.readerwriterlock readerwriterlockslim 3.interlocked 4.mutex 5.monitor ...