XA Datasource 1PC優化

我正在使用JBoss EAP 6.4（Java EE 6），我有一個問題與應用程序服務器處理XA數據源（通過EJB/JTA）的方式有關，如果2階段提交（2PC ）總是使用或者如果應用「優化」。XA Datasource 1PC優化

比方說，我有這樣的：

@Stateless 
@TransactionAttribute(TransactionAttributeType.REQUIRED) 
public class MyEjb { 
    @EJB 
    private MyFirstEjb first; 

    @EJB 
    private MySecondEjb second; 

    // Transactional processing 
    public void process() { 
     first.processJpaStuff(); 
     second.processJpaStuff(); 
    } 
}

假設：

MyFirstEjb做使用XA數據源JPA查詢1.
MySecondEjb做使用XA數據源2.

我正在使用XA數據源，因爲這些EJB可用於其他情況下2PC i （與其他數據源或JMS提供者一起）。

我現在想區分幾種情況：同一個應用程序服務器中

MyFirstEjb和MySecondEjb部署在同一個應用程序（EAR）
MyFirstEjb和MySecondEjb部署在獨立的應用程序（EAR）
0：
MyFirstEjb和MySecondEjb被不同的應用程序的服務器

而子情形內展開

一個）XA數據源1 = XA數據源2

B）XA數據源1！= XA數據源2（相同的數據庫）

C）XA數據源1！= XA數據源2（不同的數據庫）

我想b）和c）的管理方式是一樣的。有一個全局事務，每個數據源與XA事務管理器協作。 2PC被應用。

那麼情況1.a）和2.a）呢？既然兩者最終都使用相同的數據源，那麼我認爲有一些優化不需要全局2PC事務處理呢？如果是，是否有任何官方（JTA/JBoss/...）鏈接解釋這個？所有應用程序服務器/實現都是一樣的嗎？

感謝

來源

2017-03-13 Benjamin C

這取決於。

的JTA（事務協調器）一無所知EJB或應用程序。它只關心XAResources和關聯的事務分支。通常情況下，管理JPA用於實體bean的連接池的JCA將爲每個使用的數據源提供一個XAResource。 JTA在同一全局tx id下分配每個不同的分支限定符。

在事務終止期間，JTA準備好每個XAResource，並在此處優化開始。如果數據庫引擎檢測到它具有多個分支（connections/XAResources），那麼它可能會返回PREPARED第一個XAResource，但來自剩餘資源的READ_ONLY。假設tx只有一個PREPARED資源，其餘都是隻讀的，那麼它可以相應地優化終端的剩餘部分。見例如

http://narayana.io/docs/product/#two-phase-variants

https://docs.oracle.com/cd/B10501_01/java.920/a96654/xadistra.htm#1061004

注意的是，根據供應商，「數據庫引擎」和「數據庫」不完全是一回事。一些系統將在同一臺服務器上託管多個dbs，並允許優化跨越它們，而另一些系統可能將每個視爲單獨的事務引擎範圍，而不是優化這些情況。數據源也可能僅在用於連接的用戶標識/模式上有所不同，依賴於權限/模式名稱空間來隔離應用程序，而不需要爲此目的設置不同的數據庫。優化幾乎總是適用於這種情況。

在某些情況下，該應用程序使用相同的XADataSource，JCA的註冊只是一個與JTA XA資源，可能允許它使用更激進1PC優化來代替。

儘管連接可能會在本地和XA事務上下文之間切換，但JTA目前無法利用此優勢。由於資源僅在需求時才招募，系統在達到終止階段之前不知道有多少人將參與交易。 JTA規範組之前討論過允許配置，類似於tx超時的設置方式，這將允許應用程序在開始時指示tx預期爲單個資源，或者更一般地列出它預期包含的XAResource。該信息將允許JTA在適當的情況下以本地tx模式而不是XA模式驅動資源，從而消除了開始/結束/準備協議調用。它還將消除手動優化此類情況的需要，方法是在應用程序中爲同一數據庫部署XA和非XA數據源。目前它還不在路線圖上。

來源

2017-03-15 16:11:24 jbosstxnerd

哇...謝謝你對這個詳細的解釋和這些重要的鏈接！這是非常有趣的，並且使它更加清晰，即使這是一個複雜的主題。它確認優化是供應商特定的。非常感謝 –

1.MyFirstEjb和MySecondEjb在同一個應用程序部署（EAR）

當數據源是不同的，因爲你可能知道，如果驅動程序和底層數據源無法加入全局事務，或者如果驅動程序未配置爲加入全局事務，則會出現特定錯誤。

對於其他情況，除此之外，理想情況是處理兩個數據源的業務層，並且所有客戶端處理業務層（應該避免處理相同數據源的不同應用程序）。這可能會發生。

2。MyFirstEjb和MySecondEjb被部署在同一個應用程序服務器

如果部署在同一應用程序服務器上，但與的.ear客戶端訪問他們槽遠程接口不同內的單獨的應用程序（耳），因此每一個啓動一個完全不同的線程/事務（REQUIRES_NEW）。如果出現問題，客戶端將得到一個EJBException。從客戶角度來看，沒有全球交易。

3.MyFirstEjb和MySecondEjb被不同的應用服務器

如果EJB部署不同的應用服務器上的應用同樣中部署。他們通過一個遠程接口訪問，因此他們每個人都開始一個全新的交易。

來源

2017-03-13 17:32:21 Leonardo

感謝您接受這些補充說明。事實上，如果驅動程序未配置爲加入全局事務，您將得到一個XAException。但你不回答我關於優化的主要問題。我發現了一個有趣的帖子（[link]（http://integrationspot.blogspot.fr/2011/03/jta-transactions-local-and-global.html）），它表示「XA數據源可以支持兩階段提交協調，**以及本地事務**「+」應用程序服務器執行**「唯一資源優化」**並與RMLT中的資源管理器交互。「它的工作方式是？ –

還有這個答案[http://stackoverflow.com/questions/5130934/jta-datasources-without-transactions#answer-5452025](http://stackoverflow.com/questions/5130934/jta-datasources-without- transactions＃answer-5452025）這很有趣：「完全有可能通過支持XA的資源啓動非XA事務，並在本地提交它」。但是，訪問相同的數據源並依賴於JTA和EJB CMT會發生什麼？ –

XA Datasource 1PC優化

回答

相關問題