System.Transactions.TransactionInDoubtException的原因

Question

我有两个在Server数据库中读取和生成数据的作业。每隔一段时间，工作就会因System.Transactions.TransactionInDoubtException.而崩溃确切的堆栈跟踪是：

 Unhandled Exception: System.Transactions.TransactionInDoubtException: The transaction is in doubt. ---> System.Data.SqlClient.SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.ComponentModel.Win32Exception: The wait operation timed out. Exitcode: -532462766
    --- End of inner exception stack trace ---
    at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
    at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
    at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
    at System.Data.SqlClient.TdsParserStateObject.TryReadNetworkPacket()
    at System.Data.SqlClient.TdsParserStateObject.TryPrepareBuffer()
    at System.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync()
    at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
    at System.Data.SqlClient.TdsParserStateObject.TryReadByte(Byte& value)
    at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)

我在googled上搜索了一些关于MSDTC的内容，但我认为这不是问题，因为事务应该是本地的，因为作业只在单个数据库上工作。以下查询：

SELECT cntr_value AS NumOfDeadLocks
  FROM sys.dm_os_performance_counters
 WHERE object_name = 'SQLServer:Locks'
   AND counter_name = 'Number of Deadlocks/sec'
   AND instance_name = '_Total'

显示数据库中没有死锁，所以死锁不可能是原因。我在互联网上找不到任何其他资源来提供关于异常原因的准确信息。那么，有没有人知道原因是什么，或者如何找到这个错误的根源呢？

Answer 1

根据本文：http://msdn.microsoft.com/en-us/library/ms229978(v=vs.110).aspx，即使事务是本地的，如果您在同一事务范围内打开多个连接，则事务仍将升级到MSDTC。

导致将事务所有权转移到MSDTC的System.Transactions基础结构的升级发生在以下情况：.

• 事务中至少有两个支持单阶段通知的持久资源。例如，使用单个连接注册并不会导致事务升级。但是，每当您打开第二个连接到导致数据库登记的数据库时，System.Transactions基础结构就会检测到它是事务中的第二个持久资源，并将其升级为MSDTC事务。

注意:我读过一些文章，其中指出这只适用于SQL 2005，并且SQL 2008+在MSDTC推广方面更聪明。这些声明表明，只有当多个连接同时打开时，才会提升到MSDTC。请参阅：TransactionScope automatically escalating to MSDTC on some machines?

另外，您的内部异常是Timeout (System.Data.SqlClient.SqlException: Timeout过期)，而不是Deadlock。虽然两者都与阻塞有关，但它们并不是一回事。当阻塞导致应用程序停止等待被另一个连接阻塞的资源时，会发生timeout，以便当前语句能够获得该资源的锁。当两个不同的连接在竞争相同的资源时发生deadlock，而且除非其中一个连接被终止，否则它们将永远无法完成阻塞(这就是为什么死锁错误消息说“事务.已被选择为死锁受害者”)。由于您的错误是超时，这解释了为什么死锁查询返回0计数。

来自MSDN的System.Transactions.TransactionInDoubtException (http://msdn.microsoft.com/en-us/library/system.transactions.transactionindoubtexception(v=vs.110).aspx状态：

当对有疑问的事务尝试操作时，将引发此异常。当无法确定事务的状态时，事务将受到怀疑。具体来说，事务的最终结果，无论是提交的还是中止的，对于这个事务都是永远不知道的。 当尝试提交事务并将事务变为InDoubt时，也会引发此异常。

原因:在TransactionScope期间发生了一些事情，导致在事务结束时状态未知。

原因:可能有许多不同的原因，但如果不发布源代码，很难确定您的具体原因。

要检查的事情：

1. 如果使用SQL 2005，并且打开了多个连接，则事务将被提升为MSDTC事务。
2. 如果您使用的是SQL 2008+，并且同时打开了多个连接(即嵌套连接或多个ASYNC连接并行运行)，则事务将被提升为MSDTC事务。
3. 如果您的代码中有"try/catch{retry If timeout /死锁}“逻辑，那么当事务在System.Transactions.TransactionScope中时，这会导致问题，因为Server在超时或死锁发生时自动回滚事务。

Answer 2

我认为如果没有MSDTC，这种情况也会发生。我想我在一个根本不使用MSDTC的系统中发生了这种情况。我认为，如果您的DB连接在某个特定时刻失败，就会触发它。此时的情况必须是服务已经向DB发送了一个COMMIT，但是连接失败了，因此服务无法确定DB是否收到了COMMIT命令。

Answer 3

当我试图完成一个事务范围(其中包括对通过实体框架映射的数据库的调用)时，我曾经对这个“事务是有疑问的”。其中一个通过实体框架调用的是存储过程，其中包括一个带有命令"with(tablock, holdlock)“的select语句。似乎对我有效的解决方案是，对存储过程返回的结果调用Dispose() --即使存储过程刚刚说的是"Return 0”。这显然释放了资源。