无法理解查询缓存和 L2C 在休眠中的工作原理

debugcn 发表于 Dev

3235864

我将 Hazelcast 配置为 Hibernate 的 L2C。然后使用带有查询缓存提示的休眠查询构建器发出第一个请求，我得到：

org.hibernate.engine.internal.StatisticalLoggingSessionEventListener:258 - Session Metrics {
    3263961 nanoseconds spent acquiring 1 JDBC connections;
    401548 nanoseconds spent releasing 1 JDBC connections;
    4244272 nanoseconds spent preparing 1 JDBC statements;
    6266312446 nanoseconds spent executing 1 JDBC statements;
    0 nanoseconds spent executing 0 JDBC batches;
    60891580391 nanoseconds spent performing 641667 L2C puts;
    0 nanoseconds spent performing 0 L2C hits;
    8550 nanoseconds spent performing 1 L2C misses;
    0 nanoseconds spent executing 0 flushes (flushing a total of 0 entities and 0 collections);
    0 nanoseconds spent executing 0 partial-flushes (flushing a total of 0 entities and 0 collections)
}

得到了 L2C 的投入。当我执行第二个请求时，我收到了大量通过 id 查找的选择查询。

Hazelcast、Hibernate 的配置很简单，没有什么复杂的。

实体是连接表继承。

@Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 用于超类的注解。

检查 Vlad Mihalcea 文章：https ://vladmihalcea.com/hibernate-query-cache-n-plus-1-issue - 避免 n+1 问题的建议并不完全适合我的情况。

预计会在第二次请求时从缓存中获取结果，但似乎我没有理解查询缓存的真正工作原理。有人可以逐步解释查询缓存的工作原理吗？

拉迪姆·万萨

Hibernate 不会将查询结果作为一个整体存储在“查询”区域中；它而是存储一组 id，其中实体位于其他“实体”区域。

我的猜测：如果某些内容配置错误并且 Hazelcast 本身不存储实体，则有可能虽然从查询缓存中知道条目 ID 列表，但它会逐一加载实际实体。

执行查询并检查缓存区域的大小。

本文收集自互联网，转载请注明来源。

如有侵权，请联系[email protected] 删除。