原文位址：http://blog.163.com/soli1988_blog/blog/static/176895272201212812416747/
總體來看，如果所有資料的修改僅依靠單個資料源就能完成，則這個事務就相當簡單了。然而，随着商業需求的日益增加，應用程式變得越來越複雜，經常需要通路多個資料庫，這些資料庫通常分布在不同的地方，這就是分布式事務。分布式事務修改的資料存儲在多個或多種類型的資料源中，這些資料源分布在多台機器上，甚至更複雜的情況。
設想有一個事務，要求資料變化發生在兩個分離的資料庫中，仍然要求所有的acid特性測試能夠滿足。基本的事務處理不能滿足要求，因為如果其中一個資料庫伺服器失敗，無法確定另外一個資料庫的資料還沒有送出并成為永久的。換句話說，無法協調發生在不同地方的多個事務處理就沒有辦法保證事務的原子性。
例如，運作在機器a上的一個元件是單個事務的組成部分之一，元件能夠利用機器b上的sql server執行資料庫事務。組成事務的另一元件用運作在機器c上的oracle伺服器執行資料庫事務。這三台機器運作着四塊不同的代碼，它們全都要參與到這個事務中。
即使通過com+隐藏分布式事務中的細節，也必要研究和了解分布式事務的“幕後”結構。請記住這些acid特性适用于所有類型的事務，不論事務涉及的資料庫是什麼類型或數量有多少。
使用ms dtc進行兩階段送出
讓我們再看一下上述分布式事務的例子。如果oracle伺服器停機了，如何保證事務的原子性。答案是使用兩階段送出(two-phase commit，2pc)和通過microsoft分布式事務協調器(ms dtc)協調。
msdtc是最先內建在sql server中，現在已成為com+必不可少的部分，通過在事務進行中加入其他的因子，ms dtc确認所有的過程完成并送出他們。
讓我們進一步研究ms dtc，了解其工作方式。為了能用兩階段送出協定進行協調，事務中的每個資料源必須裝有ms dtc。在這些安裝中，主要的協調器總是在事務的起源之處。這個主要的協調器稱為送出協調器，它負責確定事務的送出或終止。不管事務是成功地送出還
是復原，送出協調器都負責向客戶應用程式傳回一個報告。
在兩階段送出中第一階段是準備階段，每個伺服器執行它接收的指令，但所有應寫到磁盤的内容都被緩沖，如圖1 9 - 1所示。
一旦伺服器已執行了指令，就通知送出協調器關于事務的狀況，如圖1 9 - 2所示。
第二階段稱為送出階段。如果送出協調器接收到來自每個資料源的“準備送出”通知，就送出事務，如圖1 9 - 3。
然而，如果從某一受影響的資料源接收到失敗資訊，送出協調器将執行復原，并且通知客戶應用程式，見圖1 9 - 4。