NHibernate Session ObjectDisposedException

Question

Есть ли способ проверить, был ли сеанс утилизирован NHibernate?

У меня есть класс-оболочка в Session, который имеет собственную реализацию Finalizer и IDispoable, однако, если Session удаляется до того, как я сам обработаю его в своем классе, я получаю исключение ObjectDisposedException.

Я действительно не хочу оборачивать мой код очистки кодом

try {
...
}
catch (ObjectDisposedException) { }

Но я не совсем уверен в другом. Свойства Session.IsOpen и Session.IsActive, по-видимому, не предоставляют мне никакой достоверной информации, подтверждающей, что сеанс был удален.

Полный текст вы можете посмотреть на Assembla .

Answer 1

Хорошо, просто взглянул на ваш код. Я не знаю, действительно ли это проблема, но вы вызываете End () из метода удаления диалога, который, в свою очередь, пытается восстановить соединение и удаляет сессию. если вы явно вызвали End () до этого, вы получите то, что получите, избегайте этого вызова. Я думаю, вам не следует беспокоиться об откате транзакции до завершения сеанса, поскольку это делается неявно. Просто бросил быстрый взгляд, но я думаю, что мне действительно нравится ваша реализация.

Answer 2

«Это одна из самых абсурдных вещей, которые я видел, что свойство Open остается верным даже после удаления»

Почему объект, который вы уже разместили, содержит достоверную информацию о его состоянии ?. Вы не должны пытаться использовать удаленный сеанс, я не знаю, где nhibernate утилизирует ваш сеанс, вы уверены, что не уничтожаете его самостоятельно?

Answer 3

Я всегда думал, что лучшая практика с NHibernate - это «сессия на запрос», что означает, что он должен жить только внутри области «использования».

using(Session session = new Session())
{
}

Я бы посоветовал попытаться запретить двум людям использовать сеанс / разговор. Если вы управляете созданием сеансов, вы можете обернуть его в свой собственный ISession Impl, который выполняет собственную проверку IsAlreadyDisposed (), чтобы предотвратить исключение. Тем не менее, учитывая, что это усилие против «ожидаемого исключения» и оригинальный код выглядит не так уж плохо.

Я бы также предложил следить за реализацией вашего финализатора. «Session.Is (). InTransaction ()» переходит в Session-> Transaction, и к моменту, когда финализатор возвращается к нему, сессия может быть нулевой. Навигация по управляемым отношениям во время финализатора не гарантируется.