Reason for System.Transactions.TransactionInDoubtException提到交易被提升为MSDTC的三个原因。前两个是众所周知的，但第三个原因如下：MSDTC促销的原因
3.如果您有“尝试/ catch（重试超时/死锁重试）”逻辑，您的代码中运行，那么这可以当事务处于System.Transactions.TransactionScope中时会导致问题，因为SQL Server在超时或死锁发生时自动回滚事务的方式。
我在其中一个服务器应用程序处于严重负载（SQL 2012）时看到此行为。我试过Google广泛搜索，但我没有找到更多信息。有没有人有任何关于此主题的其他信息？
感谢，
拉里
我想我们真的结束了与两个引用计数一个连接上运行一个事务。我同意的是虚假的，应该重新编码。
这不是一个问题本身。
然而，倍当内部事务回滚和重试
的问题是，一个回退回滚一切。你不能单独重试“内在”工作。 （是的，这将是超级有用的，但SQL Server不支持它。）
这看起来会激发内部事务的第二个连接。这将导致MSDTC被调用来尝试协调。
这是没有实际意义的，因为此时“外部”工作已被破坏。
这个问题没有很好的解决方案。最好的策略很可能只有一个交易，并且将内部工作作为一个单元重试外部和。重试总是必须重试整个事务。如果需要，可以使用事务“ref counting”，但不能用它来回滚。
SQL Server的一个特别令人讨厌的功能是无法预测任何特定错误是否会导致事务回滚。因此，它是从不处理SQL Server错误的最简洁的方式，并且总是声明事务丢失。 （SQL Server没有这样做的技术原因，这只是一个愚蠢的设计选择。）
你遇到了什么症状？只是例外？为什么这个例外是一个问题？你的重试逻辑应该吞下它。 – usr
我们有嵌套交易。内层有重试循环。在严重负载下，重试循环超时，回滚，升级到MSDTC，重试。大多数时候它成功了，但有时我也会遇到MSDTC故障。 MSDTC故障可能导致其中一个事务回滚，而另一个则不会。 – LESchwartz
您是否知道SQL Server不支持System.Transactions支持嵌套事务？ – usr