本文實例講述了C#分布式事務的超時處理的方法。分享給大家供大家參考。具體分析如下：

事務是個很精妙的存在，我們在數據層、服務層、業務邏輯層等多處地方都會使用到。

在這里我只說下TransactionScope這個微軟推薦使用的隱式事務。它是從Framework 2.0開始引入的一個事務管理類，在使用隱式事務時，事務完成前 程序應調用TransactionScope的Complete()方法，將事務提交，然后利用Dispose()釋放事務對象。若執行期間出現錯誤，事務將自動回滾。

比如：

using (ransactionScope scope = new TransactionScope()){    //to do something    scope.Complete();}

在這里個人建議用using來創建，因為using實現了IDispose接口，它會隱式的調用TransactionScope對象的Dispose方法，即使發生異常時也是如此，能確保在事務結束或者異常的時候也能正確的釋放資源。其實我們反編譯一下，它的內部實現就是一個try...finally代碼塊，這樣也就不難理解using的作用了。

說主題，在某地市的某庫升級中，為避免程序運行中產生臟數據以及數據更新不一致導致的重復同步情況，在可能產生上述問題的考慮下，我用這個TransactionScope來對上述的操作進行事務處理。在本機的測試環境中，運行結果是正常的，當然這個運行正常的前提是數據量較小的情況下，我每次只對一條或者十幾條數據的不同表進行insert和update。然而部署到生產環境針對真實數據運行之后，發現這個事務總是回滾，一直無法正常提交。程序也就沒法正常跑起來。因為生產環境中的數據有60W左右，insert一次、update一次，最后再insert一條同步語句，前2個操作都是比較耗時的。我切換回測試環境調試了一下，逐行運行，發現當執行完第一個insert之后,執行第二個update時發生異常了。這個異常由TransactionScope拋出，異常提示是：事務已中止。這個錯誤，在數據量小的情況下不會發生，數據量大一些就出現了，這個是不是和事務處理的時間長短有關呢？因為我明顯感覺到在這次調試的時候，執行的時間比之前數據量只有一條的時候長了很多，至少花費1分鐘以上。于是google一下，驗證了我的想法。

TransactionScope有些重載函數是可以接受TimeSpan類型的值，這個就是事務的超時時間了。當事務實現隔離的時候，事務范圍內的資源將會被鎖定，如果一些事務長期占有資源，那將很容易造成死鎖，為了避免這個問題，TransactionScope事務會定義一個超時限制，這個超時默認值為60秒。如果事務超過此時間，即使沒有發生異常，也會自動中止。上面問題的原因算是找到了，知道了原因，那么也就很好解決了。我們可以在Web.Config 中配置:

<configuration> <system.transactions>  <defaultSettings timeout="00:05:00" /> </system.transactions></configuration>

或者在using的時候就定義好超時時間：

或者先初始化事物行為的附加信息，然后定義超時時間：

我這里定義的是5分鐘，其實整個過程處理起來也就第一次處理歷史數據需要1到2分鐘時間，以后每天只需處理幾十條數據，這個時間基本是秒級別的。

這里說明下， 超時時間如果設置為0時表示超時無限長。無限長的設置主要對調試有用，調試過程中可能要逐步通過代碼來隔離業務邏輯中的問題，并且在嘗試確定問題期間不希望所調試的事務超時。在所有其他情況下使用無限長的超時時一定要格外小心，因為它會覆蓋防止事務死鎖的保護。

希望本文所述對大家的C#程序設計有所幫助。