首先呢, TransactionScope 的基本知識可以參考這篇文章 All About TransactionScope. 這篇文章裡提到的東西在細節上可能不清楚, 但是在觀念上應該不陌生. 

最早開始使用 TransactionScope 的時候, 只是希望得到 ACID 的效果, 所以就用了非常簡單的寫法:

    using (var tx = new TransactionScope()) { ... }

後來在查一些 deadlock 狀況時, 透過 deadlock graph 看到那些在 DB 執行的指令都含有 serializable 的字樣. 那時候嚇了一跳, 這段程式是多重要阿, 居然需要這麼嚴謹. 結果從指令反查回程式後, 根本沒有下 serializable, 但是有包在 TransactionScope 裡. 用 Sql Server Profiler 看了一下並且到 MSDN 查看後, 終於相信了 serializable 是預設行為.

之後我的寫法就改成了:

    using (var tx = new TransactionScope(         TransactionScopeOption.RequiresNew,         new TransactionOptions {              IsolationLevel = IsolationLevel.ReadCommitted          })) { ... }

這個寫法最主要的就是指定 IsolationLevel.ReadCommitted, 降低 blocking 和 deadlock. 而 TransactionScope 可以接收 TransactionOptions 的建構子中, 最短的就是這使用兩個參數的建構子. 第一個參數需要的 TransactionScopeOption 當時沒有掌握到差異, 程式後來也沒發生問題, 所以就一直這樣寫. 

一直沒出現問題是因為沒有用到 nested TransactionScope. 使用 nested TransactionScope 時, TransactionScopeOption 就會有影響了. 可以看看 Misunderstanding about nested TransactionScope 這邊答案的部分, 很簡潔的描述了不同 TransactionScopeOption 的差異.

現在來描述一下造成這次錯誤的程式結構. Refund() 方法裡面分成幾個步驟 , 放在各自的方法裡執行. 而有些步驟比較獨立, 可以個別執行, 所以裡面本身有 TransactionScope. 除了這些步驟外, 中途也會有狀態的變動要寫到DB裡, 這部分交給一個 Repository 來負責, 而 Repository 也有 TransactionScope. Refund() 本身也需要是完整的執行, 所以也有一層 TransactionScope. 把這些方法拉平後, 流程大概長這個樣子:

Refund() {     using (var tx1) {         ... // 開始退款         using (var tx2) {             ... // 某步驟裡的 transaction                          if (needChange) {                 ... // 改變                 tx2.Complete()             }                     }         Repository.Save(...)         ...         tx1.Complete()     } }

遇到的第一個錯誤是: Timeout expired. 由於使用 TransactionScopeOption.RequiresNew, 所以 tx1 跟 tx2 是兩個不同的 transaction. 在 tx2 裡面要做的事情, 需要的資源已經被 tx1 鎖住了, 而 tx1 又要等 tx2 執行完才會釋放資源, 所以 tx2 就一直等到 timeout 了. 比較麻煩的地方是, 這個問題在正式環境上才出現, 測試環境卻沒事. 正式環境裡, web 跟 db 是兩台機器, 而測試環境裡, web 跟 db 放在同一台機器上; 換句話說就是 local transaction 和 distributed transaction 上的差異.

後來把 RequiresNew 改成 Required 來解決這個問題. tx2 在這裡是一個跟 tx1 相關的 transaction, 改變後用已經存在的 transaction. 這時候 tx1 跟 tx2 就屬於同一個 transaction, 資源也不會擋住了. 

遇到的第二個錯誤是 The operation is not valid for the state of the transaction. 錯誤發生在離開 tx2 後, 回到 tx1 後續的 DB 存取程式碼. 由於 tx2 現在的 transaction 跟 tx1 是共用的, 所以 tx2 執行完後, 如果沒有呼叫 Complete() 的話, 整個 transaction 的狀態會被視為有錯誤並且要 rollback 的. 我在 tx2 裡面, 把寫入 DB 的部分放在 if (needChange) 的判斷裡, 自以為能夠少做點不必要的事情, 沒想到 Complete() 變成一個必須要呼叫的事情. 稍微改寫後, 也就不會發生這個錯誤了.