次の方法で共有


状態管理

一般に、状態を保持するアプリケーションでは、その状態がデータベース テーブルに格納されます。各メッセージ交換グループには一意な ID があり、通常、この ID は状態テーブルのキーとして使用されます。また、Service Broker では、送受信したメッセージを確実に保持する必要があるアプリケーションについては、メッセージ保有が用意されています。

多くのアプリケーションでは状態を保持する必要はありません。通常、タスクに複数のメッセージが関連していて、そのタスクに関する情報をデータベースの既存のテーブルに格納できない場合、アプリケーションでは状態を保持する必要があります。

たとえば、顧客情報を検索して返すアプリケーションでは状態を保持する必要がなく、このようなアプリケーションでは状態テーブルは使用しません。これに対し、受注処理を管理するアプリケーションでは、他の複数のサービスに対して要求を行います。他のサービスへの要求を調整するプログラムでは、要求を追跡するために状態テーブルを使用することがあります。すべての要求が正常に完了すると、アプリケーションでは、データ テーブルを更新し、状態テーブルのデータを消去します。要求でエラーが発生した場合は、要求を再送信するか、または状態テーブルを使用して補正要求を送信します。

また、アプリケーションでは、監査やログ記録の目的で状態テーブルを使用することがあります。アプリケーションでは、各要求についての重要な情報を状態テーブルに格納します。この場合、メッセージ交換が完了しても、情報は状態テーブルから削除されません。

メッセージ交換がアクティブな間、送受信したメッセージの正確な記録が必要なアプリケーションもあります。このような場合は、Service Broker により、メッセージの保有が提供されます。

参照

概念

Service Broker アプリケーションの概要

その他の技術情報

CREATE QUEUE (Transact-SQL)

ヘルプおよび情報

SQL Server 2005 の参考資料の入手