Reason for System.Transactions.TransactionInDoubtException提到交易被提升为MSDTC的三个原因。前两个是众所周知的，但第三个原因如下：
3.如果你有＆＃34;尝试/捕捉{重试超时/死锁}＆＃34;在代码中运行的逻辑，当事务在System.Transactions.TransactionScope中时，这会导致问题，因为SQL Server在发生超时或死锁时会自动回滚事务。
我在我的一个服务器应用程序中遇到严重负载时会看到此行为（SQL 2012）。我已经广泛尝试过谷歌搜索，但我没有找到更多信息。有没有人提到有关这个主题的其他信息？
感谢，
拉里
答案 0 :(得分：0)
我想我们真的在一个连接上运行一个事务，引用计数为2。我同意的是假的，应该重新编码。
这本身不是问题。
但是，有时内部事务回滚并重试
问题是回滚会回滚所有内容。你不能孤立地重试“内在”的工作。 （是的，这将非常有用，但SQL Server不支持它。）
这样可以启动内部事务的第二个连接。这将导致调用MSDTC以尝试协调。
这没有实际意义，因为此时“外部”工作已被破坏。
这个问题没有很好的解决方案。最佳策略可能只有一个事务，并将外部和内部工作重试为一个单元。重试始终必须重试整个事务。如果需要，可以使用事务“ref counting”，但不能使用它进行回滚。
SQL Server的一个特别令人讨厌的功能是，任何特定错误是否导致事务回滚都是不可预测的。因此，它是永远不会处理SQL Server错误并且始终声明事务丢失的最简洁方法。 （没有技术原因SQL Server必须这样做。这只是一个愚蠢的设计选择。）