メッセージの順序付け

ある種の非同期メッセージング・アプリケーションでは、メッセージの順序付けが重要です。 つまり、プロデューサーが送信するのと同じ順序でメッセージを消費する必要があります。 ご使用のアプリケーションでこのタイプのメッセージの順序付けが重要な位置を占める場合は、 それを考慮に入れて設計する必要があります。

例えば、座席予約を処理するメッセージング・アプリケーションに、プロデューサー・コンポーネントが複数とコンシューマー・コンポーネントが 1 つあるとします。 カスタマーが座席を予約すると、プロデューサー・コンポーネントがコンシューマー・コンポーネントにメッセージを送信します。 カスタマーが予約を取り消すと、同じプロデューサー (場合によっては別のプロデューサー) が 2 番目のメッセージを送信します。 通常、コンシューマー・コンポーネントは、最初のメッセージ (座席の予約) を処理してからでなければ、2 番目のメッセージ (予約の取り消し) を処理できません。

一部のアプリケーションでは同期 (要求応答) パターンが使用されます。 その場合、プロデューサーは各メッセージに対する応答を待ってから、次のメッセージを送信します。 このタイプのアプリケーションでは、コンシューマーがメッセージの受信順序を制御して、 それがプロデューサー (複数可) の送信順序と同じにすることができます。 他のアプリケーションには非同期 (応答不要送信) パターンを使用するものもあり、 その場合、プロデューサーは応答を待たずにメッセージを送信します。 このタイプのアプリケーションでも、通常は順序が保持されます。つまり、コンシューマーは、特に連続したメッセージが十分な時間間隔で送信される場合には、メッセージの受信順序がプロデューサー (複数可) の送信順序と同じだと考えます。 しかし、設計段階ではこの順序が乱れる要因も考慮に入れる必要があります。

アプリケーションが送信するメッセージの優先順位が異なる場合 (優先順位の高いメッセージが優先順位の低いメッセージを追い越す可能性があります)、あるいはアプリケーションがメッセージ・セレクターを指定して最初のメッセージ以外のメッセージを明示的に受信する場合には、メッセージの順序が乱れます。 並列処理や、エラー処理または例外処理もメッセージの順序付けに影響を及ぼすことがあります。

並列処理

複数の宛先
プロデューサーがある宛先にメッセージを送信し、次に別の宛先に 2 番目のメッセージを送信する場合、 最初のメッセージがその宛先に到着する前に、2 番目のメッセージがその宛先に到着する可能性があります。 これは、プロデューサーが両方のメッセージを同じトランザクション内で送信した場合にも起こり得ることです (トランザクションは、両方の送信が失敗したか完了したかを確認しますが、配信順序までは確認しません)。 ご使用のアプリケーションでこの問題が発生する場合は、そのアプリケーションでは複数の宛先を使用しないでください。
複数のプロデューサー
1 つのプロデューサーがある宛先にメッセージを送信し、次に 2 番目のプロデューサーが同じ宛先に 2 番目のメッセージを送信する場合、2 番目のメッセージの方が最初のメッセージより先にその宛先に到着する可能性があります。 これは、例えば最初のプロデューサーからの信号を待ってからそのメッセージ (2 番目のメッセージ) を送信するという方法で、2 番目のプロデューサーが最初のプロデューサーと同期したとしても起こり得る現象です。 また、プロデューサーがトランザクションである場合にも発生する可能性があります (トランザクションが完了したからといって、メッセージ (複数可) が宛先に到着したとは限りません。サービス統合では、まずトランザクションを完了し、後でメッセージ (複数可) を配信することもあるからです)。 ご使用のアプリケーションでこの問題が発生する場合は、そのアプリケーションでは複数のプロデューサーを使用しないでください。 同様に、単一のプロデューサーに複数の並列スレッドを実行させることも避けてください。
複数のコンシューマー
複数のコンシューマーが存在するキュー・タイプの宛先に 2 つのメッセージが到着した場合、1 つのコンシューマーが最初のメッセージを受信し、別のコンシューマーが 2 番目のメッセージを受信する可能性があります。 コンシューマーを並行して実行できる場合、2 番目のメッセージを受信するコンシューマーが、最初のメッセージを受信するコンシューマーより先にメッセージを処理してしまうことがあります。 また、1 つのコンシューマーがトランザクショナルにメッセージを受信した後、そのトランザクションをロールバックすると、メッセージは宛先に戻され、別のコンシューマーがそのメッセージを受信できるようになります。一方、その別のコンシューマーが既に別の (後で送信された) メッセージを受信して処理してしまっている場合も考えられます。 ご使用のアプリケーションでこのいずれかの問題が発生する場合は、そのアプリケーションでは複数のコンシューマーを使用しないでください。 同様に、1 つのエンドポイントに対して複数の並行メッセージ駆動型 Bean (MDB) 呼び出しを許可しないでください (デフォルト・メッセージング・プロバイダーの MDB スロットルの構成 を参照)。 あるいは、厳密なメッセージの順序付けの使用を検討してください (バス宛先の厳密なメッセージの順序付けを参照)。
クラスタリングと分割宛先
キュー・タイプの宛先が、複数のメッセージング・エンジンを持つクラスター・バス・メンバーに割り当てられている場合、各メッセージング・エンジンには、それぞれ宛先の一区画 (すなわち宛先キュー・ポイントの 1 つ) が含まれています。サービス統合は、その宛先に対する各種のメッセージをそれぞれ別の区画に配信することができます。 このキュー・タイプ宛先構成により、拡張可用性、スケーラビリティー、およびロード・バランシングが提供されますが、通常これは、メッセージの順序付けが重要なアプリケーションには適しません。 サービス統合では、同じ宛先の異なる区画に送信されるメッセージの配列は保証されません。 また、メッセージング・エンジンに含まれる宛先区画にメッセージがある間に、そのメッセージング・エンジンに障害が起こる可能性もあります。その場合、メッセージング・エンジンが再始動するまで、コンシューマーはそのメッセージを使用できません。 ただし、サービス統合では、新しいメッセージを (他のメッセージング・エンジンの) 他の区画に配信することは引き続きできるので、コンシューマーは、障害が発生したメッセージング・エンジン区画上の古いメッセージより先に、その新しいメッセージを受け取って処理することができます。 キュー宛先のあるワークロード共有では、 このタイプの構成について詳しく記述し、クラスター内の単一プロデューサーと単一コンシューマーの間でメッセージの順序付けを保持することができる「メッセージ・アフィニティー」オプションの使用方法についても説明します (ただし、クラスターが別のサービス統合バスにある場合は保持できません)。
パブリッシュおよびサブスクライブ
パブリッシュ/サブスクライブ・メッセージングでは、サービス統合は、サブスクリプションの別々のインスタンス (共有を許可するために設定される「永続サブスクリプションを共有」プロパティーを使用して作成される永続サブスクリプションの個別のインスタンスを含む) が受信するメッセージの配列は保証しません。

