NHibernate的 - 随机出现的＆QUOT;无法找到持留＆QUOT;

问题描述

我看过很多帖子回复：上述问题（无法找到持留）。但是，我们遇到的问题是，在我们的web应用程序（ASP.Net MVC）随机出现此错误。此外，当我们重新启动应用程序池的问题消失。

I've seen many posts Re: the above problem (Unable to locate persister). However the problem we are having is that this error occurs randomly in our web application (ASP.Net MVC). Also when we restart the app pool the problem goes away.

大多发生于那些被缓存的实体错误。请参见下面的映射。

Mostly the error happens for an entity that is cached. See mappings below.

  <class name="Privilege" table="PRIVILEGE" lazy="false">
<cache usage="nonstrict-read-write"/>
<id name="Id" />
<property name="Description" column="DESCRIPTION" not-null="true" />
<set name="RoleCollection" table="PRIVILEGE_ROLE">
  <cache usage="nonstrict-read-write"/>
  <key column="PRIVILEGE_ID" foreign-key="PRIVILEGE_ROLE_FK1" />
  <many-to-many class="Role" column="ROLE_ID" foreign-key="PRIVILEGE_ROLE_FK2" />
</set>

<class name="Role" table="ROLE" lazy="false" >
<cache usage="nonstrict-read-write"/>
<id name="Id"  />
<property name="Description" column="DESCRIPTION" not-null="true" />
<set name="PrincipalCollection" table="ROLE_PRINCIPAL">
  <cache usage="nonstrict-read-write"/>
  <key column="ROLE_ID" foreign-key="ROLE_PRINCIPAL_FK1" />
  <many-to-many class="Principal" column="PRINCIPAL_ID" foreign-key="ROLE_PRINCIPAL_FK2" />
</set>

难道这是关系到一个国家文物局会议的腐败？我们高度倒是AP preciate如果有人至少可以为我们指出解决此方向，因为它是不可能要么一致地重现该问题。 （我们使用NHB 3.1.0.4000）

Could this be related to a NHb Session corruption? We'd highly appreciate if someone could at least point us in a direction of troubleshooting this as it's not possible to consistently reproduce the problem either. (We use NHb 3.1.0.4000)

推荐答案

对不起来晚提供更新。

我已经想通了这样做的原因，这恰好是NHibernate会话工厂正在初始化的方式。

I've figured out the reason for this and it happens to be the way the Nhibernate Session Factory was being initialized.

1. 的NHB会议厂懒启动。即在需要DB会话的第一HTTP请求。 （即只有当它正在积极创建要求）


2. 一旦创建它的重复使用，因为它是一个单身


3. 我们已经配置了应用程序池回收每一天（4点），我们注意到异常的第一次出现也是在同一时间框架大致下降。


4. 这个问题看起来像IIS多threadeding和NHB会话工厂实施的结合，当用户（HTTP）请求落在应用程序池回收的窗口内。

解决方案

1. 回到急切初始化。即在NHB会话工厂的初始化，现在发生的事情在的Application_Start。


2. 因此，一个HTTP的用户请求总是需要使用一个现成的会话因素。

这不仅是方法固定的问题，我认为这是从性能上来看是更好的选择。急切地做会话初始化工厂的代价高昂的操作，而不是把更多的重量在一个特定的用户请求是更好地反映手头的问题。

Not only is this approach fixed the issue, I think it's a better option from a performance point of view. Eagerly doing the costly operation of Session Factory initialization rather than putting more weight on a particular user request is more reflective of the problem at hand.

我们现在正在运行在督促这款改装版一个月没有任何问题。

We are running this modified version in prod for a month now without any issues.

这篇关于NHibernate的 - 随机出现的＆QUOT;无法找到持留＆QUOT;的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！