SqlDependency信頼性？
私の現在の状況では、新しいデータがデータベーステーブルに到着したときに通知を受け取る必要があるアプリケーションがあります。データは外部ソースからのものです（私は制御できません-これは唯一の統合オプションです）。新しいデータが到着すると、アプリケーションは特定のアクションを実行する必要があります。基本的には、新しいデータのクエリ、データの処理、ローカルテーブルへの結果の挿入などです。
データはリアルタイムで処理されることが期待されているため、できればポーリングを避けたいと思います。とはいえ、失われるデータがないことを確認することが最優先事項です。
私の質問：
- SqlDependencyは一般に信頼できると考えられていますか？
- 競合状態について心配する必要がありますか？別の到着時に変更を処理していますか？
- データベースが再起動するとどうなりますか？アプリは回復して変更の受信を再開しますか、それとも定期的に通知を再サブスクライブする何らかのフェイルセーフタイマーが必要ですか？
- 私がトピックで読んだほとんどの記事は、SQL Server 2005に対応しています。SQLServer 2008 R2を使用しています。 SqlDependencyよりも優先される新しい手法はありますか？
- （編集）また、アプリケーションがダウンした場合はどうなりますか？起動時に失われたデータを照会する必要があると思いますか？
1）はい、目的は正しく設計されています（キャッシュの無効化）
2）いいえ。これは、クエリを発行することによってのみサブスクライブできる理由です。これにより、データのフェッチと新しい更新の通知の間に競合がないことが保証されます。
3）データベース（またはインスタンス）の再起動は、保留中のすべてのクエリ通知に SqlNotificationInfo 値Restartを通知します。よりよく理解するために、どのように SqlDependency and is based on Query Notification を読んでください。 SqlDependencyは常にデータベースへのオープン接続を維持するため、明示的なクエリ通知の前であっても、データベースの使用不可はSqlDependencyによって検出されます
4）いいえ。これについては、さらに詳しく...
5）「欠落データ」はありません。クエリ通知（したがってSqlDependency）は、変更されたデータについて通知することはありません。 それが変更されたことを通知するだけです。あなたはいつも戻ってallデータを読んで何が変更されたかを確認することになっています（そして、質問/回答2を参照します）。新しく開始されたアプリケーションは、最初にデータをまだ照会していないため、通知される変更はありません。 後で最初にデータを照会した後でのみ、通知を受け取ることができます。
問題の説明から、クエリ通知が必要だとは思いません。変更がいつ発生したかは関係なく、何らかの変更に対応したいようですアプリケーションが実行されていなくても。これは確かにキャッシュの無効化ではなく、変更の追跡です。したがって、 （Change Data Capture または Change Tracking などの変更追跡テクノロジを展開する必要があります。どちらもSQL Server 2008以降のみです（SQL Server 2005では使用できません）。 。 SQL Server 2005では、トリガーを展開してメッセージをキューに入れることは珍しくありません Service Broker が処理しようとしているのと同じ問題を処理します（変更を検出し、新しいデータの各行に反応します）。
.net開発者の観点から、それをキャッシュ無効化に使用したいだけだと考えると、本当に苦痛であり、完全に信頼できるわけではありません。
セットアップとトラブルシューティングは特に苦痛でした。ある環境では問題なく機能しましたが、別の環境では機能しません。なぜ困難で時間がかかるのかを理解する。
すべてが実行されている場合でも、完全に信頼できるわけではありません。 SQL Serverは、高負荷で再起動および通知が再開されないという既知の問題がある場合、通知をドロップできます。 http://connect.Microsoft.com/SQLServer/feedback/details/543921/sqldependency-incorrect-behaviour -after-sql-server-restarts 。
あなたがやりたいことをする代わりの技術があり、面倒が少ないなら、私は避けます。