如何决定使用哪个CacheConcurrencyStrategy？
NonstrictReadWriteCache，ReadOnlyCache，ReadWriteCache，TransactionalCache。我读过https://www.hibernate.org/hib_docs/v3/api/org/hibernate/cache/CacheConcurrencyStrategy.html，但没有详细解释。
答案 0 :(得分：44)
Hibernate documentation在定义它们方面做得非常好：
19.2.2。策略：只读
如果您的应用需要阅读，但是 不修改，持久化的实例 class，可以使用只读缓存。 这是最简单和最优的 执行战略。它甚至是安全的 用于群集。
19.2.3。策略：读/写
如果应用程序需要更新 数据，读写缓存可能是 适当。这种缓存策略 如果可序列化，则永远不应该使用 事务隔离级别是 需要。如果在a中使用缓存 在JTA环境中，必须指定 属性
hibernate.transaction.manager_lookup_class并命名获取策略 JTATransactionManager。其他 环境，你应该确保 交易完成时Session.close()或 调用Session.disconnect()。如果你 想要在一个中使用这个策略 集群，你应该确保 底层缓存实现 支持锁定。内置缓存 提供者不支持锁定。19.2.4。策略：非严格读/写
如果申请只是偶尔 需要更新数据（即如果是的话） 两个人极不可能 交易会尝试更新 相同的项目同时），严格 不需要事务隔离， 非严格读写缓存可能是 适当。如果在a中使用缓存 JTA环境，必须指定
hibernate.transaction.manager_lookup_class。 在其他环境中，你应该 确保交易 在Session.close()或完成时完成Session.disconnect()被称为。{/ p>19.2.5。策略：交易
事务缓存策略 完全提供支持 事务性缓存提供者，如 JBoss TreeCache。这样的缓存只能 用于JTA环境和你 必须指明
hibernate.transaction.manager_lookup_class。
换句话说：
只读：对于经常阅读但从未更新的数据非常有用（例如国家/地区等参考数据）。很简单。它具有最好的表现（显然）。
读/写：如果您的数据需要进行更新，则需要。但它没有提供SERIALIZABLE隔离级别，phantom reads可能会发生（您可能会在事务结束时看到某些事情在开始时不存在）。它具有比只读更多的开销。
非严格读/写：或者，如果两个单独的事务线程不可能更新同一个对象，则可以使用非严格读写策略。它具有比读写更少的开销。这个对于很少更新的数据非常有用。
交易：如果您需要完全交易缓存。仅适用于JTA环境。
因此，选择正确的策略取决于数据是否正在更新的事实，更新的频率和所需的隔离级别。如果您不知道如何回答要放入缓存的数据的这些问题，可以向DBA寻求一些支持。
答案 1 :(得分：5)
READ_ONLY：仅用于从不更改的实体（如果尝试更新此类实体，则抛出异常）。它非常简单和高效。非常适合一些不会改变的静态参考数据。
NONSTRICT_READ_WRITE：在更改受影响的数据的事务已提交后，将更新缓存。因此，不能保证强一致性，并且存在可以从高速缓存获得陈旧数据的小时间窗口。这种策略适用于能够容忍最终一致性的用例。
READ_WRITE：此策略保证了通过使用“软”锁实现的强一致性：当更新缓存实体时，软锁也存储在该实体的缓存中，这是在交易提交后发布。访问软锁定条目的所有并发事务将直接从数据库中获取相应的数据。
TRANSACTIONAL：缓存更改在分布式XA事务中完成。在同一XA事务中，缓存实体中的更改将在数据库和缓存中提交或回滚。
答案 2 :(得分：4)
阅读API文档是件好事，但你也应该阅读文档（它很棒），Second Level Cache - Strategies。
答案 3 :(得分：0)
事务性 - 在极少数更新的情况下，将此策略用于读取主要数据，以防止并发事务中的陈旧数据。
读写 - 在罕见的更新情况下，再次将此策略用于读取主要数据，以防止并发事务中的陈旧数据。
Nonstrict-read-write - 此策略不保证缓存和数据库之间的一致性。如果数据几乎没有变化，并且陈旧数据的可能性很小，则不要使用此策略。
只读 - 适用于数据的并发策略，永不改变。仅用于参考数据。
希望这能清除你的怀疑！