在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。
换一种说法:
只读: 对 经常读取但从未更新的 数据很有用(例如,参考数据,如“国家”)。很简单。它拥有所有最佳性能(显然)。
读/写: 如果您的数据需要 更新,则是 理想的。但是它不提供SERIALIZABLE隔离级别,可能会发生幻像读取(您可能会在事务结束时看到开始时不存在的某些内容)。它比只读具有更多的开销。
非严格读/写: 或者,如果不太可能两个单独的事务线程可以更新同一对象,则可以使用非严格读/写策略。它比读写具有更少的开销。这对于 很少更新的 数据很有用。
事务性: 如果您需要 完全事务性 缓存。仅适用于JTA环境。
因此,选择正确的策略取决于是否要更新数据,更新的频率和所需的隔离级别。如果您不知道如何回答要放入高速缓存中的数据的这些问题,请咨询DBA。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)