因為事務需要實現ACID，即原子性、一致性、隔離性、持久性，所以需要采用一定的機制來保證，通常采用的是分階段提交的方式。
XA:XA協議，規定事務管理器和資源管理器接口，采用二階段提交協議。
一階段提交協議
一階段提交協議相對簡單，如下圖：
當然，前提是開啟了事務，然后在應用程序發出提交/回滾請求后，數據庫執行操作，而后將成功/失敗返回給應用程序，程序繼續執行。
一階段提交協議相對簡單，簡單帶來的優點就是，它不用再與其他的對象交互，節省了判斷步驟和時間，所以在性能上是在階段提交協議中對好的。
二階段提交協議
一階段提交協議有其優點，但缺點也很明顯：
- 數據庫確認執行事務的時間較長，出問題的可能性就隨之增大。
- 如果有多個數據源，一階段提交協議無法協調他們之間的關系。
所以在一階段協議的基礎上，有了二階段協議，二階段協議的好處是添加了一個管理者角色，如下：
很明顯，二階段協議通過將兩層變為三層，增加了中間的管理者角色，從而協調多個數據源之間的關系，二階段提交協議分為兩個階段。
第一階段
應用程序調用了事務管理器的提交方法，此后第一階段分為兩個步驟：
- 事務管理器通知參與該事務的各個資源管理器，通知他們開啟事務、執行SQL（暫不提交），並進入prepare狀態（該狀態下可執行commit / rollback）。
- 資源管理器接收到消息后開始准備階段，寫好事務日志並執行事務，但不提交，然后將是否就緒的消息返回給事務管理器（此時已經將事務的大部分事情做完，以后的內容耗時極小）。
第二階段
第二階段也分為兩個步驟：
- 事務管理器在接受各個消息后，開始分析，如果有任意其一失敗，則發送回滾命令，否則發送提交命令。
- 各個資源管理器接收到命令后，執行（耗時很少），並將提交消息返回給事務管理器。
事務管理器接受消息后，事務結束，應用程序繼續執行。
為什么要分兩步執行？
一是因為分兩步，就有了事務管理器統一管理的機會；二盡可能晚地提交事務，讓事務在提交前盡可能地完成所有能完成的工作，這樣，最后的提交階段將是耗時極短，耗時極短意味着操作失敗的可能性也就降低。
同時，二階段提交協議為了保證事務的一致性，不管是事務管理器還是各個資源管理器，每執行一步操作，都會記錄日志，為出現故障后的恢復准備依據。
二階段提交協議的存在的弊端是阻塞
因為事務管理器要收集各個資源管理器的響應消息，如果其中一個或多個一直不返回消息，則事務管理器一直等待，應用程序也被阻塞，甚至可能永久阻塞。