問題タブ [xa]

私の知る限り、MDB で可能なのは AUTO_ACKNOWLEDGE と DUPS_OK_ACKNOWLEDGE だけです。XA トランザクションを回避するために、CLIENT_ACKNOWLEDGE のようなものが必要です。

基本的に私が欲しいもの：メッセージを取得する->ローカルトランザクションを開始する->データベース操作を実行する->ローカルトランザクションを終了する->メッセージを確認する

これを達成する方法を知っていますか？

現在、Jboss 5.1.GA を使用しています。

私が理解している限りでは、2 フェーズ コミットが実行される前に、トランザクションを各サイトに送信するための往復通信が必要です。各サイトはトランザクションの一部を実行し、コーディネーターがすべてのサイトから応答を受け取ると、2 フェーズ コミットを実行します。これにより、準備フェーズなどが開始されます。

2 フェーズ コミットに先行する実行から準備フェーズを分離する必要があるのはなぜですか? 実行フェーズと準備フェーズをマージして、往復の通信コストを削減しない理由はありますか?

これは私の前の質問へのフォローアップです。

アプリケーションログからの例外：

スプリング構成：

非XA構成の休止状態：

Hibernate XA構成：

ほとんどのビジネスロジックが発生するサービス実装クラスのコードスニペット：

Daoレイヤー1のコードスニペット：

Dao Layer2のコードスニッパー：

1. このアプリケーションは、ユーザーが同時にテストを受けることができるテストシステムです。
2. 当初、トランザクションの境界は私のDaoレイヤーではなく、サービス実装クラス（実際にはコントローラークラス）で、begin-commitブロック内の1つのトランザクションに複数の読み取りと更新が関連付けられていました。いくつかのデッドロックが発生していたので、境界をDaoレイヤーに移動し、begin-commitブロックの間にhqlステートメントが1つだけになるようにして、デッドロックを防ぐが運がなかったかどうかを確認しました。
3. hibernate.connection.autocommitをtrueに、hibernate.transaction.flush_before_completionをtrueに、hibehibernate.transaction.auto_close_sessionをtrueに設定しようとしましたが、うまくいきませんでした。
4. あるユーザーが読み取った行が別のユーザーによって更新されることはありません。各ユーザーは、同じDB2テーブルにアクセスしていても、異なる行を読み取って更新します。テスト用の一連の質問を作成するプロセスを実行するときにのみ、2人のユーザーが同じタイプのテストを受けている場合、同じ行を読み取ります。これは、上記のsomeDeadlockCausingMethodと非常によく似ており、テストの質問は、質問と回答を含む一連のテーブルから作成されます。forループ内でこの結果セットを反復処理することにより、新しい行が別のテーブルに挿入され、ユーザーのテストに表示される各質問の詳細が保存されます。2人のユーザーが同じテストを受けても、各ユーザーのすべての質問のプールからランダムな質問のセットが取得されるため、この手順はアプリケーションで必要です。
5. ユーザーがテストを受けるためのテストの準備ができたので、アプリケーションの次の論理的な手順は、テストを受けるユーザーに関する質問の詳細だけを含むテーブルから行を読み取ることです。したがって、同時ユーザーはこのプロセス中に同じテーブルを読み取りますが、同じ行を読み取ることはありません。ユーザーには、一度に1つの質問が表示されます。ユーザーが質問に回答すると、このユーザーのみに関連する質問を取得するために読み取られた行が、回答の選択肢で更新されます。この場合も、2人の同時ユーザーに対して同じ行が更新されることはありません。このメソッドは、上記のanotherDeadlockCausingMethod（）に類似しています。
6. アプリケーションが何をするのかを理解していただければ幸いです。同時ユーザーが同じ行を読み取ったり更新したりすることは決してないという事実は、リソースがどのようにロックされるかについて私を驚かせました。次に、テーブルが更新されるためにページロックが行われていることがわかりました。そこで私は行って、DBAに、更新されているテーブルの行ロックに変更できるかどうか尋ねました。彼は、行ロックを実装するためのDB2のパフォーマンスのオーバーヘッドを懸念しており、DB2を使用する他のアプリケーションに影響を与える可能性があるかどうかを心配しています。それで、私が他の解決策を見つけられない限り、彼はそれをしたくありません。
7. XA/JMSの部分は忘れてください。とりあえず、その部分がコメントアウトされていると仮定します。アプリケーションの大部分では、デッドロックが発生する場所で非XAデータソースが使用されます。

   デッドロックを解決するにはどうすればよいですか？デザインのどこが悪かったのか理解したい。どんな助けでも事前に大歓迎です

