当抛出 EndPointNotFoundException WCF 调用异常时，NHibernate 会话（每个请求的会话）被关闭，如何解决此问题？
我们使用 Spring.NET 进行依赖注入，使用 NHibernate 作为 ORM。我们使用“Session Per Request”模型，并且会话是使用 Spring.NET 创建的。在其中一个页面中，有一个网络服务调用。当Web服务调用抛出EndPointNotFoundException异常时，NH会话被关闭，我们得到“延迟初始化异常：”无法延迟初始化角色集合：，没有会话或会话被关闭（我们有一个Person对象，它被加载到页面加载，但 Person 对象具有一组延迟加载的集合，如地址等。当访问其中一个延迟加载的集合时，会引发错误）。如果没有抛出异常，则一切正常。有快速的解决办法吗？
We are using Spring.NET for Dependency Injection and NHibernate as ORM. We use Session Per Request Model and the session is created using Spring.NET. In one of the page, There is a webservice call. When the web service call throws EndPointNotFoundException exception, the NH Session gets closed and we get 'Lazy Initialization exception : 'failed to lazily initialize a collection of role: , no session or session was closed(We have a Person objects, that gets loaded in the page load, but the Person objects has set of lazily loaded collections like addresses etc. the error is thrown when one of the lazily loaded collection is accessed). If the exception is not thrown,everything works correctly. Is there a quick solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
需要更多信息，但我会尝试进行计算猜测：
抛出的异常未得到处理，或者如果处理则重新抛出。
异常传播到页面错误处理程序。
无论哪种方式，沿着异常气泡管道的某个地方，异常处理程序都会调用 ISession.Close() ，然后消耗异常（因此程序执行通过页面的呈现继续进行）
这并不罕见，通常在执行以下操作时回滚事务时，建议同时关闭
ISession。请注意，回滚+关闭可能会在失败的提交上执行，在这种情况下，失败的 Web 服务调用会以某种方式污染您的对象状态，从而导致提交失败。异常再次被处理和消耗。
本质细节是，某些包含代理 nhibernate 实体的代码路径仍然可以执行并尝试引用关闭的
ISessionMore information is required but i'll try to make a calculated guess:
The exception thrown is not handled, or if handled is re-thrown.
The exception propagates to the page error handler.
Either way somewhere along the exception bubble pipeline an exception handler calls
ISession.Close()and then consumes the exception (and thus program execution continues via the rendering of the page)This is not uncommon and usually when doing a rollback on the transaction it is advised to also close the
ISession.Note, that a rollback+close may be performed on a failed commit, in which case the failed webservice call somehow pollutes your object state and thus the commit fails. Again the exception is handled and consumed.
The nitty gritty detail is that some code-path that contains proxied nhibernate entities still gets to execute and tries to reference the closed
ISession