前兩天,又看了一下原作《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 ...