次の方法で共有


永続的な Client-Side エラー

場合によっては、メッセージ キュー メッセージを宛先キューに移動できます。 たとえば、キューのアクセス制御でメッセージをクライアントからサーバーに移動することが許可されていない場合、問題のあるメッセージはクライアント側の配信不能キューに移動されます。 この場合、COM+ キューに登録されたコンポーネント サービスでは、例外クラスをコンポーネントに関連付けられます。 例外クラスをコンポーネントに関連付けるには、コンポーネント サービス管理ツールのコンポーネント プロパティ ページにある [詳細] タブを使用します。 COM+ 管理機能の ExceptionClass カタログ コンポーネント属性を使用して、例外クラスをプログラムで関連付けることもできます。

例外クラスは、IPlaybackControlを実装するコンポーネントの ProgID または CLSID として定義されます。 キューに置かれたコンポーネント サービスには、Xact 配信不能キューをスキャンする配信不能キュー モニターがあります。 キューにメッセージがある場合、配信不能キュー モニターはターゲット コンポーネントに関連付けられている例外ハンドラーをインスタンス化し、クライアント側の回復不可能なエラーが発生したことを示す IPlaybackControl::FinalClientRetry呼び出します。

IPlaybackControlに加えて、例外ハンドラーは、例外を処理するサーバー コンポーネントと同じインターフェイス セットを実装する必要があります。 IPlaybackControl::FinalClientRetry呼び出されると、キューに登録されたコンポーネントの実行時に、失敗したメッセージが例外ハンドラーに再生されます。 これにより、例外ハンドラーは、たとえば補正トランザクションを生成することによって、サーバーに移動できないメッセージの代替動作を実装できます。

例外ハンドラーが再生されたすべてのメソッド呼び出しを完了すると、メッセージは Xact 配信不能キューから削除され、無視されます。 ただし、例外ハンドラーがいずれかのメソッド呼び出しからエラー状態を返すことによってメッセージを中止した場合、メッセージは Xact 配信不能キューに返されます。 次の一連のイベントは、クライアント側の例外の処理方法を示しています。

  1. メッセージ キューがサーバーにメッセージを配信できず、メッセージを Xact 配信不能キューに配置します。
  2. 配信不能キュー リスナー (DLQL) は、Xact 配信不能キューでメッセージを検索します。
  3. DLQL は、メッセージからターゲット コンポーネント CLSID を取得し、例外クラスをチェックします。
  4. DLQL は例外クラスをインスタンス化します。
  5. 例外クラスの IPlaybackControl の DLQL クエリ。
  6. DLQL は、例外クラスの IPlaybackControl::FinalClientRetry メソッドを呼び出します。
  7. DLQL は、メッセージから例外クラスへのすべてのプロパティおよびメソッド呼び出しを再生します。
  8. 例外ハンドラーがトランザクションを正常に完了した場合、DLQL はメッセージを削除します。 例外ハンドラーは IObjectContext::SetAbort発行する場合があり、メッセージは配信不能キューに残ります。

上記のいずれかの手順が失敗した場合、メッセージは Xact 配信不能キューに残ります。

開始すると、DLQL はメッセージ キュートランザクション配信不能キューの各メッセージを読み取り、キューに登録された各コンポーネント メッセージの例外クラスをインスタンス化します。 キューを 1 回通過した後、新しいメッセージを待機します。 その後、新しい配信不能キュー メッセージが到着するたびに処理されます。

ここで説明するプロセスに介入する必要がある場合、または有害メッセージを最終的な休止キューから移動する必要がある場合は、メッセージ・ムーバー・ユーティリティーを使用します。 メッセージ・ムーバー・ユーティリティーの詳細については、エラー処理 を参照してください。

Client-Side エラー

Server-Side エラー