我该如何决定CacheConcurrencyStrategy使用哪个?
CacheConcurrencyStrategy
NonstrictReadWriteCache
ReadOnlyCache
ReadWriteCache
TransactionalCache
我阅读了https://www.hibernate.org/hib_docs/v3/api/org/hibernate/cache/CacheConcurrencyStrategy.html,但没有足够详细地解释。
在Hibernate文档确实在他们定义了很好的工作:
19.2.2。策略:只读 如果您的应用程序需要读取而不是修改持久类的实例,则可以使用只读缓存。这是最简单和最佳的执行策略。在群集中使用它甚至是安全的。 19.2.3。策略:读/写 如果应用程序需要更新数据,则可以使用读写缓存。如果需要可序列化的事务隔离级别,则永远不要使用此缓存策略。如果在JTA环境中使用了高速缓存,则必须指定属性 hibernate.transaction.manager_lookup_class 并命名用于获取JTA的策略TransactionManager。在其他环境中,应确保在调用Session.close()或 时完成事务 Session.disconnect()。如果要在群集中使用此策略,则应确保基础缓存实现支持锁定。内置缓存提供程序不支持锁定。 19.2.4。策略:非严格读/写 如果应用程序仅偶尔需要更新数据(即,如果两个事务很难同时尝试更新同一项目),并且不需要严格的事务隔离,则非严格读写缓存可能是合适的。如果在JTA环境中使用了缓存,则必须指定 hibernate.transaction.manager_lookup_class。在其他环境中,应确保在调用Session.close()或 时完成事务Session.disconnect()。 19.2.5。策略:事务性 事务缓存策略为完全事务缓存提供程序(例如JBoss TreeCache)提供支持。这样的缓存只能在JTA环境中使用,必须指定 hibernate.transaction.manager_lookup_class。
如果您的应用程序需要读取而不是修改持久类的实例,则可以使用只读缓存。这是最简单和最佳的执行策略。在群集中使用它甚至是安全的。
如果应用程序需要更新数据,则可以使用读写缓存。如果需要可序列化的事务隔离级别,则永远不要使用此缓存策略。如果在JTA环境中使用了高速缓存,则必须指定属性 hibernate.transaction.manager_lookup_class 并命名用于获取JTA的策略TransactionManager。在其他环境中,应确保在调用Session.close()或 时完成事务 Session.disconnect()。如果要在群集中使用此策略,则应确保基础缓存实现支持锁定。内置缓存提供程序不支持锁定。
hibernate.transaction.manager_lookup_class
TransactionManager
Session.close()
Session.disconnect()
如果应用程序仅偶尔需要更新数据(即,如果两个事务很难同时尝试更新同一项目),并且不需要严格的事务隔离,则非严格读写缓存可能是合适的。如果在JTA环境中使用了缓存,则必须指定 hibernate.transaction.manager_lookup_class。在其他环境中,应确保在调用Session.close()或 时完成事务Session.disconnect()。
事务缓存策略为完全事务缓存提供程序(例如JBoss TreeCache)提供支持。这样的缓存只能在JTA环境中使用,必须指定 hibernate.transaction.manager_lookup_class。
换一种说法:
只读: 对 经常读取但从未更新的 数据很有用(例如,参考数据,如“国家”)。很简单。它拥有所有最佳性能(显然)。
读/写: 如果您的数据需要 更新,则是 理想的。但是它不提供SERIALIZABLE隔离级别,可能会发生幻像读取(您可能会在事务结束时看到开始时不存在的某些内容)。它具有比只读更多的开销。
非严格读/写: 或者,如果不太可能两个独立的事务线程可以更新同一对象,则可以使用非严格读/写策略。它比读写具有更少的开销。这对于 很少更新的 数据很有用。
事务性: 如果您需要 完全事务性 缓存。仅适用于JTA环境。
因此,选择正确的策略取决于是否要更新数据,更新的频率和所需的隔离级别。如果您不知道如何回答要放入高速缓存中的数据的问题,请向DBA寻求支持。