Интересное учебное руководство доступно здесь . Надо надеяться, это будет действовать как введение для Вас.
То, что другие сказали, правда, но они не указали, что проблема отсутствия контроля транзакций самостоятельно заключается в том, что если вы выполняете несколько операций NHibernate без явной транзакции, каждая из этих операций будет выполняться в отдельных транзакциях .
Таким образом, вы можете легко получить несогласованность между операциями. Явно запуская транзакцию NHibernate, а затем выполняя в ней операции, вам гарантируется согласованность этих операций.
Это, конечно, верно для ЛЮБОГО уровня доступа к данным, который неявно запускает транзакции за вас, если вы этого не сделаете. Это не ограничивается NHibernate.
Этот пост от одного из авторов может содержать ваш ответ:
Даже если мы только читаем данные, мы хотите использовать транзакцию, потому что используя транзакцию, убедитесь, что мы получаем согласованный результат из базы данных. NHibernate предполагает, что любой доступ к база данных сделана под сделка, и настоятельно не рекомендую любое использование сеанса без транзакции.
Оставляя в стороне вопрос безопасности работая с транзакциями, предположение, что транзакции дорогостоящие, и нам нужно их оптимизировать. ложный. Как уже упоминалось, базы данных всегда работают в сделка. И базы данных были сильно оптимизирован для работы с транзакции. Вопрос в том это за заявление или за пакет. Есть некоторый объем работы, которая требует необходимо сделать для создания и размещения транзакции, и необходимо сделать это за заявление на самом деле дороже, чем делать это за пакет.
var fooIdFromDb = ExecuteQuery("Select Id from Foo where something = somethingelse");
var barsFromDb = ExecuteQuery("Select * from Bar where FooId = " + fooIdFromDB);
Что, если какая-то другая транзакция удалит строки из Bar между двумя запросами? У вас возникнут проблемы с фантомными данными. Это не специфическая проблема NHibernate. У вас будет такая же проблема с любым другим видом доступа к базе данных без использования транзакций. Вам следует прочитать руководство по транзакциям в целом, а не руководство NHiberante.
Давайте сосредоточимся на том, что произойдет, если вы не будете использовать транзакции. Обычно, но не обязательно, вы закрываете сеанс в конце обработки, но до того, как вы начнете читать данные (т. Е. Представление). Этот метод распространяется под термином « Открытый сеанс в представлении » (хотя он, очевидно, имеет шаблон для предотвращения чтения перед закрытием). Этот шаблон часто используется в веб-приложениях, где сеанс открывается при поступлении запроса и закрывается непосредственно перед записью в поток ответа.
(N) Hibernate требует сеанса и транзакции. Когда вы читаете без использования явной транзакции, транзакция будет настроена для вас. Когда вы читаете после того, как транзакция зафиксирована, поведение зависит от конфигурации и драйвера NH.
И ODBC, и JDBC не определяют, что происходит, когда соединение закрывается и есть незафиксированные или неподтвержденные данные. При повторном открытии соединения возможно автоматическое начало новой транзакции.
Использование нетранзакционного доступа можно использовать только вместе с настройкой auto-commit
явно в конфигурации NHibernate. В противном случае используется драйвер по умолчанию, и он может работать, а может и не работать.
Короче говоря, существует много недостатков и неопределенного поведения, когда вы не используете транзакции при чтении. Это будет работать часто, но это зависит от конфигурации, применяемых шаблонов, драйверов. Существует большая вероятность того, что вы получите LazyInitializationException
, что является обычным результатом чтения после фиксации без открытия новой транзакции.
«Лучшая практика» - использовать одну транзакцию для чтения / записи и другую только для чтения. Это кратко описано в предыдущей ссылке, раздел «Могу ли я использовать две транзакции в сеансе», но требует дополнительной реализации.
Это не только «использовать транзакции для чтения», это также: «использовать ту же транзакцию, которую вы используете для записи для чтения». (а затем, пока это правда, фактическое приложение будет зависеть от ваших текущих шаблонов, количества уровней, кеширования и конфигурации).
Обновление: немного расширено, устранены некоторые двусмысленности