Hibernate 緩存一致性

ehcache緩存推薦閱讀：

http://blog.csdn.net/angjunqiang/article/details/43155437

hibernate二級緩存推薦閱讀：

http://elf8848.iteye.com/blog/805351

1 只讀緩存 read only 
不需要鎖與事務，由於緩存自數據從數據庫加載後就不會改變。

    若是數據是隻讀的，例如引用數據，那麼老是使用「read-only」策略，由於它是最簡單、最高效的策略，也是集羣安全的策略。是性能第一的策略 。

2 讀寫緩存 read write 
對緩存的更新發生在數據庫事務完成後。緩存須要支持鎖。
在一個事務中更新數據庫，在這個事務成功完成後更新緩存，並釋放鎖。 
鎖只是一種特定的緩存值失效表述方式，在它得到新數據庫值前阻止其餘事務讀寫緩存。那些事務會轉而直接讀取數據庫。
緩存必須支持鎖，事務支持則不是必須的。若是緩存是一個集羣，「更新緩存」的調用會將新值推送給全部副本，這一般被稱爲「推（push）」更新策略(JMS、JGroup方式)。

    若是你的數據是又讀又寫的，那麼使用「read-write」策略。這一般是性能第三的策略，由於它要求有緩存鎖，緩存集羣中使用重量級的「推」更新策略。

3 非嚴格讀寫緩存 nonstrict read write 
在一個事務中更新數據庫，在這個事務完成前就清除緩存，爲了安全起見，不管事務成功與否，在事務完成後再次清除緩存。
既不須要支持緩存鎖，也不須要支持事務。若是是緩存集羣，「清除緩存」調用會讓全部副本都失效，這一般被稱爲「拉（pull）」更新策略。

    若是你的數據讀不少或者不多有併發緩存訪問和更新，那麼能夠使用「nonstrict-read-write」策略。感謝它的輕量級「拉」更新策略，它一般是性能第二好的策略。

4 事務緩存 transactional （必定要在JTA環境中）
對緩存和數據庫的更新被包裝在同一個JTA事務中，這樣緩存與數據庫老是保持同步的。數據庫和緩存都必須支持JTA。

    除非你真的想將緩存更新和數據庫更新放在一個JTA事務裏，不然不要使用「transactional」策略，由於JTA須要漫長的兩階段提交處理，這致使它基本是性能最差的策略。