2

私は分散トランザクションの必要性から JTA の世界に足を踏み入れていますが、両者の違いjavax.jms.ConnectionFactoryやjavax.jms.XAConnectionFactory、より正確に言えば、私javax.jms.ConnectionFactoryにしかできないと期待していたことがどのように実行されるのかがわかりjavax.jms.XAConnectionFactoryません。

詳細: Atomikos Essentials をトランザクション マネージャーとして使用しており、アプリは Apache Tomcat 6 で実行されています。

OpenMQJMS プロバイダー ( ) をリソースとして登録したダミー アプリを使用して小さな POC を実行していますJNDI。 

<Resource name="jms/myConnectionFactory" auth="Container"  
 type="com.atomikos.jms.AtomikosConnectionFactoryBean"  
 factory="com.atomikos.tomcat.EnhancedTomcatAtomikosBeanFactory"   
uniqueResourceName="jms/myConnectionFactory"  
xaConnectionFactoryClassName="com.sun.messaging.XAConnectionFactory"  
maxPoolSize="3"/>

そして奇妙な問題は、私のコードでこれを行うことです: 

Context ctx = new InitialContext();  
ConnectionFactory queueConnectionFactory =  
(ConnectionFactory)ctx.lookup("java:comp/env/jms/myQueueFactory");  
javax.jms.Connection connection = queueConnectionFactory.createConnection();  
Session session = connection.createSession(true, Session.AUTO_ACKNOWLEDGE);

コードの後半で、このセッションを a で使用すると、 または のいずれかを使用UserTransactionして 2 つMessageProducerの s で問題なく動作します。CommitRollback

私が理解していないのはjavax.jms.XAConnectionFactory.createConnection()、メソッドを使用していて、Sessionどのジョブが機能するかということです。javax.jms.XAConnectionFactory役割は？

javax.jms.BasicConnectionFactoryまた、両方のクラス (および) のソース コードを調べ、XA クラスが をオーバーライドしないことを確認したことも付け加えておきますcreateConnection。

4

2 に答える 2

3

ConnectionFactory と XAConnectionFactory の主な違いは、XAConnectionFactory が XASession を作成する XAConnections を作成することです。XASessions は実際の違いを表しています ( JMS JavaDocs から引用するため:)

XASession インターフェースは、Java Transaction API (JTA) (オプション) に対する JMS プロバイダーのサポートへのアクセスを追加することにより、Session の機能を拡張します。このサポートは、javax.transaction.xa.XAResource オブジェクトの形式を取ります。

つまり、XASession は、XA インスタンスにトランザクション認識を与えるものです。ただし、この特定の実装は、完全に準拠した JMS プロバイダーであってもオプションです。同じ JavaDoc から:

XAResource は、複数のトランザクションで作業をインターリーブしたり、進行中のトランザクションのリストを回復したりするためのかなり洗練された機能を提供します。JTA 対応の JMS プロバイダーは、この機能を完全に実装する必要があります。これは、XA をサポートするデータベースのサービスを使用して行うことができます。または、JMS プロバイダーがこの機能を最初から実装することを選択する場合もあります。アプリケーション サーバーのクライアントには、通常の JMS セッションと見なされるものが与えられます。バックグラウンドでは、アプリケーション サーバーが基盤となる XASession のトランザクション管理を制御します。

言い換えれば、プロバイダーは、XA または非 XA JMS リソースを指定することを要求する場合があります。または、あなたの場合のように、プロバイダーは、通常の JMS Sessionのように見えるものを使用して、すべての JTA 配管を透過的に実行する場合があります。

于 2010-11-07T13:00:25.557 に答える
1

実際、あなたが提供したサンプル コードはいずれも XA 機能を実行しません。メッセージが同期点の下にあることだけが必要な場合は、1 フェーズ コミット (1PC) で十分です。ただし、たとえば、JMS メッセージと DB の更新を単一の調整された作業単位で行う場合は、XA である 2 フェーズ コミット (2PC) を使用します。同じトランスポート プロバイダー上の 2 つのメッセージ プロデューサ間での調整には、XA 2PC は必要ありません。

2PC を使用していた場合、COMMIT と ROLLBACK に加えて、コードのどこかで BEGIN を呼び出すことになります。あなたの例にその動詞がないのは、あなたが2PCをしていないように見えると言った理由です. BEGIN 呼び出しは、トランザクション マネージャーと通信して、参加しているリソース マネージャー間でトランザクション コンテキストを確立します。次に、COMMIT により、メッセージとDB の更新が 1 つの作業単位で終了します。ここで興味深いのは、参加しているリソース マネージャーが 1 つしかない場合、一部のトランスポートはサイレントに最適化して 1PC に戻すことです。その場合、2PC を実行しているように見えますが、実際には 1PC を取得しています。リソース マネージャーは 1 つしかないため、この最適化で信頼性が失われることはありません。

一方、1PC を実行している場合は、2 つのタイプの接続ファクトリに違いは見られません。あなたが説明した動作を正確に示します。

考慮すべき最後のケースは、ConnectionFactory を使用して BEGIN を呼び出そうとすることです。非 XA 接続ファクトリは調整された XA トランザクションに参加できないため、この呼び出しは失敗するはずです。

于 2010-11-07T14:29:53.693 に答える