如何让 NHibernate 缓存获取的子集合？

我有一个相当简单的条件查询来获取子集合，如下所示：

var order = Session.CreateCriteria<Order>()
    .Add(Restrictions.Eq("Id", id))
    .SetFetchMode("Customer", FetchMode.Eager)
    .SetFetchMode("Products", FetchMode.Eager)
    .SetFetchMode("Products.Category", FetchMode.Eager)
    .SetCacheable(true)
    .UniqueResult<Order>();

使用 NH Prof，我已经验证这只需使用冷缓存到数据库进行一次往返（如预期）；然而，在连续执行时，它只检索Order从缓存中获取，然后对图中的每个子实体使用 SELECT(N+1) 访问数据库，如下所示：

Cached query: SELECT ... FROM Order this_ left outer join Customer customer2 [...]
SELECT ... FROM Customer WHERE Id = 123;
SELECT ... FROM Products WHERE Id = 500;
SELECT ... FROM Products WHERE Id = 501;
...
SELECT ... FROM Categories WHERE Id = 3;

等等等等。显然它没有缓存whole查询或图形，仅根实体。第一个“缓存查询”行实际上包含所有join它应该的条件 - 它肯定会缓存查询本身正确，只是不是entities， 显然。

我已经使用 SysCache、SysCache2 甚至 HashTable 缓存提供程序尝试过此操作，并且我似乎总是得到相同的行为（NH 版本 3.2.0）。

谷歌搜索发现了一些古老的问题，例如：

• NH-195：子集合未存储在二级缓存中 https://nhibernate.jira.com/browse/NH-195
• SysCache 和 SysCache2 之间的奇怪差异 https://forum.hibernate.org/viewtopic.php?p=2368641#2368641
• NHibernate – 谨防不当应用的缓存策略 http://ayende.com/blog/4046/nhibernate-beware-of-inadvisably-applied-caching-strategies（Ayende - 当然他只是费心提到什么not去做，而不是如何解决......）

然而，这些似乎早就被修复了，无论我使用哪个提供商，我都会遇到同样的不良行为。

我已经读过关于 SysCache 和 SysCache2 的 nhibernate.info 文档 http://nhibernate.info/doc/nhibernate-reference/caches.html#NHibernate.Caches.SysCache2我似乎没有遗漏任何东西。我尝试过添加cacheRegion线到Web.config文件中涉及查询的所有表，但它不会改变任何内容（而且据我所知，这些元素只是为了无效缓存，所以它们无论如何都不重要）。

所有这些超级老问题似乎都已得到解决/解决，我认为这是不可能的still是 NHibernate 中的一个错误，这一定是我做错了什么。但什么？

将 NHibernate 中的获取指令与二级缓存结合时，我需要做一些特别的事情吗？我在这里缺少什么？

我确实设法弄清楚了这一点，所以其他人终于可以得到直接的答案：

综上所述，我有一段时间对二级缓存和查询缓存的区别感到困惑；杰森的答案在技术上是正确的，但不知怎的，它并不适合我。我是这样解释的：

• 查询缓存会跟踪哪些实体由查询发出。确实如此not缓存整个结果集。这相当于做一个Session.Load在延迟加载的实体上；它知道/预期存在但不跟踪any除非特别询问，否则它会实际加载其他信息real entity.

• 二级缓存跟踪实际的data对于每个实体。当 NHibernate 需要通过 ID 加载任何实体时（凭借Session.Load, Session.Get、延迟加载关系，或者在上面的情况下，是缓存查询一部分的实体“引用”），它将首先在二级缓存中查找。

当然，事后看来，这是完全有道理的，但是当您听到“查询缓存”和“二级缓存”这两个术语在很多地方几乎可以互换使用时，这就不是那么明显了。

本质上，您需要配置两组（每组两个设置）才能看到查询缓存的预期结果：

1. 启用两个缓存

在 XML 配置中，这意味着添加以下两行：

<property name="cache.use_second_level_cache">true</property>
<property name="cache.use_query_cache" >true</property>

在 Fluent NHibernate 中，是这样的：

.Cache(c => c
    .UseQueryCache()
    .UseSecondLevelCache()
    .ProviderClass<SysCacheProvider>())

请注意UseSecondLevelCache上面因为（在发布本文时）它是never上提到的Fluent NHibernate wiki 页面 http://wiki.fluentnhibernate.org/Database_configuration;有几个启用查询缓存但不启用二级缓存的例子！

2.为每个实体启用缓存

仅启用二级缓存几乎没有任何作用，这就是我被绊倒的地方。二级缓存不仅必须启用，而且为您想要缓存的每个单独的实体类进行配置.

在 XML 中，这是在<class>元素：

<cache usage="read-write"/>

在 Fluent NHibernate（非自动映射）中，它是在ClassMap构造函数或放置其余映射代码的任何位置：

Cache.ReadWrite().Region("Configuration");

必须这样做every将被缓存的实体。作为一种约定，可能可以在一个地方进行设置，但是这样您就几乎错过了使用区域的能力（并且在大多数系统中，您不希望缓存事务数据与配置数据一样多）。

就是这样。这实际上并不难，但要找到一个好的、完整的例子却出人意料地困难，尤其是对于 FNH 来说。

最后一点：这样做的自然结果是当与查询缓存一起使用时，它使得急切连接/获取策略变得非常不可预测。显然，如果 NHibernate 发现查询已被缓存，它就会使没有任何努力首先检查是否all甚至any实际实体的数量被缓存。它几乎只是假设它们是，并尝试单独加载每一个。

这就是SELECT N+1灾难的原因；如果 NH 注意到实体不在二级缓存中并且只是按照所写的那样正常执行查询，并使用 fetch 和 future 等，那么这也没什么大不了的。但它并没有这样做；相反，它尝试加载每个实体及其关系、子关系、子子关系等等，一次一个.

因此，除非您明确启用了缓存，否则使用查询缓存几乎没有意义all中的实体entire图表，即使如此，您也需要非常小心（通过过期、依赖关系等），缓存的查询不会比它们应该检索的实体更持久，否则您最终将导致性能下降更差。