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

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

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

比如：

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

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

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

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

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

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

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

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

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

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

最新評論