DTP/XA 規范及XA API調用研究
分布式事務(Distributed Transaction Processing/XA)規范是一個業界標準規范，它定義了分布式事務中各方角色和標準兩階段提交的協議規范(XA Protocol)，該規范為廣為業界所支持(CICS/TUXEDO/Enica，后來的OTS/JTS規范以及微軟的MTS的莫不源于此。
XA規范中關鍵角色簡述如下
AP: 客戶應用程序，負責連接TM,RM，使用RM的提供的API訪問和更改數據，聲明分布式事務的開始和結束階段點(Transaction Demarcation)。
TM: 事務管理器，負責管理、協調、準備和提交分布式事務，對AP的接口標準為TX接口, 并非所有的 TM 實現都遵循這個標準, 但是都會提供類似的接口函數.
RM: 資源管理器，在AP訪問數據時，關聯事務相關的數據修改，并根據TM的命令提交或回滾數據修改，通常為數據庫, IBM MQSeries實現了RM接口。
RM分為靜態和動態兩種,靜態RM需要TM明確調用xa_start/xa_end關聯事務與RM的聯系. 動態RM在數據發生更改時,會自動回調TM提供的ax_reg/ax_unreg函數,動態關聯到當前活動的分布式事務中.
XA API中定義的xa_****和ax_****函數。
ax_reg 向事務管理器注冊資源管理器。
ax_unreg 向事務管理器取消注冊資源管理器。
xa_close 終止應用程序對資源管理器的使用。
xa_commit 通知資源管理器提交事務分支。
xa_complete 測試異步 xa 操作是否完成。
xa_end 取消線程與事務分支的關聯。
xa_forget 允許資源管理器丟棄啟發完成的事務分支的信息。
xa_open 初始化資源管理器，供應用程序使用。
xa_prepare 請求資源管理器準備提交事務分支。
xa_recover 獲取資源管理器已準備或啟發完成的事務標識符 (XID) 列表。
xa_rollback 通知資源管理器回滾事務分支。
xa_start 啟動或恢復事務分支；將 XID 與資源管理器請求線程的未來工作關聯。
ax_ 例程可讓資源管理器調用事務管理器；所有事務管理器必須提供這些例程。在 DTP 環境中操作時，xa_ 例程由資源管理器提供，并由事務管理器調用。當應用程序調用事務管理器以啟動全局事務時，事務管理器可以使用 xa_ 接口通知事務分支的資源管理器。
分布式事務各個階段相關API調用如下：
1 AP 通知TM打開RM連接， AP-->TM tx_open()
TM 會在該函數中調用RM提供的xa_open函數，打開到RM的連接。
在TUXEDO SERVICE中，需要在tpsvrinit()函數中調用tpopen()函數完成這項工作。
2 AP 聲明事務開始 AP-->TM tx_begin()
在聲明后，該線程后續對RM的所有訪問和更新均屬于該事務。
對于static RM, TM 需要調用xa_start() 明確關聯事務和RM。
在TUXEDO SERVICE/CLIENT中，tpbegin()函數完成類似工作.
當TUXEDO SERVICE被調用時, 如果已經處于事務中, TUXEDO 會自動調用與SERVICE關聯的RM的xa_start()函數(只對于 static RM).
3 AP訪問RM，使用RM規定的API訪問，XA規范未作定義。
對于dynamic RM, 如果訪問時發生了數據更改,例如提交一個UPDATE SQL 語句, RM會自動回調TM的ax_reg函數關聯到當前事務.
4 AP聲明事務分支結束
在TUXEDO SERVICE調用完成后, 自動調用 RM 的xa_end()函數(對于static RM和未調用ax_unreg的dynamic RM)。
說明: 根據業務需要,上述2-4步驟會在不同的進程(TUXEDO SERVICE)中重復出現, 只要事務ID( Global XID )相同,這多個事務分支(Branch) 均被認為屬于同一個事務.
5 AP 要求提交或回滾事務(TM tx_commit/tx_rollback )
AP要求提交事務時, TM 需要檢查事務狀態, 確定事務并未標記為MARKED_ROLLBACK(只能回滾),否則會回滾并報告錯誤.
TUXEDO CLIENT/SERVICE 調用 tpcommit/tpabort 提交或回滾事務.
在TUXEDO中,由于實現的原因,所有xa_prepare/xa_commit/xa_rollback都是由單獨的TMS進程發起調用的, TUXEDO SERVICE 進程不會發起相關調用.
TUXEDO配置文件中,每個TUXEDO SERVICE GROUP可以關聯一個RM和多個TMS,每個GROUP內的SERVICE 進程和TMS進程啟動時都會使用相同的 XA OpenInfo String打開到RM的連接.
標準兩階段事務提交過程:
1 (準備)更改事務狀態為PREPARING, 依次調用事務關聯RM的xa_prepare(), 任意RM返回錯誤則進入回滾過程, RM都PREPARE完成事務狀態改變為PREPARED.
2 (提交)更改事務狀態為COMMITTING, 記錄事務日志到硬盤中, 依次調用RM的xa_commit方法,再更新事務日志, 更改事務狀態為COMMITTED.事務提交完成.
3 (回滾)更改事務狀態為ROLLING_BACK, 依次調用事務關聯RM的的xa_rollback,更改事務狀態為ROLLED_BACK
簡化一階段事務提交過程:
1 (提交)更改事務狀態為COMMITTING, 記錄事務日志到硬盤中, 調用RM的xa_commit(TMONEPHASE)方法,再更新事務日志, 更改事務狀態為COMMITTED.事務提交完成.
啟發式事務提交和回滾:
部分RM支持啟發式提交或回滾, xa_commit/xa_rollback 返回時,可能會返回XA_HEUR***的值, 表明RM執行了啟發式優化.
此時TM需要后續調用RM的xa_forget(), 讓RM徹底釋放該事務相關的資源.
目前JSRB(Java Service Request Broker)已經部分實現上述TM的功能, 項目繼續進展中...: http://jsrb.sourceforge.net
參考資料：
Distributed Transaction Processing_ The XA Specification
IBM WebSphere 開發者技術期刊: 在中間件環境中配置和使用 XA
http://www.ibm.com/developerworks/cn/websphere/techjournal/0704_sood/0704_sood.html
XA接口的一階段提交與兩階段提交有何區別？
http://www-1.ibm.com/support/docview.wss?uid=csc148256d65004dc82448256d65004276f0