Java事務的類型有三種：JDBC事務、JTA(Java Transaction API)事務、容器事務。 常見的容器事務如Spring事務，容器事務主要是J2EE應用服務器提供的，容器事務大多是基於JTA完成，這是一個基於JNDI的，相當複雜的API實現。所以本文暫不討論容器事務。本文主要介紹J2EE開發中兩個比較基本的事務：JDBC事務和JTA事務。
JDBC事務
JDBC的一切行為包括事務是基於一個Connection的，在JDBC中是通過Connection對象進行事務管理。在JDBC中，常用的和事務相關的方法是： setAutoCommit、commit、rollback等。
下面看一個簡單的JDBC事務代碼：
上面的代碼實現了一個簡單的轉賬功能，通過事務來控制轉賬操作，要麼都提交，要麼都回滾。
JDBC事務的優缺點
JDBC為使用Java進行數據庫的事務操作提供了最基本的支持。通過JDBC事務，我們可以將多個SQL語句放到同一個事務中，保證其ACID特性。JDBC事務的主要優點就是API比較簡單，可以實現最基本的事務操作，性能也相對較好。
但是，JDBC事務有一個侷限：一個 JDBC 事務不能跨越多個數據庫！！！所以，如果涉及到多數據庫的操作或者分佈式場景，JDBC事務就無能為力了。
JTA事務
為什麼需要JTA
通常，JDBC事務就可以解決數據的一致性等問題，鑑於他用法相對簡單，所以很多人關於Java中的事務只知道有JDBC事務，或者有人知道框架中的事務（比如Hibernate、Spring）等。但是，由於JDBC無法實現分佈式事務，而如今的分佈式場景越來越多，所以，JTA事務就應運而生。
如果，你在工作中沒有遇到JDBC事務無法解決的場景，那麼只能說你做的項目還都太小。拿電商網站來說，我們一般把一個電商網站橫向拆分成商品模塊、訂單模塊、購物車模塊、消息模塊、支付模塊等。然後我們把不同的模塊部署到不同的機器上，各個模塊之間通過遠程服務調用(RPC)等方式進行通信。以一個分佈式的系統對外提供服務。
一個支付流程就要和多個模塊進行交互，每個模塊都部署在不同的機器中，並且每個模塊操作的數據庫都不一致，這時候就無法使用JDBC來管理事務。我們看一段代碼：
上面的代碼是一個簡單的支付流程的操作，其中調用了五個服務，這五個服務都通過RPC的方式調用，請問使用JDBC如何保證事務一致性？我在方法中增加了@Transactional註解，但是由於採用調用了分佈式服務，該事務並不能達到ACID的效果。
JTA事務比JDBC事務更強大。一個JTA事務可以有多個參與者，而一個JDBC事務則被限定在一個單一的數據庫連接。下列任一個Java平臺的組件都可以參與到一個JTA事務中：JDBC連接、JDO PersistenceManager 對象、JMS 隊列、JMS 主題、企業JavaBeans（EJB）、一個用J2EE Connector Architecture 規範編譯的資源分配器。
JTA的定義
Java事務API（Java Transaction API，簡稱JTA ） 是一個Java企業版 的應用程序接口，在Java環境中，允許完成跨越多個XA資源的分佈式事務。
JTA和它的同胞Java事務服務(JTS；Java TransactionService)，為J2EE平臺提供了分佈式事務服務。不過JTA只是提供了一個接口，並沒有提供具體的實現，而是由j2ee服務器提供商 根據JTS規範提供的，常見的JTA實現有以下幾種：
1.J2EE容器所提供的JTA實現(JBoss)
2.獨立的JTA實現:如JOTM，Atomikos.這些實現可以應用在那些不使用J2EE應用服務器的環境裡用以提供分佈事事務保證。如Tomcat,Jetty以及普通的java應用。
JTA裡面提供了 java.transaction.UserTransaction ,裡面定義了下面幾個方法
- begin：開啟一個事務
- commit：提交當前事務
- rollback：回滾當前事務
- setRollbackOnly：把當前事務標記為回滾
- setTransactionTimeout：設置事務的事件，超過這個事件，就拋出異常，回滾事務
這裡，值得注意的是，不是使用了UserTransaction就能把普通的JDBC操作直接轉成JTA操作，JTA對DataSource、Connection和Resource 都是有要求的，只有符合XA規範，並且實現了XA規範的相關接口的類才能參與到JTA事務中來，關於XA規範，請看我的另外一篇文章中有相關介紹。這裡，提一句，目前主流的數據庫都支持XA規範。
要想使用用 JTA 事務，那麼就需要有一個實現 javax.sql.XADataSource 、 javax.sql.XAConnection 和 javax.sql.XAResource 接口的 JDBC 驅動程序。一個實現了這些接口的驅動程序將可以參與 JTA 事務。一個 XADataSource 對象就是一個 XAConnection 對象的工廠。XAConnection 是參與 JTA 事務的 JDBC 連接。
要使用JTA事務，必須使用XADataSource來產生數據庫連接，產生的連接為一個XA連接。
XA連接（javax.sql.XAConnection）和非XA（java.sql.Connection）連接的區別在於：XA可以參與JTA的事務，而且不支持自動提交。
上面的例子就是一個使用JTA事務的轉賬操作，該操作相對依賴於J2EE容器，並且需要通過JNDI的方式獲取UserTransaction和Connection。
標準的分佈式事務
一個分佈式事務（Distributed Transaction）包括一個事務管理器（transaction manager）和一個或多個資源管理器(resource manager)。一個資源管理器（resource manager）是任意類型的持久化數據存儲。事務管理器（transaction manager）承擔著所有事務參與單元者的相互通訊的責任。
看上面關於分佈式事務的介紹是不是和2PC中的事務管理比較像？的卻，2PC其實就是符合XA規範的事務管理器協調多個資源管理器的一種實現方式。 我之前有幾篇文章關於2PC和3PC的，那幾篇文章中介紹過分佈式事務中的事務管理器是如何協調多個事務的統一提交或回滾的，後面我還會有幾篇文章詳細的介紹一下和分佈式事務相關的內容，包括但不限於全局事務、DTP模型、柔性事務等。
JTA的優缺點
JTA的優點很明顯，就是提供了分佈式事務的解決方案，嚴格的ACID。但是，標準的JTA方式的事務管理在日常開發中並不常用，因為他有很多缺點:
- 實現複雜
通常情況下，JTA UserTransaction需要從JNDI獲取。這意味著，如果我們使用JTA，就需要同時使用JTA和JNDI。
- JTA本身就是個笨重的API
- 通常JTA只能在應用服務器環境下使用，因此使用JTA會限制代碼的複用性。
總結
Java事務的類型有三種：JDBC事務、JTA(Java Transaction API)事務、容器事務，其中JDBC的事務操作用法比較簡單，適合於處理同一個數據源的操作。JTA事務相對複雜，可以用於處理跨多個數據庫的事務，是分佈式事務的一種解決方案。
這裡還要簡單說一下，雖然JTA事務是Java提供的可用於分佈式事務的一套API，但是不同的J2EE平臺的實現都不一樣，並且都不是很方便使用，所以，一般在項目中不太使用這種較為負責的API。現在業內比較常用的分佈式事務解決方案主要有異步消息確保型、TCC、最大努力通知等
閱讀更多 戚小柒說IT 的文章
