带 ehcache 的集群休眠缓存：非严格与严格读写答案

【问题标题】：Clustered hibernate cache with ehcache: nonstrict vs. strict read write带 ehcache 的集群休眠缓存：非严格与严格读写
【发布时间】：2011-07-02 01:34:04
【问题描述】：

nonstrict-read-write 和 read-write 之间的真正区别是什么？我可以阅读 ehcache 和 Hibernate 文档，但据我所知，他们只说“如果您进行更新，读写会更好”。我觉得不满意。

我可能对这样配置的长期缓存集合有疑问：

<cache name="trx.domain.Parent.children" maxElementsInMemory="5000"
    eternal="false" overflowToDisk="false" timeToIdleSeconds="1200"
    timeToLiveSeconds="1800">
    <cacheEventListenerFactory
        class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
        properties="replicateAsynchronously=true, replicatePuts=true, replicateUpdates=true, replicateUpdatesViaCopy=false, replicateRemovals=true" />

<set name="children" lazy="false" inverse="true">
    <cache usage="nonstrict-read-write"/>
    <key column="callout_id" />
    <one-to-many class="Child" />
</set>

当集合更新时，在更新发生的节点和其他节点上究竟会发生什么？ nonstrict-read-write 和 read-write 这里有什么区别？节点是否有可能使用缓存中的 10 分钟陈旧版本？

注意冗长的超时和异步复制。

【问题讨论】：

标签： java hibernate ehcache distributed-caching

【解决方案1】：

读写：如果两个事务试图修改数据，则这些事务在“已提交读”级别（或可重复读，如果数据库设置为该级别）隔离 - 通常这就足够了，通常我们不需要“可序列化”隔离级别。

非严格读写：缓存根本没有锁定，所以如果两个事务修改数据我们永远不知道我们得到了什么，我们不能保证缓存状态=数据库状态。

只有当两个事务同时修改数据的可能性很小时，这才是安全的。我们也需要设置合适的缓存超时时间。

更多细节和很好的解释请看这里：hibernate cache strategy

【讨论】：

【解决方案2】：

NONSTRICT_READ_WRITE：在提交更改受影响数据的事务后更新缓存。因此，不能保证强一致性，并且有一个很小的时间窗口可以从缓存中获取陈旧数据。这种策略适用于可以容忍最终一致性的用例。

READ_WRITE：此策略通过使用“软”锁来保证强一致性：当缓存的实体被更新时，软锁也会存储在该实体的缓存中，即事务提交后释放。所有访问软锁定条目的并发事务都将直接从数据库中获取相应的数据。

【讨论】：