| 分佈式事務必須知足傳統事務的特性，即原子性，一致性，分離性和持久性。可是分佈式事務處理過程當中，某些場地(Server)可能發生故障，或 者因爲網絡發生故障而沒法訪問到某些場地。爲了防止分佈式系統部分失敗時產生數據的不一致性。在分佈式事務的控制中採用了兩階段提交協議（Two- Phase Commit Protocol）。即事務的提交分爲兩個階段：
預提交階段(Pre-Commit Phase)
決策後階段（Post-Decision Phase）
兩階段提交用來協調參與一個更新中的多個服務器的活動，以防止分佈式系統部分失敗時產生數據的不一致性。例如，若是一個更新操做要求位於三個不一樣結點上的記錄被改變，且其中只要有一個結點失敗，另外兩個結點必須檢測到這個失敗並取消它們所作的改變。
爲了支持兩階段提交，一個分佈式更新事務中涉及到的服務器必須可以相互通訊。通常來講一個服務器會被指定爲"控制"或"提交"服務器並監控來自其它服務器的信息。
在分佈式更新期間，各服務器首先標誌它們已經完成（但未提交）指定給它們的分佈式事務的那一部分，並準備提交（以使它們的更新部分紅爲永久性的）。這是 兩階段提交的第一階段。若是有一結點不能響應，那麼控制服務器要指示其它結點撤消分佈式事務的各個部分的影響。若是全部結點都回答準備好提交，控制服務器 則指示它們提交併等待它們的響應。等待確認信息階段是第二階段。在接收到能夠提交指示後，每一個服務器提交分佈式事務中屬於本身的那一部分，並給控制服務器 發回提交完成信息。
在一個分佈式事務中，必須有一個場地的Server做爲協調者(coordinator)，它能向 其它場地的Server發出請求，並對它們的回答做出響應，由它來控制一個分佈式事務的提交或撤消。該分佈式事務中涉及到的其它場地的Server稱爲參 與者（Participant）。 數據庫 事務兩階段提交的過程以下： ● 兩階段提交在應用程序向協調者發出一個提交命令時被啓動。這時提交進入第一階段，即預提交階段。在這一階段中： (1) 協調者準備局部（即在本地）提交併在日誌中寫入"預提交"日誌項，幷包含有該事務的全部參與者的名字。 (2) 協調者詢問參與者可否提交該事務。一個參與者可能因爲多種緣由不能提交。例如，該Server提供的約束條件（Constraints）的延遲檢查不符合 限制條件時，不能提交；參與者自己的Server進程或硬件發生故障，不能提交；或者協調者訪問不到某參與者（網絡故障），這時協調者都認爲是收到了一個 否認的回答。 (3) 若是參與者可以提交，則在其自己的日誌中寫入"準備提交"日誌項，該日誌項當即寫入硬盤，而後給協調者發回一?quot;已準備好提交"的回答。 (4) 協調者等待全部參與者的回答，若是有參與者發回否認的回答，則協調者撤消該事務並給全部參與者發出一個"撤消該事務"的消息，結束該分佈式事務，撤消該事務的全部影響。 ● 若是全部的參與者都送回"已準備好提交"的消息，則該事務的提交進入第二階段，即決策後提交階段。在這一階段中： (1) 協調者在日誌中寫入"提交"日誌項，並當即寫入硬盤。 (2) 協調者向參與者發出"提交該事務"的命令。各參與者接到該命令後，在各自的日誌中寫入"提交"日誌項，並當即寫入硬盤。而後送回"已提交"的消息，釋放該事務佔用的資源。 (3) 當全部的參與者都送回"已提交"的消息後，協調者在日誌中寫入"事務提交完成"日誌項，釋放協調者佔用的資源 。這樣，完成了該分佈式事務的提交。 |