エラーおよび例外条件

サービスの品質
エラーおよび例外条件がメッセージの配信に与える影響は、メッセージのサービスの品質によって決まります (メッセージの信頼性レベル - JMS デリバリー・モードとサービス統合のサービスの品質を参照)。 サービスの品質によっては、エラーまたは例外条件によって、サービス統合がメッセージを確実に (一度で) 配信できたり、配信の信頼性が低下したり (複数回試行した後に配信されるか、まったく配信されない) することがあります。 例えば、サービスの品質が「高速非パーシスタント」である場合は、 障害後に一連のメッセージを再配信することができます。ただし、基本の順序は常に保持されるため、 メッセージが、1、2、3、2、3、4 のような順序で届くことがあります。要するに、サービス統合では、 異なるサービス品質で送信される異なるメッセージの順序は保証されません。 ご使用のアプリケーションでこの問題が発生する場合は、必ず適切なサービス品質を選択するようにして、同じ宛先に送信するメッセージに異なるサービス品質を混在させることは避けてください。
例外宛先
特定の障害シナリオでは、サービス統合がメッセージを例外宛先に配信する場合も、 メッセージを宛先に配信した後にそのメッセージを例外宛先に転送する場合もあります。 サービス統合では、例外宛先に送信または転送するメッセージの配列は保証されません。 ご使用のアプリケーションでこの問題が発生する場合は、例外宛先を使用しないように宛先を構成することができます (例外宛先を参照)。 プロデューサーと宛先が異なるバスにある場合は、それらのバス間のリンク (複数可) を、例外宛先を含まないように構成できます (外部バスおよび外部バスへのリンクに対する例外宛先処理の構成を参照)。
トランザクションのロールバック
メッセージ駆動型 Bean (MDB) のアクティベーション・スペックでは、障害が発生しているメッセージの再試行間の遅延を指定できます。 この遅延によって、同じメッセージが MDB を再び駆動する前にロールバックのリカバリーを行うための条件を整える時間ができます。ただし、メッセージがこの方法で遅延されている間に、別の (後で配信された) メッセージで MDB を駆動することはできます (システム・リソース問題からの MDB アプリケーションの保護を参照)。 ご使用のアプリケーションでこの問題が発生する場合は、順次障害の最大回数を 1 に制限するか (JMS アクティベーション・スペック [設定] を参照)、 厳密なメッセージの順序付けを使用する (バス宛先の厳密なメッセージの順序付けを参照) ことを検討してください。
未確定トランザクションの解決
2 フェーズ・コミット処理中に、JMS の送信または受信操作が未確定の場合はアプリケーションに障害が発生することがあります。この場合、 未確定状態が解決する前にアプリケーションが再始動する可能性があり、そうなると、アプリケーションの再始動時には「不可視」だった 1 つ以上のメッセージが後で「可視」になります。 宛先上のそれ以外のメッセージには影響はありません。 コンシューマー・アプリケーションは、「不可視」メッセージ (例えばメッセージ 1) より論理的には後になるメッセージ (例えばメッセージ 2) を受信できます。その後アプリケーションは、未確定トランザクションの解決後に、以前は「不可視」だったメッセージ (メッセージ 1) を受信します。 このように、アプリケーションはメッセージを間違った順番で受信し、処理する場合があります。 ご使用のアプリケーションでこの問題が発生する場合は、 厳密なメッセージの順序付けを使用する (バス宛先の厳密なメッセージの順序付けを参照) ことを検討してください。

トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjj8000_
ファイル名:cjj8000_.html