1、分布式事務相關概念
分布式事務處理（Distributed Transaction Processing，DTP）是指一個事務可能涉及多個數據庫操作，分布式事務處理的關鍵是必須有一種方法可以知道事務在任何地方所做的所有動作，提交或回滾事務的決定必須產生統一的結果（全部提交或全部回滾）。
X/Open 組織（即現在的 Open Group ）定義了分布式事務處理模型。 X/Open DTP 模型（ 1994 ）包括應用程序（ AP ）、事務管理器（ TM ）、資源管理器（ RM ）、通信資源管理器（ CRM ）四部分。一般，常見的事務管理器（ TM ）是交易中間件，常見的資源管理器（ RM ）是數據庫，常見的通信資源管理器（ CRM ）是消息中間件。
通常把一個數據庫內部的事務處理，如對多個表的操作，作為本地事務看待。數據庫的事務處理對象是本地事務，而分布式事務處理的對象是全局事務。
所謂全局事務，是指分布式事務處理環境中，多個數據庫可能需要共同完成一個工作，這個工作即是一個全局事務，例如，一個事務中可能更新幾個不同的數據庫。對
數據庫的操作發生在系統的各處但必須全部被提交或回滾。此時一個數據庫對自己內部所做操作的提交不僅依賴本身操作是否成功，還要依賴與全局事務相關的其它
數據庫的操作是否成功，如果任一數據庫的任一操作失敗，則參與此事務的所有數據庫所做的所有操作都必須回滾。
一般情況下，某一數據庫無法知道其它數據庫在做什么，因此，在一個 DTP 環境中，交易中間件是必需的，由它通知和協調相關數據庫的提交或回滾。而一個數據庫只將其自己所做的操作（可恢復）影射到全局事務中。
XA 就是 X/Open DTP 定義的交易中間件與數據庫之間的接口規范（即接口函數），交易中間件用它來通知數據庫事務的開始、結束以及提交、回滾等。 XA 接口函數由數據庫廠商提供。
XA 與兩階段提交協議
通常情況下，交易中間件與數據庫通過 XA 接口規范，使用兩階段提交來完成一個全局事務， XA 規范的基礎是兩階段提交協議。
在第一階段，交易中間件請求所有相關數據庫準備提交（預提交）各自的事務分支，以確認是否所有相關數據庫都可以提交各自的事務分支。當某一數據庫收到預
提交后，如果可以提交屬于自己的事務分支，則將自己在該事務分支中所做的操作固定記錄下來，并給交易中間件一個同意提交的應答，此時數據庫將不能再在該事
務分支中加入任何操作，但此時數據庫并沒有真正提交該事務，數據庫對共享資源的操作還未釋放（處于上鎖狀態）。如果由于某種原因數據庫無法提交屬于自己的
事務分支，它將回滾自己的所有操作，釋放對共享資源上的鎖，并返回給交易中間件失敗應答。在第二階段，交易中間件審查所有數據庫返回的預提交結果，如所有數據庫都可以提交，交易中間件將要求所有數據庫做正式提交，這樣該全局事務被提交。而如果有任一數據庫預提交返回失敗，交易中間件將要求所有其它數據庫回滾其操作，這樣該全局事務被回滾。
以一個全局事務為例， AP 首先通知交易中間件開始一個全局事務，交易中間件通過 XA 接口函數通知數據庫開始事務，然后 AP 可以對數據庫管理的資源進行操作，數據庫系統記錄事務對本地資源的所有操作。操作完成后交易中間件通過 XA 接口函數通知數據庫操作完成。交易中間件負責記錄 AP 操作過哪些數據庫（事務分支）。 AP 根據情況通知交易中間件提交該全局事務，交易中間件會通過 XA 接口函數要求各個數據庫做預提交，所有數據庫返回成功后要求各個數據庫做正式提交，此時一筆全局事務結束。
XA 規范對應用來說，最大好處在于事務的完整性由交易中間件和數據庫通過 XA 接口控制， AP 只需要關注與數據庫的應用邏輯的處理，而無需過多關心事務的完整性，應用設計開發會簡化很多。
具體來說，如果沒有交易中間件，應用系統需要在程序內部直接通知數據庫開始、結束和提交事務，當出現異常情況時必須由專門的程序對數據庫進行反向操作才能完成回滾。如果是有很多事務分支的全局事務，回滾時情況將變得異常復雜。而使用 XA 接口，則全局事務的提交是由交易中間件控制，應用程序只需通知交易中間件提交或回滾事務，就可以控制整個事務（可能涉及多個異地的數據庫）的全部提交或回滾，應用程序完全不用考慮沖正邏輯。
在一個涉及多個數據庫的全局事務中，為保證全局事務的完整性，由交易中間件控制數據庫做兩階段提交是必要的。但典型的兩階段提交，對數據庫來說事務從開
始到結束（提交或回滾）時間相對較長，在事務處理期間數據庫使用的資源（如邏輯日志、各種鎖），直到事務結束時才會釋放。因此，使用典型的兩階段提交相對
來說會占用更多的資源，在網絡條件不是很好，如低速網、網絡顛簸頻繁，情況會更為嚴重。
當一個全局事務只涉及一個數據庫時，有一種優化方式，即一階段提交。當 AP 通知交易中間件提交事務時，交易中間件直接要求數據庫提交事務，省去兩階段提交中的第一階段，可以縮短處理一個事務的時間，以提高事務處理的效率。作為兩階段提交的一種特例，與兩階段一樣，一階段提交也是標準的。
XA的要求
對于jms來說，需要配置支持XA的 connection factory.
對于db來說，需使用支持XA的JDBC driver.
兩階段提交(2 phase commit)
先說transaction的管理，如下圖。
transaction manager與不同的resource manager都有交互。
在phase1時，transaction manager向兩個resouce詢問是否可以準備提交。Resouce可回復ready,
not_ready或是read_only. 當兩個都ready時，則可以進入phase2
進行提交。任何一個回復not_ready則整個transaction 回滾。回復read_only的資源在phase2階段被排除在提交過程之外。
2.JTA
JTA(Java Transaction API) 為 J2EE 平臺提供了分布式事務服務。
要用 JTA 進行事務界定，應用程序要調用 javax.transaction.UserTransaction 接口中的方法。
讓我們來關注下面的話：
“用 JTA 界定事務，那么就需要有一個實現 javax.sql.XADataSource 、
javax.sql.XAConnection 和 javax.sql.XAResource 接口的 JDBC
驅動程序。一個實現了這些接口的驅動程序將可以參與 JTA 事務。一個 XADataSource 對象就是一個 XAConnection
對象的工廠。 XAConnection s 是參與 JTA 事務的 JDBC 連接。”
要使用JTA事務，必須使用XADataSource來產生數據庫連接，產生的連接為一個XA連接。
XA連接（javax.sql.XAConnection）和非XA（java.sql.Connection）連接的區別在于：XA可以參與JTA的事務，而且不支持自動提交。
Note:
Oracle, Sybase, DB2, SQL Server,MySQL(5.0以后InnoDB存儲引擎)等大型數據庫才支持XA, 支持分布事務。
3.OFBiz中實現的事務
OFBiz采用Apache Commons DBCP作為數據庫連接池技術，分布式事務是通過Apache Geronimo Transaction實現的。下面是部分實現類關系：
TransactionFactory和ConnectionFactory都可以自己實現并且在entityengine.xml中進行配置，OFBiz中默認配置的是GeronimoTransactionFactory和DBCPConnectionFactory。OFBiz中實現事務不需要顯示調用，在services.xml中的service進行配置，配置的項目有兩個require-new-transaction和use-transaction，是否起一個新的事務和是否啟用事務，默認是false和true。如果不是采用service，event為java實現，那么需要手動實現事務，通常如下：
try {
beganTransaction = TransactionUtil.begin(DEFAULT_TX_TIMEOUT);
//db operation
return "success";
} catch (Exception e) {
e.printStackTrace();
TransactionUtil.rollback(beganTransaction, e.getMessage(), e);
return "error";
} finally {
TransactionUtil.commit(beganTransaction);
}