3

メッセージがキューから読み取られるとき (破壊的な呼び出し)、後で TX がロールバックされた場合 (MDB コンテナーで管理された TX)、メッセージがキューに戻されることを観察しました (バックカウントとキューのしきい値設定に応じて、元のキューまたはバックアウト キュー)。 . TX のロールバックが失敗したために何かが発生した場合 (繰り返されるネットワークの問題または何らかの問題)、メッセージが失われるとしましょう。

本当ですか??

ありがとう

4

2 に答える 2

3

前の質問へのコメントで述べたように、短い答えは「いいえ、失敗しても WMQ はそれらのメッセージを失うことはありませCOMMITん」ですが、もう少し詳しく見てみましょう。

クライアントがネットワーク経由で MQ に接続すると、MQ は、MQ への共有メモリ接続とクライアント アプリケーションへのソケット接続を作成するプロセスを開始します。トランザクションを開いたままにしておくのは、WMQ 用語で「チャネル エージェント」と呼ばれる共有メモリ プロセスです。

COMMITアプリケーションの観点から失敗したように見える2 つのケースがあります。これらの最初の例でCOMMITは、 がチャネル エージェントに配信されて実行されますが、ネットワークの問題により、確認がアプリケーションに返されることはありません。GETMQ の観点からは、アプリが意図的に呼び出しをコミットしたため、メッセージが「失われた」わけではありません。

COMMIT2 番目のケースは、 がチャネル エージェントに到達する前にネットワーク障害が発生した場合です。この場合、COMMITアプリはトランザクションが存在する接続ハンドルを回復できないため、本当に失敗しています。チャネル エージェントは、TCP 接続が失敗したことを認識すると、トランザクションをバックアウトしてチャネルを閉じます。このプロセスの問題点は、チャネル エージェントが接続が切断されたことを認識するまでに時間がかかることです。実際、ほとんどのプラットフォームでのデフォルトの TCP タイムアウトは 2 時間です。サーバーの TCP 設定に応じて、トランザクションGETそのメッセージを同期点で最大 2 時間保持し、消費されたように見せることができます。これが、現在のレベルの QMgr とクライアントを使用することが強く推奨される理由の 1 つです。失われた接続を検出するために、TCP への依存度が低くなり、内部チャネル ハートビート プロトコルへの依存度が高くなります。

アプリケーションの観点からは、これらのケースはどちらも同じように見えます - app 呼び出しCOMMITと 2009 を取得しますMQRC_CONNECTION_BROKEN。ただし、最初のケースではメッセージが原因で失わCOMMITれ、2 番目のケースではメッセージが再度配信される可能性があります。このあいまいさのため、アプリは重複メッセージを検出して適切に処理できる必要があります。

これが MQ の欠陥であると断言する前に、この結果のあいまいさは、ネットワーク経由でメッセージングを使用する場合に固有のものであり、WebSphere MQ に固有のものではないことを指摘しておきます。実際、JMS 1.1 仕様では、4.4.13 でこれに直接対処しています。

クライアントがセッションで作業をコミットしてから commit メソッドが戻るまでの間に障害が発生した場合、クライアントはトランザクションがコミットされたかロールバックされたかを判断できません。PERSISTENT メッセージの非トランザクション送信と送信メソッドからの戻りとの間に障害が発生した場合にも、同じあいまいさが存在します。

このあいまいさに対処するのは、JMS アプリケーション次第です。場合によっては、これによりクライアントが機能的に重複したメッセージを生成することがあります。

セッション回復のために再配信されたメッセージは、重複メッセージとは見なされません。

したがって、同期点を使用すると、メッセージが失われるケースを排除できます。これは、キューからメッセージを永続的に削除するには、メッセージのGET後に a が続く必要があるためです。COMMIT定義上、COMMITアプリケーションがメッセージを確認するまで は到着できません。ただし、同期点はメッセージの重複の可能性を排除できません。これは、いずれかのCOMMITがGET失敗した場合、アプリがメッセージを再度表示する可能性があるためです。同様に、の が失敗しCOMMITたPUT場合、アプリは がCOMMITチャネル エージェントに到達する前に失敗したのか、到達した後に失敗したのかを知る方法がなく、再接続しPUTてメッセージを再度送信するしかありません。

実際に「失われた」メッセージが発生している場合は、次の可能性があります。

  1. 送信アプリは で失敗しましたCOMMITが、メッセージの別のコピーを送信しませんでした。
  2. 上でGETting アプリが失敗しCOMMIT、メッセージは失われていませんが、実際には同期点にあります。その場合、孤立したチャネルを停止して、トランザクションをロールバックします。

これらの 2 つのケース以外では、WMQ はその永続的なメッセージを失うことはありません。

于 2012-11-17T17:32:54.917 に答える
1

いいえ。メッセージは失われません。トランザクションでは、メッセージはコミットが成功した後にのみキューから削除されます。コミットまたはロールバックが失敗すると、メッセージが再表示されます。コミットまたはロールバックが呼び出される前にアプリケーションとキュー・マネージャー間の接続が切断された場合、WebSphere MQ は自動的にロールバックを行います。これにより、メッセージが失われないことが保証されます。

于 2012-11-17T11:23:29.210 に答える