加速你的Hibernate引擎（下） - 编程入门网

4.8 二级缓存调优

HRD第20.2节 “二级缓存”中的描述对大多数开发者来说过于简单，无法做出选择。3.3版及以后版本不再推荐使用基于“CacheProvider”的缓存，而用基于“RegionFactory”的缓存，这也让人更糊涂了。但是就算是最新的3.5参考文档也没有提及如何使用新缓存方法。

出于下述考虑，我们将继续关注于老方法：

所有流行的Hibernate二级缓存提供商中只有JBoss Cache 2、Infinispan 4和Ehcache 2支持新方法。OSCache、SwarmCache、Coherence和Gigaspaces XAP-Data Grid只支持老方法。

两种方法共用相同的<cache>配置。例如，它们仍旧使用相同的usage属性值“transactional|read-write|nonstrict-read-write|read-only”。

多个cache-region适配器仍然内置老方法的支持，理解它能帮助你快速理解新方法。

加速你的Hibernate引擎（下）(4)

4.8.1 基于CacheProvider的缓存机制

理解该机制是做出合理选择的关键。关键的类/接口是CacheConcurrencyStrategy和它针对4中不同缓存使用的实现类，还有EntityUpdate/Delete/InsertAction。

针对并发缓存访问，有三种实现模式：

无论是锁还是事务都没影响，因为缓存自数据从数据库加载后就不会改变。

对缓存的更新发生在数据库事务完成后。缓存需要支持锁。

对缓存和数据库的更新被包装在同一个JTA事务中，这样缓存与数据库总是保持同步的。数据库和缓存都必须支持JTA。尽管缓存事务内部依赖于缓存锁，但Hibernate不会显式调用任何的缓存锁函数。

针对“read-only”的只读模式。

针对“read-write”和“nonstrict-read-write”的非事务感知（non-transaction-aware）读写模式。

针对“transactional”的事务感知读写。

以数据库更新为例。EntityUpdateAction对于事务感知读写、“read-write”的非事务感知读写，还有“nonstrict-read-write”的非事务感知读写相应有如下调用序列：

软锁只是一种特定的缓存值失效表述方式，在它获得新数据库值前阻止其他事务读写缓存。那些事务会转而直接读取数据库。

缓存必须支持锁；事务支持则不是必须的。如果缓存是一个集群，“更新缓存”的调用会将新值推送给所有副本，这通常被称为“推（push）”更新策略。

既不需要支持缓存锁，也不需要支持事务。如果是缓存集群，“清除缓存”调用会让所有副本都失效，这通常被称为“拉（pull）”更新策略。

在一个JTA事务中更新数据库；在同一个事务中更新缓存。

软锁缓存；在一个事务中更新数据库；在上一个事务成功完成后更新缓存；否则释放软锁。

在一个事务中更新数据库；在上一个事务完成前就清除缓存；为了安全起见，无论事务成功与否，在事务完成后再次清除缓存。

对于实体的删除或插入动作，或者集合变更，调用序列都是相似的。

实际上，最后两个异步调用序列仍能保证数据库和缓存的一致性（基本就是“read committed”的隔离了级别），这要归功于第二个序列中的软锁和“更新数据库”后的“更新缓存”，还有最后一个调用序列中的悲观“清除缓存”。

基于上述分析，我们的建议是：　

依笔者看来，二级缓存并非一级数据源，因此使用JTA也未必合理。实际上最后两个调用序列在大多数场景下是个不错的替代方案，这要归功于它们的数据一致性保障。

如果数据是只读的，例如引用数据，那么总是使用“read-only”策略，因为它是最简单、最高效的策略，也是集群安全的策略。

除非你真的想将缓存更新和数据库更新放在一个JTA事务里，否

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!