WebSphere MQ Version 7.x に接続されたアクティベーション・スペックまたは ASF リスナー・ポートを使用した厳密なメッセージ順序付け

厳密なメッセージ順序付けは、メッセージ駆動型 Bean アプリケーションを WebSphere MQ メッセージング・プロバイダーにデプロイするときに、非順次に着信したメッセージを処理するための特別な機能がアプリケーションにコーディングされていない場合に行うことができます。

WebSphere® Application Server バージョン 7 以降では、リスナー・ポートは安定化されています。詳しくは、安定化されたフィーチャーに関するトピックを参照してください。リスナー・ポートを使用する WebSphere MQ メッセージ駆動型 Bean のデプロイメント構成を、アクティベーション・スペックを使用する構成に移行する準備を行ってください。ただし、アプリケーションが WebSphere Application Server バージョン 7 より前のアプリケーション・サーバーで動作する必要がないことを確認するまでは、このマイグレーションを開始しないでください。例えば、一部のメンバーがバージョン 6.1 で一部のメンバーが新しいバージョンのアプリケーション・サーバー・クラスターがある場合、クラスター内のすべてのアプリケーション・サーバーを新しいバージョンにマイグレーションするまで、アクティベーション・スペックを使用するためにそのクラスター上のアプリケーションをマイグレーションしないでください。

このシナリオでは、以下のことを前提としています。

メッセージ駆動型 Bean (MDB) アプリケーションはトランザクション・タイプである。
WebSphere MQ キューのバックアウトしきい値 (BOTHRESH) が 0 に設定されている。
WebSphere MQ バージョン 7.0 以降を使用している。

オーダー配信用の WebSphere Application Server 構成

WebSphere MQ キュー・マネージャーは、WebSphere MQ バージョン 7.0 以降で稼働している必要があります。
キュー・マネージャーへの接続には、WebSphere MQ メッセージング・プロバイダーの通常モードを使用する必要があります。 WebSphere MQ 資料の「WebSphere MQ メッセージング・プロバイダー・モードを選択する場合の規則」トピックを参照してください。
リスナー・ポートを使用している場合は、 WebSphere Application Server のリスナー・ポートで「最大セッション数」を 1に設定する必要があります。
アクティベーション・スペック「最大サーバー・セッション数」を WebSphere Application Server のアクティベーション・スペックで使用する場合は、 1に設定する必要があります。

この構成に関する重要な情報

ASF リスナー・ポートおよび WebSphere MQ アクティベーション・スペックには、連動してメッセージ配信を実行する 2 つの異なるパーツがあります。これら 2 つのパーツは、キュー・マネージャーからは別個のアプリケーションと見なされます。
- 1 つ目のパーツは、着信したメッセージをただちに検出しますが、それらをコンシュームしません。代わりに、それらのメッセージを 2 つ目のパーツにディスパッチします。
- 2 つ目のパーツは、サーバーのセッション・プールであり、アプリケーションのトランザクション内でメッセージを処理するためにスレッドを割り振り、それを MDB の onMessage() メソッドに配信します。
バージョン 7.0 以降、WebSphere MQ は、メッセージ検出用のプッシュ・モデルを提供します。このモデルは、以前の WebSphere MQ のバージョンで使用されていたポーリング・モデルよりも効率が良く、通常の操作の下で、より良好なメッセージ順序付けを行うことができます。

メッセージが非順次で配信可能な状況

この構成では、以下の状況の場合、メッセージを非順次で配信可能です。

トランザクションのロールバック後に、キュー上の次の有効なメッセージが、ロールバックされたメッセージが再配信される前に配信される可能性があります。
- ASF リスナー・ポートの場合、「最大再試行数 (Maximum retries)」を zero に設定し、ロールバック発生時にリスナー・ポートを停止することで、ロールバック後の非順次配信を防ぎます。ただし、その後リスナー・ポートを手動で再始動する必要があります。
- アクティベーション・スペックでは、「メッセージ配信に失敗した場合にエンドポイントを停止 (Stop endpoint if message delivery fails)」を選択して「エンドポイントをサスペンドする前の連続デリバリー失敗回数 (Number of sequential delivery failures before suspending endpoint)」を 0 に設定し、ロールバック発生時にメッセージ・エンドポイントを一時停止することで、ロールバック後の非順次配信を防ぎます。ただし、その後 MDB のメッセージ・エンドポイントを手動で再開する必要があります。詳しくは、WebSphere MQ の資料を参照してください。
トランザクション・リカバリーの間は、メッセージが非順次に配信される可能性があります。
注: このシナリオが発生するには、特定のイベント・セットが特定の順序で発生する必要があるため、これは一般的ではありません。しかし、アプリケーションの操作にとって順序付けられたメッセージ配信が重要である場合には、考慮する必要があります。
- 以下のいずれかのコンポーネントが障害からリカバリーする間に、このデプロイメント・オプションで非順次メッセージ配信が起きる可能性があります。
  - MDB をホストしているアプリケーション・サーバー
  - WebSphere MQ キュー・マネージャー
  - アプリケーション・サーバーとキュー・マネージャーを接続しているネットワーク
- 上記のコンポーネントのいずれかで、MDB トランザクションの 2 フェーズ・コミットの途中で障害が発生した場合、アプリケーション・サーバーのトランザクション・マネージャーは、コンポーネントが再び使用可能になったときに、キュー・マネージャーへの接続を再確立し、トランザクションを解決します。
- このリカバリー・プロセスは非同期であり、トランザクション・リカバリー・プロセスが完了する前に MDB への新規メッセージの配信が開始することがあります。トランザクション・リカバリーの結果がトランザクションのロールバックである場合、メッセージは WebSphere MQ キューに返され、アプリケーションに再配信されます。これは、新しいメッセージが既に配信された後である可能性があります。

クラスター化されたデプロイメントに関する考慮事項

アプリケーション・サーバーには、このアクティベーションを自動的に管理できる機能がないので、1 つのクラスター・メンバーについてのみ MDB をアクティブ化する必要があります。
アプリケーションの始動状態の設定とは別個に、リスナー・ポートの始動状態を「停止 (stopped)」に設定することができます。
wsadmin スクリプトを使用するか、Java™ コードから com.ibm.websphere.management.AdminClient インターフェースを使用して、MBean インターフェースを持つアプリケーション、ASF リスナー・ポート、およびメッセージ・エンドポイントを手動で開始および停止することができます。