处理 NHibernate 事务错误

Question

我们的应用程序（使用 NHibernate 和 ASP.NET MVC）在进行压力测试时会引发大量 NHibernate 事务错误。主要类型有：

1. 事务未连接，或已断开连接
2. 行被另一个事务更新或删除（或未保存值映射不正确）
3. 事务（进程 ID 177）在锁资源上与另一个进程发生死锁，并被选为死锁受害者。重新运行事务。

有人可以帮我找出异常 1 的原因吗？ 我知道我必须处理代码中的其他异常。有人可以向我指出可以帮助我有效处理这些错误的资源吗？

问：我们如何管理会话和交易？

答：我们正在使用 Autofac。对于每个服务器请求，我们创建一个新的请求容器，其中的会话位于容器生命周期范围内。激活会话后我们就开始交易。当请求完成时，我们提交事务。在某些情况下，交易可能会很大。为了简化，每个服务器请求都包含在一个事务中。

Answer 1

看看这个线程：
http://n2cms.codeplex.com/Thread/View.aspx?ThreadId=85016 基本上它

所说的导致此异常的可能原因是：

2010-02-17 21:01:41,204 1 警告
NHibernate.Util.ADOExceptionReporter -
System.Data.SqlClient.SqlException：
数据库的事务日志
“数据库名称”已满。找出来
为什么日志中的空间不能重用，
请参阅 log_reuse_wait_desc 列
系统数据库

由于事务日志的大小与事务期间完成的工作量成正比，因此也许您应该考虑将事务边界跨命令处理程序“处理”事务写入部分的命令。然后，您可以使用会话 #X 加载您想要改变的状态，改变它并提交它，所有这些都作为 #X 中的一个工作单元。

至于读取方面，您可能会拥有另一个读取数据的 ISession#Y；这个 ISession 可用于在 RepeatableRead 或类似 Futures 功能的东西中批量读取，并且可以简单地从缓存中读取（尽管它确实是一个拐杖）。这样做可能会帮助您从并非如此的“错误”中恢复过来。活锁、死锁和受害者事务。

每个请求使用事务的问题是，您的 ISession 在您工作时获取大量簿记数据，所有这些数据都是事务的一部分。因此，数据库将数据（角色、列、表等）标记为参与事务，导致等待图跨越“实体”（在数据库意义上，而不是 DDD 意义上），而这些实体实际上并不是事务的一部分您的应用程序所采取的命令的事务边界。

根据记录（其他人在谷歌上搜索此内容），Fabio post 处理数据层的异常。引用他的一些代码；

public class MsSqlExceptionConverterExample : ISQLExceptionConverter
{
  public Exception Convert(AdoExceptionContextInfo exInfo)
  {
      var sqle = ADOExceptionHelper.ExtractDbException(exInfo.SqlException) as SqlException;
      if(sqle != null)
      {
          switch (sqle.Number)
          {
              case 547:
                  return new ConstraintViolationException(exInfo.Message,
                      sqle.InnerException, exInfo.Sql, null);
              case 208:
                  return new SQLGrammarException(exInfo.Message,
                      sqle.InnerException, exInfo.Sql);
              case 3960:
                  return new StaleObjectStateException(exInfo.EntityName, exInfo.EntityId);
          }
      }
      return SQLStateConverter.HandledNonSpecificException(exInfo.SqlException,
          exInfo.Message, exInfo.Sql);
  }
}

• 547 是约束冲突的异常编号。
• 208 是 SQL 中无效对象名称的异常编号。
• 3960 是由于更新冲突而中止的快照隔离事务的异常编号。

因此，如果您遇到了像您所描述的那样的并发问题；请记住，它们将使您的 ISession 无效，并且您必须像上面那样处理它们。

您可能正在寻找的部分内容是 CQRS，其中您有单独的读取端和写入端。这可能会有所帮助：http://abdullin.com/cqrs/，http://cqrsinfo.com。

总结一下；您的问题可能与您处理交易的方式有关。另外，尝试运行 select log_wait_reuse_desc from sys.databases where name='MyDBName' 并查看它会提供什么。

Answer 2

这个线程有一个解释：
http://groups.google.com/group/nhusers/browse_thread/thread/7f5fb68a00829d13

简而言之，数据库可能会因为某些错误而自行回滚事务，这样当你稍后尝试回滚事务时，它已经回滚并处于僵尸状态。这往往会隐藏回滚的实际原因，因为您看到的只是 TransactionException，而不是首先实际触发回滚的异常。

我认为除了记录它并尝试找出导致潜在错误的原因之外，您对此无能为力。

Answer 3

我知道这篇文章是不久前发布的，假设您已修复它，但似乎您与 NHibernate ISession 存在线程共享问题，该问题不是线程安全的。基本上，一个线程正在启​​动一个事务，另一个线程正在尝试关闭它，从而导致各种混乱。