未処理の各セッションには、アプリケーションが受信したメッセージの確認方法を決定する肯定応答モードがあります。 可能な肯定応答モードは 3 つ存在し、肯定応答モードの選択は、アプリケーションの設計に影響を及ぼします。
このトピックの情報が該当するのは、アプリケーションが WebSphere MQ キュー・マネージャーまたは WebSphere サービス統合バスに接続している場合に限ります。ブローカーへのリアルタイム接続の場合、この情報は該当しません。
XMS が使用しているメッセージ受信を確認する仕組みは、JMS が使用している仕組みと同じです。
セッションが未処理である場合、アプリケーションが受信したメッセージを確認する方法は、セッションの肯定応答モードによって決まります。 肯定応答モードは、以下の 3 つです。
メッセージがアプリケーションに同期化して配信されると、セッションは、Receive 呼び出しが正常に完了するたびにメッセージの受信を確認します。メッセージが C アプリケーションに非同期状態で配信されると、セッションは、メッセージ・リスナー関数の呼び出しが正常に完了するたびにメッセージの受信を確認します。 C++ アプリケーションの場合、セッションは、メッセージ・リスナーの onMessage() メソッドの呼び出しが正常に完了するたびにメッセージの受信を確認します。
アプリケーションはメッセージを正常に受信したが、障害のために肯定応答を実行できなかった場合、そのメッセージは再度配信できるようになります。このため、アプリケーションは再配信されるメッセージを処理できる必要があります。
この肯定応答モードを使用すると、セッションが実行する必要がある処理の量は削減されますが、肯定応答を実行できない障害が発生すると、複数のメッセージが再配信の対象になる可能性があります。このため、アプリケーションは再配信される複数のメッセージを処理できる必要があります。
アプリケーションは、各メッセージの受信を個別に確認できます。 あるいは、アプリケーションは複数のメッセージを一括して受信し、受信した最後のメッセージの場合にのみ Acknowledge メソッドを呼び出すこともできます。 Acknowledge メソッドを呼び出すと、このメソッドの前回の呼び出し以降に受信したすべてのメッセージの肯定応答が実行されます。
アプリケーションは、前述した肯定応答モードと関連して、Session クラスの Recover メソッドを呼び出すことにより、セッション中にメッセージの配信を停止することや再開することができます。受信が以前に確認されなかったメッセージは、再配信されます。 ただし、これらのメッセージは、以前配信されたときと同じ順序では配信されない場合があります。 その間に、優先度の高いメッセージが到着し、元のメッセージの一部は有効期限が切れることがあります。 さらに、Point-to-Point ドメインでは、元のメッセージの一部が別のアプリケーションによってコンシュームされることがあります。
アプリケーションは、メッセージの JMSRedelivered ヘッダー・フィールドの内容を調べることにより、そのメッセージが再配信されるかどうかを判別できます。 アプリケーションは、Message クラスの Get JMSRedelivered メソッドを呼び出すことにより、これを実行します。