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须要漫长的两阶段提交处理，这致使它基本是性能最差的策略。