我在 ASP.NET 会话中缓存了 NHibernate 会话。
我遇到过一种情况，用户编辑了一个对象，因此它位于 ISession 的第一级缓存中。然后另一个用户编辑了同一个对象。
此时，用户 1 仍然可以看到其编辑的原始版本，而用户 2 可以看到对象的正确状态？
处理此问题的正确方法是什么，而无需始终为每个对象显式调用 session.Refresh(myObj) ？
我还启用了二级缓存。对于 NHibernate 长会话，我应该完全禁用第一级缓存吗？
编辑：为我希望从 10.4.1.具有自动版本控制的长会话本节的结尾是
由于 ISession 也是（强制的）一级缓存并包含所有加载的对象，因此我们可以仅在少数请求/响应周期中使用此策略。这确实是推荐的，因为 ISession 很快也会有过时的数据。
我不确定这是什么类型的文档，可能会包含两者，然后立即说会话将具有过时的数据（这就是我所看到的）。这里有什么解决方案吗？还是没有？
I have NHibernate sessions cached in the ASP.NET session.
I came across a situation where a user edited an object so it's in their first level cache in the ISession. Another user then edited the same object.
At this point User1 still sees their original version of their edits where as User2 sees the correct state of the object?
What is the correct way to handle this without manually calling session.Refresh(myObj) explicitly for every single object all the time?
I also have a 2nd level cache enabled. For NHibernate Long Session should I just disable the first level cache entirely?
Edit: Adding some more terminology to what I'm looking to achieve from 10.4.1. Long session with automatic versioning the end of this section concludes with
As the ISession is also the (mandatory) first-level cache and contains all loaded objects, we can propably use this strategy only for a few request/response cycles. This is indeed recommended, as the ISession will soon also have stale data.
I'm not sure what kind of documentation this is for it to include both probably and then immediately say the session will have stale data (which is what I'm seeing). What's the solution to this right here or is there none?
发布评论
评论（3）
只需使用 IStatelessSession 而不是 ISession 即可。
另请记住，NH 并非设计用于长期存在的 ISession（正如其他人已经提到的）。一个问题是你已经提到的。另一个是当 NH 跟踪的对象图很大时，性能会显着下降。使用 IStatelesSession 可以避免这两个问题。
它为您提供不被 NH 跟踪的分离对象。
不确定将会话保留在 ASP.NET 会话中的原因。也许您可以提供一些细节？
另请记住，会话是 IDbConnection 的包装器。保持它打开很容易导致连接池饥饿。
Just use IStatelessSession instead of ISession.
Also keep in mind that NH wasn't designed to be used with long-living ISessions (as already mentioned by others). One problem is that you already mentioned. The other is that the performance drops significantly when there's a large object graph tracked by NH. Both problems could be avoided by using IStatelesSession.
It gives you detached objects not being tracked by NH.
Not sure about the reasoning behind keeping sessions in the ASP.NET session. Maybe you could provide some details?
Also remember that a session is a wrapper over IDbConnection. Keeping it open can easily lead to conneciton pool starvation.
显然，这是 NHibernate 的一个已知缺点，我的问题中引用的文档对此进行了详细说明。
Apparently this is a known shortcoming of NHibernate as detailed by documentation cited in my question.