通知の取得
多くのアプリケーションでは、専用のコードを用意することなくクエリ通知を受信および処理できます。通知サブスクリプションが SqlDependency オブジェクトによって管理される場合、このオブジェクトは自動的にサブスクリプションを監視します。通知メッセージが到着すると、SqlDependency オブジェクトは SqlDependency オブジェクトに登録されているイベント ハンドラを呼び出します。この方法では、通知を受信するために特別な作業は必要ありません。SqlDependency を使用するアプリケーションは、通知メッセージを受信または処理する必要はありません。
逆に、アプリケーションが通知要求を使用する場合は、アプリケーション自体がキューを監視し、通知メッセージに対処する必要があります。この場合、通知を受信するサービス用に、メッセージを処理するアプリケーションを作成します。通知を要求するアプリケーションとメッセージを処理するアプリケーションを同じにすることも、クエリ通知メッセージを受信し対処するアプリケーションを別に作成することもできます。
SQL Server は、実際に実行されたクエリと通知 ID を組み合わせて使用することで通知サブスクリプションを追跡します。アプリケーションが同じ通知 ID を使用して 2 つの異なるクエリの通知を要求した場合、SQL Server は同じ通知 ID で 2 つのサブスクリプションを作成します。ただし、アプリケーションが同じ通知 ID を 2 回使用して同じクエリに対する通知を要求した場合、SQL Server は 2 回目の要求で指定されているタイムアウトを使ってサブスクリプションを 1 つだけ作成します。
データベースで実行されるアプリケーションは、通常、メッセージが到着した時点でキューによってアクティブ化されるストアド プロシージャです。これらのストアド プロシージャは、Transact-SQL または .NET がサポートする言語のいずれかを使用して作成できます。この方法に比べると一般的ではありませんが、アプリケーションを定期ジョブとして実行する方法や、ストアド プロシージャをバックグラウンドで常時実行するスタートアップ タスクを使用する方法もあります。
データベース外で実行されるアプリケーションは、通常、次のいずれかの方法でメッセージを受信します。
- アプリケーションから定期的にキューをポーリングし、メッセージが到着しているかどうかを確認する。
- アプリケーションで RECEIVE ステートメントの WAITFOR 句を使用して、ステートメントから少なくとも 1 行が返されるまでは RECEIVE ステートメントのバッチまたはストアド プロシージャを実行しないようにする。
- アプリケーションが通知を受け取るキューに QUEUE_ACTIVATION イベントのイベント通知を作成する。その後、アプリケーションは上記 2 つの方法のうちいずれかを使用して、アクティベーション イベントを受け取るサービスを監視します。
これらの方法に比べると一般的ではありませんが、WMI を使用してキューのアクティベーションを監視する方法や、メッセージに応じてなんらかの外部操作を実行する CLR (共通言語ランタイム) ストアド プロシージャを作成する方法もあります。
クエリ通知のメッセージ交換には、常に通知メッセージが 1 つ含まれるので、クエリ通知を処理するアプリケーションは、メッセージを受け取ったらそのメッセージ交換を終了させる必要があります。そうしないと、このメッセージ交換はいずれタイムアウトします。クエリ通知のメッセージ交換がタイムアウトした場合、SQL Server は SQL Server エラー ログにメッセージ交換のタイムアウト エラーを記録します。
Service Broker を使用するアプリケーションの作成方法の詳細については、「Service Broker のプログラミングの概要」を参照してください。Service Broker を使用するアプリケーションの起動方法の詳細については、「起動方法の選択」を参照してください。