私は Resin の JtaTransactionManager を使用して Resin Server で jta トランザクションを管理しています。以下は transactionManager の spring config です。

以下はデータソース構成です。

1. この構成がうまく機能するのに、共通接続が 2 フェーズ コミットもサポートするのはなぜだろうか。
2. dbcp の接続を xa 接続に置き換える必要がある場合。
3. dbcp の接続が 2 フェーズ コミットをサポートするかどうか。

私は、AとBの2つの異なるデータソースを処理する必要があるSpringJavaEEアプリケーションで作業しています。

アプリケーションは一貫した方法でAとBを更新する必要があるため。1つの更新が失敗すると、プロセス全体が失敗し、ロールバックを実行する必要があります。

アプリケーションの実装方法について、2つの異なるアイデアがあります。

1. 両方の更新を分散トランザクションXAに含める必要があります。このアプローチは、パフォーマンスの点でコストがかかります。さらに、Bソースはまもなくオフになり、XAインフラストラクチャ全体を維持することがボトルネックになる可能性があります。
2. データベースAからデータベースBへのOracleDBリンクを設定し、Oracleが更新の同期を処理している間、アプリケーションが単一のデータソースとローカルトランザクションでのみ機能していると信じ込ませることができます。Bがオフになるときは、Bの更新を削除して、DBリンクをオフにします。

これらの2つのシナリオについてどう思いますか？

MQ を介して EJB アプリケーションにメッセージを受信して​​います。これは XA トランザクションです。メッセージを受信した後、いくつかの http 要求を送信し、応答を返す必要があります (これは RMI 呼び出しになります)。
私の懸念は、これらのリクエストのためにキューリスナーがシャットダウンする可能性があることです (http リクエストによる応答に時間がかかります)。
私が見つけた解決策は、サーバー管理スレッドで作業を行うか、別の EJB で作業を行うことでした。これは、現在動作している XA トランザクションのコンテキストでうまくいくためです (これについては正確にはわかりません)。
最善の解決策を教えてください。

XA アーキテクチャ、JMS、および Camel を使用した複数のコンテナにわたるトランザクション制御のサンプル コードを教えてください。

私はSpring Batchを使用して、データベースから/へのエクスポート/インポートを主に行う多数のバッチジョブを作成しています。Spring Batch ジョブ リポジトリ データベースとターゲット データベース (データの読み取り/書き込みの対象となるデータベース) は、異なるマシン上にあります。

私の質問は、この構成で XA トランザクションを使用する必要があるかどうかです。

ある時点で、ジョブ リポジトリ db へのリンクがブレーキをかけるシナリオについて疑問に思っています。データが破損する可能性はありますか? このような：

1. ジョブが開始されました (ジョブ リポジトリへの書き込み)
2. トランザクション内のターゲット データベースでの読み取り/処理/書き込み
3. ジョブ リポジトリへのリンク db ブレーキとジョブの失敗

最後に、ターゲット データベースを更新しましたが、ジョブが失敗したため、ジョブの再起動時に同じデータが再度処理されます。

新しいプロジェクトのために、生活を少し楽にしてくれるテクノロジーを探しています。私の新しいプロジェクトは、基本的に 2 つのクライアントとサーバーです。client1 はメッセージ 1 をサーバーに送信し、サーバーはメッセージ 1 をクライアント 2 に送信し、クライアント 2 はメッセージ 1 で何かを行います。

これは、プレーンな Java ソケットまたは RMI または同様の手法で実行できます。しかし、ここに問題があります。プロセス全体がトランザクションである必要があります。つまり、client2 が message1 を処理できない場合、client1 とサーバーはこれを認識し、実行されたアクションをロールバックする必要があります。

私の最初のアイデアは、クライアント 2 からクライアント 1 にメッセージを送信し、その結果をサーバーに送信することでした。

jms、jta、jca などのテクノロジーについてはすでに調べましたが、すべてに少し圧倒されました。そして、もっと簡単な方法があるのではないかと思います。