在現在的web項目中很多情況下要涉及到同時操作多個數據庫 ，所以跨數據庫的事務或是跨系統的數據庫操作的事務就要求的越來越多了，我們知道在session bean中的一個方法內對多個數據庫的操作通過拋出系統異常可以讓ejb容器來維護跨庫的事務（分佈式事務），實際上它的底層也是依賴容器實現的jta來做的。
一個jta事務涉及到一個事務管理器和一個或者多個資源管理器，其中事務管理器相當於一箇中間件，它因該有實現jta的容器來提供，這也是在普通的jdbc事務中沒有的，而資源管理器就是數據庫，數據庫與事務管理器之間通過XA 接口規範，使用兩階段提交來完成一個全局事務（即分佈式事務）。大多數商用數據庫都提供了XA接口函數。
在第一階段，中間件請求所有相關數據庫準備提交（預提交）各自的事務分支，以確認是否所有相關數據庫都可以提交各自的事務分支。當某一數據庫收到預提交後，如果可以提交屬於自己的事務分支，則將自己在該事務分支中所做的操作固定記錄下來，並給中間件一個同意提交的應答，此時數據庫將不能再在該事務分支中加入任何操作，但此時數據庫並沒有真正提交該事務，數據庫對共享資源的操作還未釋放（處於上鎖狀態）。如果由於某種原因數據庫無法提交屬於自己的事務分支，它將回滾自己的所有操作，釋放對共享資源上的鎖，並返回給中間件失敗應答。
在第二階段，中間件審查所有數據庫返回的預提交結果，如所有數據庫都可以提交，中間件將要求所有數據庫做正式提交，這樣該全局事務被提交。而如果有任一數據庫預提交返回失敗，中間件將要求所有其它數據庫回滾其操作，這樣該全局事務被回滾。
以一個全局事務爲例，應用程序首先通知事務管理器（即中間件）開始一個全局事務，中間件通過XA接口函數通知數據庫開始事務，然後應用程序可以對數據庫管理的資源進行操作，數據庫系統記錄事務對本地資源的所有操作。操作完成後中間件通過XA接口函數通知數據庫操作完成。中間件負責記錄應用程序操作過哪些數據庫（事務分支）。應用程序根據情況通知中間件提交該全局事務，中間件會通過XA接口函數要求各個數據庫做預提交，所有數據庫返回成功後要求各個數據庫做正式提交，此時一筆全局事務結束。
XA規範對應用來說，最大好處在於事務的完整性由中間件和數據庫通過XA接口控制，應用程序只需要關注與數據庫的應用邏輯的處理，而無需過多關心事務的完整性，應用設計開發會簡化很多。具體來說，如果沒有中間件，應用系統需要在程序內部直接通知數據庫開始、結束和提交事務，當出現異常情況時必須由專門的程序對數據庫進行反向操作才能完成回滾。如果是有很多事務分支的全局事務，回滾時情況將變得異常複雜。而使用XA接口，則全局事務的提交是由交易中間件控制，應用程序只需通知交易中間件提交或回滾事務，就可以控制整個事務（可能涉及多個異地的數據庫）的全部提交或回滾，應用程序完全不用考慮衝正邏輯。
我們實際使用的時候一般是在服務器的配置文件中配置一個xa連接的數據源，注意在這裏要用xa連接的數據源，然後利用jta的實行來保證跨數據庫的事務，也可以用ejb的容器來維持。XA 連接與非 XA 連接是不同的，但在jboss中,如果在普通的配置文件中配置多個local-tx-datasource數據源，也可以做到跨庫的事務，但這時系統會給與警告，說明採用這種數據源連接有可能事務會失敗，
WARN [TxConnectionManager$LocalXAResource] Prepare called on a local tx. Use of local transactions on a jta transaction with more than one branch may result in inconsistent data in some cases of failure.
我們應該在mssql-xa-ds.xml文件中配置xa-datasource，則可以消除這種情況。至於如何直接使用jta的實現類來完成事務，也就是調用UserTransaction.begin()、 UserTransaction.commit() 和 serTransaction.rollback() 等方法還有在看看資料，其中對於UserTransaction的得到我有點疑問，它怎麼是通過jndi來得到的了？
InitialContext ctx = new InitialContext();
Object txObj = ctx.lookup("java:comp/UserTransaction");
UserTransaction utx = (UserTransaction) txObj;
太晚了，要睡了，明天還要上班，這些問題明晚在解決吧！
