1. 流程
1) Coordinator (協調者) 廣播 VOTE-REQ 給所有 Participant (參與者)
2) Coordinator 等待 Participant 的結果
3) Participant 回復 YES or NO 給 Coordinator
4) Coordinator 收集所有結果后, 廣播 COMMIT or ABORT 給所有 Participant
其中, 當 Participant 處於 狀態 3 與 狀態 4 之間的時候(已經發送 YES 並等待 Coordinator 的回復)稱之為不確定狀態, 這個狀態處於阻塞狀態
2. 超時協議
Participant 與 Coordinator 可能會處於無法通信的狀態, 這時候可以有不同的處理策略
1) Termination Protocol
在與協調者的通信恢復之前p始終保持阻塞。之后，協調者通知p對應的決定結果。協調者肯定支持這樣做，因為它沒有不確定區間。該terminaion protocol滿足AC5，因為如果所有的故障都修復了的話，p就能與協調者通信，然后就能達到決定狀態。
這種簡單的terminaion protocol缺點在於，p可能要經歷不必要的阻塞。比如，假設現在有兩個參與者p和q。協調者先給q發送了一個COMMIT或ABORT消息，但是在發送給p之前發生了故障。因此，盡管p是不確定的，但是q不是。如果p可以與q進行通信，那么它就可以從q那得知最終的決定結果。並不需要一直等待着協調者的恢復。
2) Cooperative Termination Protocol
參與者p如果在不確定區間超時，它會發送一個DECISION-REQ消息給所有其他進程，設為q，問下q是否知道決定結果或者能否單方面地做出決定。在這個場景中，p是initiator，q是responder。有如下三種情況：
1. q已經決定進行Commit(或Abort)：q簡單地發送一個COMMIT(或ABORT)消息給p，然后p進行相應動作
2. q還未進行投票：q可以單方面地決定進行Abort。然后它發送ABORT消息給p，p會因此決定進行ABORT
3. q已經投了Yes但是還未做決定：q也是處於不確定狀態，因此無法幫助p達成決定。
對於該協議來說，如果p可以同某個進程q通信並且上述1或2成立，那么p就可以不經阻塞地達成決定。另一方面，如果p通信的所有進程都是3成立，那么p就會被阻塞。那么p將會一直阻塞，直到故障修復的出現了某個進程q滿足條件1或2為止。
3. 故障
Coordinator 和 Participant 有可能會發生故障, 故障恢復后, 需要根據發生故障時的狀態來決定, 所以需要將各個狀態寫入 DT log
* 如果DT log包含一個start-2PC記錄，那么說明S就是協調者所在節點。如果它還有commit(或abort)記錄，那么說明在發生故障前協調者已經做出了決定。如果這兩種記錄(commit或abort)都沒有找到，那么協調者可以通過向DT log中插入一條abort記錄來單方面地決定進行Abort。這樣可以工作的關鍵在於，協調者是先將commit記錄寫入DT log，然后再發送COMMIT消息的(上面的第3點)。
* 如果DT log中沒有start-2PC記錄，那么S就是參與者節點。那么有如下三種可能：
* DT log中包含一個commit(或abort)記錄。那么說明在發生故障之前，參與者已經達成了決定。
* DT log中沒有yes記錄。那么要么是參與者是在投票前發生的故障，要么投的是No(但是在發生故障前還沒有完成abort記錄的寫入)。(這也是為何yes記錄必須要在發送YES消息前寫入日志的原因；參考上面的第2點。)因此，它可以單方面地通過向DT log中寫入一條abort記錄決定進行Abort。
* DT log中包含了yes記錄，但是沒有commit(或abort)記錄。那么說明參與者是在不確定區間內發生的故障。它可以通過使用terminaion protocol來達成決定。回想一下，yes記錄中包含了協調者名稱以及所有的參與者，這正是terminaion protocol所需要的。
整理自
http://duanple.blog.163.com/blog/static/70971767201311810939564
http://research.microsoft.com/en-us/people/philbe/chapter7.pdf