事務協調者(事務管理器)給每個參與者(資源管理器)發送Prepare消息，每個參與者要么直接返回失敗(如權限驗證失敗)，要么在本地執行事務，寫本地的redo和undo日志，但不提交，到達一種“萬事俱備，只欠東風”的狀態。

可以進一步將準備階段分為以下三個步驟：

1）協調者節點向所有參與者節點詢問是否可以執行提交操作(vote)，并開始等待各參與者節點的響應。

2）參與者節點執行詢問發起為止的所有事務操作，并將Undo信息和Redo信息寫入日志。（注意：若成功這里其實每個參與者已經執行了事務操作）

3）各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回一個”同意”消息；如果參與者節點的事務操作實際執行失敗，則它返回一個”中止”消息。

提交階段

如果協調者收到了參與者的失敗消息或者超時，直接給每個參與者發送回滾(Rollback)消息；否則，發送提交(Commit)消息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。(注意:必須在最后階段釋放鎖資源)

接下來分兩種情況分別討論提交階段的過程。

當協調者節點從所有參與者節點獲得的相應消息都為”同意”時:

1）協調者節點向所有參與者節點發出”正式提交(commit)”的請求。

2）參與者節點正式完成操作，并釋放在整個事務期間內占用的資源。

3）參與者節點向協調者節點發送”完成”消息。

4）協調者節點受到所有參與者節點反饋的”完成”消息后，完成事務。

如果任一參與者節點在第一階段返回的響應消息為”中止”，或者 協調者節點在第一階段的詢問超時之前無法獲取所有參與者節點的響應消息時：

1）協調者節點向所有參與者節點發出”回滾操作(rollback)”的請求。

2）參與者節點利用之前寫入的Undo信息執行回滾，并釋放在整個事務期間內占用的資源。

3）參與者節點向協調者節點發送”回滾完成”消息。

4）協調者節點受到所有參與者節點反饋的”回滾完成”消息后，取消事務。

不管最后結果如何，第二階段都會結束當前事務。

二階段提交看起來確實能夠提供原子性的操作，但是不幸的事，二階段提交還是有幾個缺點的：

1、同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。當參與者占有公共資源時，其他第三方節點訪問公共資源不得不處于阻塞狀態。

2、單點故障。由于協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那么所有的參與者還都處于鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者宕機導致的參與者處于阻塞狀態的問題）

3、數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求之后，發生了局部網絡異常或者在發送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之后就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。于是整個分布式系統便出現了數據部一致性的現象。

4、二階段無法解決的問題：協調者再發出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了。那么即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。

由于二階段提交存在著諸如同步阻塞、單點問題、腦裂等缺陷，所以，研究者們在二階段提交的基礎上做了改進，提出了三階段提交。

3PC

三階段提交（Three-phase commit），也叫三階段提交協議（Three-phase commit protocol），是二階段提交（2PC）的改進版本。

與兩階段提交不同的是，三階段提交有兩個改動點。