サーバー側エラー
リスナーとプレーヤーは、連携して有害なメッセージに対処します。 再生中のトランザクションが失敗した場合、メッセージ キューイングは入力メッセージを入力キューに戻します。 サーバー コンポーネントから失敗した HRESULT を受け取った場合、または例外をキャッチした場合、プレーヤーはトランザクションを中止します。 問題が解決されない場合、リスナーは次のパターンでループし続ける可能性があります。
- メッセージをデキューする
- オブジェクトをインスタンス化する
- ロールバックが発生する
- メッセージをキューの一番上に戻す
キューに登録されたコンポーネント サービスは、アプリケーション固有の一連の再試行キューを使用することにより、このエラーを処理します。 コンポーネントのインストール時に作成されるキューは、以下に示すとおり、アプリケーションごとに 7 つあります。
通常の入力キュー。 このキューの名前は COM+ アプリケーション名です。 これは、"メッセージ キューイング" パブリック キューです。
最初の再試行キュー。 通常の入力キューからのメッセージを処理するときにトランザクションが繰り返し失敗した場合、メッセージはここに移動されます。 このキューのメッセージは 1 分後に処理されます。 メッセージは、2 番目の再試行キューの背面に移動される前に、このキューで 3 回再試行することができます。 このキューの名前は ApplicationName_0 です。 このキューは、プライベート "メッセージ キューイング" キューです。
2 番目の再試行キュー。 最初の再試行キューからのメッセージを処理するときにトランザクションが繰り返し失敗した場合、メッセージはここに移動されます。 このキューのメッセージは 2 分後に処理されます。 メッセージは、3 番目の再試行キューの背面に移動される前に、このキューで 3 回再試行することができます。 このキューの名前は ApplicationName_1 です。 このキューは、プライベート "メッセージ キューイング" キューです。
3 番目の再試行キュー。 2 番目の再試行キューからのメッセージを処理するときにトランザクションが繰り返し失敗した場合、メッセージはここに移動されます。 このキューのメッセージは 4 分後に処理されます。 メッセージは、4 番目の再試行キューの背面に移動される前に、このキューで 3 回再試行することができます。 このキューの名前は ApplicationName_2 です。 このキューは、プライベート "メッセージ キューイング" キューです。
4 番目の再試行キュー。 3 番目の再試行キューからのメッセージを処理するときにトランザクションが繰り返し失敗した場合、メッセージはここに移動されます。 このキューのメッセージは 8 分後に処理されます。 メッセージは、5 番目の再試行キューに移動される前に、このキューで 3 回再試行することができます。 このキューの名前は ApplicationName_3 です。 このキューは、プライベート "メッセージ キューイング" キューです。
5 番目の再試行キュー。 5 番目の再試行キューからのメッセージを処理するときにトランザクションが繰り返し失敗した場合、メッセージはここに移動されます。 このキューのメッセージは 16 分後に処理されます。 メッセージは、最後の静止キューに移動される前に、このキューで 3 回再試行することができます。 このキューの名前は ApplicationName_4 です。 これは、プライベート "メッセージ キューイング" キューです。
アプリケーション固有の最後の静止キュー。 5 番目の再試行キューで試行されたときにトランザクションが繰り返し中止した場合、メッセージはここに移動されます。 このキューの名前は ApplicationName_DeadQueue です。 これは、プライベート "メッセージ キューイング" キューです。 最後の静止キューは、キュー リスナーによって処理されません。 メッセージは、(キューに入っているコンポーネントのメッセージ ムーバー ユーティリティなどによって) 手動で移動されるか、メッセージ キューイング エクスプローラーによって消去されるまで、ここにとどまります。
すべての再試行が失敗することは明らかであるため、再生できないメッセージは、すべての再試行レベルを進むことなく、アプリケーション固有の最後の静止キューに直接移動させることができます。
プレーヤーは COM+ イベントを発行し、メッセージを再生できないことを関係者に通知します。 COM+ イベントは以下の状況で発行されます。
- トランザクションが中止されたとき
- メッセージがキュー間で移動されたとき
- メッセージが最後の静止キューに登録されたとき
メッセージはキュー間を移動する前に変更できます。 COM+ のキューに登録されたコンポーネントのセキュリティ メカニズムを使用すると、メッセージを移動してキューを再試行し、アプリケーションの初期入力キューに再挿入できます。 キューに登録されたコンポーネントのセキュリティについて詳しくは、「キューに登録されたコンポーネントのセキュリティ」をご覧ください。
再試行キューは、アプリケーションがコンポーネント サービス管理ツールにより、または COM+ Administrative SDK 関数を使用することによりキューに登録済みとマークされている場合に、メイン アプリケーション キューと共に作成されます。 キューに登録されたコンポーネント サービスを使用すると、再試行キューを削除可能することで、再試行メカニズムの柔軟性が高まります。 たとえば、すべての再試行キューが削除された場合、永続的に中止するメッセージは、アプリケーション キューからアプリケーション固有の最後の静止キューに直接移動されます。 1 つ以上の再試行キューを削除することにより、再試行の数と長さを小さくすることができます。 キューが再試行シーケンスから削除された場合、残りのキューのタイミングは、再試行キューのシーケンス内の位置に対応します。 たとえば、再試行キュー ApplicationName_1、ApplicationName_2、ApplicationName_3 を削除した場合、ApplicationName_4 上のメッセージは、キューが 2 番目の再試行キューであるかのように処理されます。
再試行メカニズムは、可能な限りメッセージを完了するよう設計されています。 場合によっては、メッセージが成功しない可能性があります。 たとえば、クライアントは、資金が不足しているアカウントからお金を引き出そうとしているかもしれません。 このような状況では、次のようにさまざまな方法でエラーを処理することができます。
- 診断を生成して警告を発行する
- 補正トランザクションを作成する
- 問題を無視してメッセージを無視する
クライアント側の永続的なエラーと同様、キューに登録されたコンポーネント サービスを使用すると、例外クラスをコンポーネントに関連付けることができます。 例外クラスは、コンポーネント サービス管理ツールのコンポーネント プロパティ ページにある [詳細設定] タブを使用するか、COM+ Administrative 関数を使用して、コンポーネントに関連付けられます。 例外クラスを使用すると、メッセージが再試行された後、そのメッセージがアプリケーション固有の最後の静止キューに移動される前に、開発者が制御できるようになります。 例外クラスについて詳しくは、「永続的なクライアント側エラー」をご覧ください。
以下に、サーバー側の例外処理の一連のイベントを示します。
- メッセージは、使用可能なアプリケーション固有の再試行キューを通じて移動されます。
- 最後の静止キューでの最後の再試行が失敗します。
- キューに登録されたコンポーネント サービスのランタイムは、メッセージからターゲット コンポーネントを取得し、例外クラスをチェックします。
- ランタイムは、例外クラスをインスタンス化します。
- 例外クラスに対する実行時クエリ IPlaybackControl。
- ランタイムは、例外クラスで IPlaybackControl::FinalServerRetry を呼び出します。
- ランタイムは、メッセージから例外クラスへのプロパティおよびメソッド呼び出しをすべて再生します。
- 手順 4 から 6 が成功しない場合、ランタイムはメッセージをアプリケーション固有の最後の静止キューに移動します。
上記のプロセスに介入する必要がある場合、または有害なメッセージを最後の静止キューから移動する必要がある場合、メッセージ ムーバー ユーティリティーを使用します。 メッセージ ムーバー ユーティリティーについて詳しくは、「エラーの処理」をご覧ください。
関連トピック