Не сбрасывайте сессию после того, как исключение произойдет - NHibernate
Возвратите false, предотвратит навигацию. Иначе местоположение стало бы возвращаемым значением someFunc
2 ответа
Наконец-то я нашел решение своей проблемы. На случай, если людям будет интересно, я публикую решение здесь.
public class SimpleRoleProvider : RoleProvider
{
// isolated session management for the RoleProvider to avoid
// issues with automated management of session lifecycle.
public override string[] GetRolesForUser(string username)
{
using (var session = GlobalSetup.SessionFactory.OpenSession())
{
var users = new UserRepository(session);
var user = users.Get(username);
// no role if user is not registered
if (null == user) return new string[0];
// default role for registered user
return user.IsManager ? new[] {"Manager", "User"} : new[] {"User"};
}
}
}
По сути, происходило то, что репозиторий RoleProvider , похоже, не имеет того же жизненного цикла, что и обычные репозитории in-view / in-controller . В результате к моменту вызова RoleProvider сеанс NHibernate уже был удален, что привело к исключению, наблюдаемому здесь выше.
Я заменил код следующим здесь. У этого есть собственное управление сеансом NHibernate, и в итоге он работает нормально.
Вы никогда не должны перехватывать исключения и игнорировать их во время транзакции NHibernate.
Я пытаюсь объяснить почему.
Могут быть исключения, например, вызванные ограничениями в базе данных. (это также может быть вызвано проблемами сопоставления, исключениями, вызванными свойствами или чем-то еще.) NHibernate пытается синхронизировать состояние в памяти с базой данных. Это делается при фиксации - а иногда и перед запросами, чтобы убедиться, что запросы выполняются на реальных данных. Когда эта синхронизация не удается, состояние в базе данных является чем-то случайным , некоторые изменения сохраняются, другие - нет. Единственное, что вы можете сделать в таком случае, - это закрыть сеанс.
Учтите, что решения и вычисления в вашем коде основаны на значениях в памяти . Но - в случае игнорируемого исключения, эти значения не являются значениями в базе данных, их там никогда не будет. Таким образом, ваша логика будет принимать решение и вычислять «фантазийные данные».
Между прочим, никогда не стоит перехватывать какие-либо исключения (нетипизированные) и игнорировать их . Вы всегда должны знать, какие исключения вы обрабатываете, и быть уверенным, что можете продолжить.
То, что вы здесь делаете, это проглатывает ошибки программирования. Поверьте, стабильнее система не будет. Вопрос только в том, замечаете ли вы ошибку, когда она возникает, или игнорируете ее там и даже сохраняете результат ошибки в базе данных ? Когда вы делаете последнее, вам не нужно удивляться, если ваша база данных непоследовательна, и при попытке получить данные из базы данных возникают другие ошибки. И вы никогда не найдете код, который является реальной причиной ошибки.