https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.admin.doc/ids_admin_1050.htm
兩階段提交協議
兩階段提交協議提供了一個自動恢復機制以防系統或者媒體在事務的時候失敗。兩階段提交協議確保所有參與的數據庫接受然后執行相同的行為，無視本地或者網絡的失敗

如果任何一個數據庫服務器無法提交相關事務，則必須阻止參與事務的所有數據庫服務器執行其工作。

數據庫服務器在涉及到多臺數據庫服務的數據更改自動使用兩階段提交協議。舉個例子，假如你有三個數據庫服務器，叫australia,italy和france連接起來
如果你執行了如下的代碼

CONNECT TO stores_demo@italy
BEGIN WORK
  UPDATE stores_demo:manufact SET manu_code = 'SHM' WHERE manu_name = 'Shimara'
  INSERT INTO stores_demo@france:manufact VALUES ('SHM', 'Shimara', '30')
  INSERT INTO stores_demo@australia:manufact VALUES ('SHM', 'Shimara', '30')
COMMIT WORK

這種時候就要使用兩階段提交協議
每一個全局的事務都由一個協調者和多個參與者，定義如下：

協調者指導全局事務的結果。它決定提交這個事務或者拒絕這個事務
兩階段提交協議總是把協調的角色分配給當前的數據庫服務器。在單個事務中，協調器的角色不能改變。在上面的例子中，協調者的角色是italy。如果把上面的代碼第一行改變為

CONNECT TO stores_demo@france

每一個參與者指導一個事務分支的執行，這是與全局事務相關的一部分。當
應用程序使用多個進程來處理全局事務
多個遠程應用程序用于同一個全局事務
全局事務包括數個事務分支。

在使用兩階段提交協議時，參與者是Italy和australia， 協調員數據庫服務器italy也作為參與者，因為它也在進行更新。

兩階段提交協議依賴于兩種通信，消息和邏輯記錄

消息在協調員和每個參與者之間通過。來自協調器的消息包括事務標識號和指令(準備提交，提交或者回滾).來自每個參與者的消息包括事務的狀態和所采取行為的報告(可以調教，不能提交或者回滾)。

事物的邏輯日志記錄保存在磁盤或磁帶上，即使數據庫服務器發生故障，也可以保證數據的完整性和一致性。

在兩階段提交協議中，協調者把所有的數據修改指令發送給參與者，然后協調者啟動兩階段提交協議。兩階段提交協議有兩個部分，預提交階段和后決定階段。

預提交階段，在預提交階段，協調者先指導每一個參與數據服務器準備提交事務。參與者告訴協調者是否它們可以commit事務。協調者基于每一個參與者的回應，決定提交這個事務或者回滾這個事務。如果每一個參與者都返回可行，協調者就決定執行。如果有任何一個參與者沒有準備好提交這個事務，協調者就決定終止這個事務。

后決定階段，在后決定階段，協調者把是提交還是回滾的記錄存到日志中，然后把信息發送給參與者確認事務已經提交。如果協調者決定后滾，參與者回滾事務，但是不向協調者發送ack。然后協調者發送信息決定提交這個事務，它等待每一個參與者發送ack，然后終止這個事務。

兩階段提交協議被設計用來處理系統或者媒體的失敗時保持所有參與者數據庫數據的完整性。如果有失敗產生，兩階段提交協議執行一個自動恢復。可以恢復以下的情況:
1.協調者系統失敗
2.參與者系統失敗
3.網絡失敗
4.管理者關閉協調者線程
5.管理者關閉參與者線程
管理者在自動恢復中的唯一工作是在系統或者網絡失敗的時候把協調者和參與者重新上線。
如果協調者線程失敗，每一個數據庫服務器的參與者必須決定是否在提交或回滾事務之后自動恢復。
在兩階段提交協議完成之前，有一個參與者線程預提交的部分工作終止了，就發生參與者恢復。參與者恢復的目標是根據協調者的指定完成提交。

回滾以以下方式處理。 當協調者確定事務必須回滾時，它會向所有參與者發送消息以回滾其工作。 協調者不等待對此消息的確認，而是繼續關閉事務并將其從共享內存中刪除。 如果參與者嘗試確定此事務的狀態，也就是說，確定事務是提交還是回滾（例如，在參與者恢復期間） - 在共享內存中找不到任何事務狀態。 參與者必須將此解釋為意味著事務被回滾。