問題タブ [atomikos]

2 つの異なるリモートの activeMQ ブローカー間で jms メッセージを移動しようとしています。

私はスタンドアロン アプリケーションを作成しているため、Atomikos を使用しています。また、Spring を使用してすべてを機能させています。

次のBean javaconfigセットアップがあります

DMLC を開始する前に、実行時に 2 つの AtomikosConnectionFactoryBean が ActiveMQXAConnectionFactory (ブローカーごとに 1 つ) をラップしています。

次に、次のメソッドを使用して、簡単な messageListener (開始前に dmlc に割り当てられます) をセットアップします。

アプリケーションは特定のエラーや警告なしで起動しますが、ソース キューにメッセージを入れるとすぐに、同じメッセージに対して onMessage メソッドが何度も実行されていることがログで確認できます。ロールバックして再起動します (エラーはどこにもスローされません)。

また、たまたま同じソース URL と宛先 URL (同じブローカーを意味しますが、それぞれに独自の connectionFactory があることを意味します) を使用すると、それが機能し、メッセージがソース キューと宛先キューの間で意図したとおりに転送されることにも気付きました。

私が疑問に思っているのは

1. セットアップで何が間違っていますか? 2 つの異なるブローカーを使用しているのに、同じブローカーを使用している場合 (ただし 2 つの異なる接続ファクトリを使用している場合) にトランザクションが何度もロールバックされているように見えるのはなぜですか?
2. 現在、すべての例外をキャッチして何もしていないため、onMessage が現在適切なトランザクションを行っているとは完全に確信していません。これにより、jmstemplate がメッセージの送信を完了する前に dmlc のトランザクションがコミットされると思いますが、確信が持てません。この場合、代わりに SessionAwareMessageListener の方がよいでしょうか? onMessage メソッドで @Transacted を設定する必要がありますか?

この問題に光を当てるのを手伝ってくれる人はいますか? すべての入力を歓迎します。

アップデート：

「ロールバック」の問題は、使用していた両方の AMQ がブローカーのネットワークを介して相互に接続されており、たまたまソースと宛先に同じキュー名を使用していたことが原因であることに気付きました。これにより、メッセージがアプリケーションによってある AMQ から別の AMQ に転送された後、すぐに、ソース AMQ にコンシューマーがあったため、メッセージは元の AMQ に転送され、元の AMQ として認識されました。アプリケーションによって新しいメッセージが送信され、再度転送され、サイクルは無限に続きました。以下に投稿された解決策は、他の問題に役立ちました。

実行した手順:

1. リンク http://www.atomikos.com/Documentation/Tomcat7Integration35に記載されているすべての手順に従いまし た。「atomikos-integration-extension-3.7.1-20120529.jar」を TOMCAT_HOME/lib フォルダーにコピーしました。

   b. サーバー.xml

   c. context.xml

   d. 必要なすべてのトランザクション jar を追加しました。また、トランザクション プロパティ:

2. コードで行われた変更、

を。transaction.xml :

問題: メッセージをキューにプッシュしようとした場合にのみ、常に No JTA TransactionManager found がログに記録されます。DB 呼び出しを正常に実行できます。

誰かがこの問題に直面したことがある場合は、どのように解決したかをお知らせください。

この構成 (MainConfig.java) では:

(CustomerConfig.java)

(OrderConfig.java)

(CustomerRepository.java)

(OrderRepository.java)

このテストを実行すると、NullPointerException が発生します。

null オブジェクトは transactionManager のようで、適切に注入されていないと思います。スタックトレースの関連部分は次のとおりです。

pom ファイルは次のとおりです。

完全なコードは Github で入手できます: https://github.com/fabiomaffioletti/mul-at 誰にもヒントはありますか？

顧客接続のスプリング ブートのコンソール ログをたどります。

私は、Spring Integration フレームワークと分散トランザクション用の atomikos を使用して構築されたプロジェクトに取り組んでいます。最近、統合テストを実行して、メッセージがシステムを介して正しく送信されていることを確認しようとしています。これらの統合テストの 1 つを実行すると、新しいトランザクションが作成されていることを示す 10 個のログ メッセージと、トランザクションのコミットを示す 10 個のログ メッセージが表示されることに気付きました。

メッセージがチャネルからエンドポイントに、またはその逆に渡されるたびに、Spring は新しいトランザクションを作成しますか?

以下のコードは、(transactionManager を使用して) message-driven-channel-adapter でメッセージを受け取り、ルーターに送信します。次に、ルーターは、トランスフォーマー、サービス アクティベーター (retryAdvice を使用)、およびアウトバウンド メッセージ アダプターを含むチェーンにメッセージを送信します。

私の知る限り、メッセージ駆動型チャネル アダプターがキューからメッセージを受信すると 1 つのトランザクションが作成され、メッセージの処理が完了するとコミットが行われるはずです。したがって、合計で 3 つのトランザクションがあると思いました。テストでのメッセージの送信から 1 つ、インバウンド アダプターから 1 つ、テストでのメッセージの受信から 1 つです。

spring-datasource.xml から

spring-context.xml から

メッセージエンドポイント

試験方法

ログ

春にアプリケーションがあり、DB および jms キューとやり取りするサービスはほとんどありません。2 フェーズ コミットを処理するために、atomikos を使用しました。

私が持っている質問は、設計の観点から、サービス実行の最後にすべてのキュー操作を行う場合、キューにメッセージを入れた後のエラーの可能性が非常に少なくなる場合、それでも 2 フェーズ コミットを使用する必要がありますか?

私は以前のプロジェクトで 2 台の PC を使用しており、サービス ロジックが上記のように適切に調整されていれば、データが破損する可能性は非常に低いと常に感じています。

もちろん、失敗するケースもあります (ネットワークまたはデータベースの障害のために txn をコミットできない場合、キューは処理されます) - いずれにせよ対処しなければならない大きな問題です。

ご意見をお聞かせください。サービス ロジックを整理することで、上記のような 1 つの DB と 1 つの jms キューのみが関係する単純なシナリオで JTA を回避できないでしょうか?

ありがとう、ライヴ。 

概念実証の 1 つとして、JTA に Hibernate と Atomikos を使用しています。おそらくタイムアウトが原因で、JTA トランザクションの予期しないロールバック例外が発生します。例外は次のとおりです。

javax.transaction.RollbackException: Prepare: NO vote