Hibernate缓存策略

时间:2009-12-03 04:31:08

标签: java hibernate orm ehcache second-level-cache

如何决定使用哪个CacheConcurrencyStrategy

  • NonstrictReadWriteCache
  • ReadOnlyCache
  • ReadWriteCache
  • TransactionalCache

我读过https://www.hibernate.org/hib_docs/v3/api/org/hibernate/cache/CacheConcurrencyStrategy.html,但没有详细解释。

4 个答案:

答案 0 :(得分:44)

Hibernate documentation在定义它们方面做得非常好:

  

19.2.2。策略:只读

     

如果您的应用需要阅读,但是   不修改,持久化的实例   class,可以使用只读缓存。   这是最简单和最优的   执行战略。它甚至是安全的   用于群集。

     

19.2.3。策略:读/写

     

如果应用程序需要更新   数据,读写缓存可能是   适当。这种缓存策略   如果可序列化,则永远不应该使用   事务隔离级别是   需要。如果在a中使用缓存   在JTA环境中,必须指定   属性   hibernate.transaction.manager_lookup_class   并命名获取策略   JTA TransactionManager。其他   环境,你应该确保   交易完成时   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)

  1. 事务性 - 在极少数更新的情况下,将此策略用于读取主要数据,以防止并发事务中的陈旧数据。

  2. 读写 - 在罕见的更新情况下,再次将此策略用于读取主要数据,以防止并发事务中的陈旧数据。

  3. Nonstrict-read-write - 此策略不保证缓存和数据库之间的一致性。如果数据几乎没有变化,并且陈旧数据的可能性很小,则不要使用此策略。

  4. 只读 - 适用于数据的并发策略,永不改变。仅用于参考数据。

  5. 希望这能清除你的怀疑!

相关问题