【问题标题】:Some clarifications about Hibernate caching mechanism?关于 Hibernate 缓存机制的一些说明?
【发布时间】:2011-09-21 13:02:55
【问题描述】:

我对通过休眠缓存教程时发现的语句有疑问。

Statement1:-一级缓存始终与Session对象关联。 Hibernate 默认使用这个缓存。

问题1:-
由于此缓存默认保存来自会话方法(如加载、获取等)的所有结果。由于保存所有对象,这不会是主要的内存问题吗?

问题2:-
我们是否需要默认启用此缓存或其那里?如果需要,我可以禁用一级缓存吗?如果是怎么办?

以下问题适用于一级和二级缓存

问题3:-
如果我从缓存中获取相同的对象(例如,我在同一个会话中两次使用 customerid 1 加载对象客户)从缓存返回的两个对象将具有来自缓存中对象的不同引用。 对吗?因为如果我更新客户对象中的某些字段,它不应该反映在缓存中,除非调用 save/update 方法。

问题4:-
根据我的理解,如果我们尝试从 id 1 第二次从该缓存中获取客户对象,即使在两者之间进行了更新,它也会返回相同的旧对象。 我们如何确保它是否已更新它从数据库中读取,否则从缓存中读取? 我想我们可以使用像 EHCache 之类的类的读写缓存策略

问题 5:- 关于查询缓存
我读了这个声明:-查询中的更新经常发生。因此,对于查询缓存,需要两个缓存区域。

用于存储结果。(仅缓存标识符值和值类型的结果)。 用于存储最新的更新。

我认为“查询中的更新经常发生”意味着在这里我们通常会更改一些参数值,例如 select * from customer where custid=? 所以id 将针对不同的客户 ID 进行更改。因此查询缓存将保留每个查询(连同参数)和每个查询返回的结果。

对吗?但不确定为什么我们需要两个缓存区域来进行查询缓存?

【问题讨论】:

    标签: hibernate


    【解决方案1】:

    AFAIK
    答案 01:

    Hibernate 缓存加载的对象以避免不必要的数据库访问。避免持久性上下文的最简单方法是使用StatelessSession。 Stateless Hibernate Session 没有脏检查责任,因此可以很好地满足您没有一级缓存(持久上下文)的要求。

    答案 02:

    1. 您不必启用一级缓存

    答案 03

    1. 如果一个对象在同一个会话中使用它的身份被加载两次,Hibernate 会确保返回同一个对象,而不管是否启用了二级缓存。让我澄清一下二级缓存不缓存对象实例。它维护实例的序列化(不完全是)版本。 下面link简单解释了hibernate二级缓存的结构。

    很抱歉,我无法理解“更新客户对象并且它没有反映在缓存中”背后的概念。我希望该链接能澄清您的问题。

    答案 04

    1. 如果配置不正确,确实会出现从缓存中获取过时数据的问题。 如果缓存上的过期时间尚未发生,则将获取状态数据。可以使用Session.evict() 执行驱逐,但是您可能不清楚需要驱逐哪些数据。因此,缓存应该始终是优化数据库访问的最后一步。 通过重新评估集合关系上的关联和获取计划,可以实现良好的优化水平,从而避免 N+1 选择问题,同时避免。

      EHCache为未更新的数据提供read-write 缓存策略 符合事务read committed 保护。那就是避免dirty reads,但不能帮助反对repeatable reads

    查看EHCache配置here

    答案 05:查询缓存

    1. 查看这些链接以更好地了解会话缓存和查询缓存
      答:Session Cache
      B.Second Level Cache
      C.Query Cache

    2. Checkout this link 对查询缓存的结构进行了简要/简单的解释。

    希望这会有所帮助。

    【讨论】:

    • 感谢 rictionlesspulley 如此详尽的回复。我有这些后续查询。正如你所说“让我澄清一下二级缓存不缓存对象的实例。它维护实例的序列化(不完全)版本”“我没有明白你所说的序列化版本的cahe是什么意思?关于EH CAche,正如你所说,我们可以在 ression 中读取已提交的事务。这就是我所需要的。
    • 如果您转到答案 05 中的第二个链接,您将确切地看到对象是如何存储在二级缓存中的。我的意思是*缓存对象的序列化版本*不是缓存本身。
    • 关于EHCache的读写缓存策略一定要设置合适的缓存过期时间!
    猜你喜欢
    • 2015-06-22
    • 2011-06-17
    • 2011-02-04
    • 1970-01-01
    • 2020-04-28
    • 2021-09-28
    • 2019-05-14
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多