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