NHibernate 会话 ObjectDisposeException
是否有办法验证 Session 是否已被 NHibernate 处理掉？
我在 Session 上有一个包装类，它有自己的 Finalizer 和 IDispoable 实现，但是如果在我自己在类中处理它之前 Session 被释放，我最终会收到 ObjectDisposeException。
我真的不想用
try {
...
}
catch (ObjectDisposedException) { }
但我不太确定任何其他方式来包装我的清理代码。 Session.IsOpen 和 Session.IsActive 属性似乎没有为我提供任何可靠的信息来确认会话已被处理。
有关完整源代码，您可以在 上查看它组装。
Is there anyway to verify if a Session has been disposed of by NHibernate?
I have a wrapper class on Session that has it's own Finalizer and IDispoable implementation however if the Session gets disposed before I handle it myself in my class I end up receiving an ObjectDisposedException.
I really don't wish to wrap my clean up code with
try {
...
}
catch (ObjectDisposedException) { }
But I'm not really sure of any other way. The Session.IsOpen and Session.IsActive properties do not seem to offer any reliable information for me to acknowledge the session has been disposed of.
For full source you can view it on Assembla.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好的，只是看了一下您的代码。
我不知道这是否正是问题所在，但您正在从对话 dispose 方法中调用 End()，
它反过来尝试重新连接并处理会话..
如果您在此之前显式调用了 End()，您将得到您所得到的，请避免该调用。
我认为您不应该担心在会话处置之前回滚事务，因为这是隐式完成的。
只是快速浏览了一下，但我想我真的很喜欢你的实现。
Ok, just taked a peek at your code.
I don't know if this is exactly the issue, but you are calling End() from the conversation dispose method,
which in turn tries to reconnect and disposes the session..
if you have eplicitly called End() before this you will get what you get, avoid that call.
I think you shouldn't worry about rolling back the transaction before the session dispose as this is implicitly done.
Just taken a quick look, but i think i really like your implementation.
我一直认为 NHibernate 的最佳实践是“每个请求一个会话”，这意味着它应该只存在于“使用”范围内。
我建议尝试阻止两个人处理会话/对话。 如果您控制会话的创建，您可以将其包装在您自己的 ISession impl 中，该 ISession impl 执行它自己的 IsAlreadyDispose() 检查以防止异常。 尽管如此，考虑到这种努力与“预期的异常”和原始代码看起来并没有那么糟糕。
我还建议您注意终结器的实现。 “Session.Is().InTransaction()”进入Session->Transaction，并且当终结器轮到它时，会话可能为空。 在终结者时期驾驭托管关系并不能保证一定有效。
I always thought best practice with NHibernate was "session per request" meaning that it should only live inside the 'using' scope.
I'd suggest trying to prevent two people from disposing the session/conversation. If you control the creation of sessions you could wrap it in your own ISession impl that performs it's own IsAlreadyDisposed() check to prevent the exception. Still, considering that effort vs "expected exception" and the original code doesn't look so bad.
I'd also suggest watching out with your finaliser implementation. The "Session.Is().InTransaction()" goes Session->Transaction and the session might be null by the time the finaliser gets round to it. Navigating a managed relationship at finaliser time isn't guaranteed to work.
“这是我见过的最荒谬的事情之一，即使在处置后它的 Open 属性仍然保持不变”
为什么您已经处置的对象会包含有关其状态的可靠信息？
你不应该尝试使用已处置的会话，我也不知道 nhibernate 在哪里处置你的会话，你确定你不是自己处置它吗？
"That's one of the most absurd things I've seen to have it's Open property remain true even after disposal"
Why would an object you already have disposed contain reliable information about it's state?.
You shouldn't try to use a disposed session, i don't know where nhibernate is disposing your session either, are you sure you are not disposing it yourself?.