Hibernate 缓存一致性

2019独角兽企业重金招聘Python工程师标准>>>

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

转载于:https://my.oschina.net/u/2500345/blog/616868