Spring的分散式交易，使用或不用XA – 2

原文連結：

http://www.javaworld.com/javaworld/jw-01-2009/jw-01-spring-transactions.html?page=2

    1. 開始訊息事務
    2. 接收訊息
    3. 開始資料庫事務
    4. 更新資料庫, 失敗!
    5. 復原資料庫事務
    6. 復原訊息事務

如上的例子中, 訊息在最後的復原動作發生後傳回中介軟體，並在某個時刻被另外一個事務所接收。這通常是好事，否則你可能無法記錄失敗。(自動重試和異常處理的機制不在本文討論範圍)

上面兩個程式流最重要的特徵在於它們是原子性的, 形成單個邏輯事務，要麼全部成功，要麼全部失敗。

但究竟怎麼保證程式流和上面的兩種情況類似呢？必須使用到一些事務資源之間的同步，這樣如果一個提交，那麼全部提交，反之亦然。由於包含了多個事務資源，所以事務是分布式的，如果不採取同步措施，那麼一定不會是原子性的。分散式交易技術和概念上的困難均在於資源之間的同步(或缺少同步)。

下面討論的前面的3個模式是基於XA協議的。由於這些模式被廣泛討論過，我不會涉及太多的細節。熟悉XA模式的讀者可以直接跳到共用事務資源模式（Shared Transaction Resource pattern）。
使用兩階段交易認可方式的完整XA（Full XA with 2PC）

如果需要‘防彈層級’的保護比如事務需要從服務中斷中恢複, 甚至包括伺服器崩潰，那麼完整XA(Full XA)是你唯一的選擇。在這個例子中用來同步事務的共用資源是一個特殊的交易管理員，用來協調使用XA協議的進程的資訊。在Java中，從開發人員角度來看，協議是通過JTA UserTransaction來暴露的。

做為一個系統介面，XA的能力大部分開發人員尚不瞭解。他們需要知道有這麼一個XA，能做什麼，有什麼代價，如何使用事務資源。代價來自於兩階段交易認可協議two-phase commit (2PC) ，交易管理員使用該協議來確保所有的資源在事務結束前對處理結果達成一致。

如果是Spring應用，會使用Spring JtaTransactionManager和Spring聲明式交易管理(declarative transaction management) 來隱藏底層同步的技術細節。使用XA或不用XA之間的區別僅在於配置工廠資源：資料來源（DataSource）執行個體，和應用程式交易管理員。這篇文檔包含一個示範應用（atomikos-db項目）示範了這個配置。資料來源（DataSource）執行個體和交易管理員是僅有的XA-或JTA-相關元素。

想瞭解示範應用是如何工作的，可以運行com.springsource.open.db下面的單元測試用例。MultipleDataSourceTests類插入資料到兩個資料來源中，然後使用Spring整合支援功能復原這個事務，如列表1中所示：

by iefreer