SqlDependency Reliablity?

Моя текущая ситуация заключается в том, что у меня есть приложение, которое необходимо уведомлять, когда новые данные поступают в таблицу базы данных. Данные поступают из внешнего источника (что я не контролирую - это единственный вариант интеграции). Когда поступают новые данные, моему приложению нужно предпринять определенные действия - в основном запрос для новых данных, обработать его, вставить результат в локальную таблицу и т.д.

Я хочу избежать опроса, если это возможно, поскольку данные, как ожидается, будут обрабатываться в режиме реального времени. Тем не менее, убедитесь, что данные никогда не пропущены - это приоритет №1.

Мои вопросы:

  • Насколько SqlDependency считается надежным?
  • Нужно ли беспокоиться о состоянии гонки, например? Я обращаюсь с одним изменением, когда приходит еще один человек?
  • Что происходит, когда база данных перезагружается? Будет ли мое приложение восстанавливаться и снова получать изменения, или мне понадобится таймер отказоустойчивости, который периодически будет повторно подписываться на уведомления?
  • Большинство статей, которые я прочитал по адресу address SQL Server 2005. Я использую SQL Server 2008 R2. Существует ли более новая технология, которая предпочтительнее, чем SqlDependency?
  • (Edit) Также, что, если приложение опустится? Думаю, мне нужно будет запросить пропущенные данные при запуске?

ОТВЕТЫ

Ответ 1

1) Да, я считаю это надежным, так как он правильно выполняет цель, предназначенную для выполнения (кэширование недействительности)

2) Нет. Вот почему вы можете подписаться только путем выдачи запроса, что гарантирует отсутствие расы между извлечением данных и новыми обновлениями, уведомляющими

3) Перезапуск базы данных (или экземпляра) сигнализирует все ожидающие уведомления о запросах с SqlNotificationInfo значением Restart. Узнайте, как SqlDependency и основывается на уведомлении о запросах для лучшего понимания. Поскольку SqlDependency постоянно поддерживает открытое соединение с базой данных, недоступность базы данных будет обнаружена SqlDependency еще до того, как будет обнаружено явное уведомление о запросе

4) Нет. Подробнее об этом далее...

5) Нет пропущенных данных. Уведомление о запросе (и, следовательно, SqlDependency) никогда не уведомляет вас о том, какие данные были изменены. Он только уведомляет вас о том, что он изменился. Вы всегда должны вернуться и прочитать все данные обратно посмотрите, что изменилось (и я верну вас к вопросу/ответ № 2). Недавно начатое приложение еще не запросило данные для начала, поэтому никаких изменений не сообщается. Только после того, как он первым запросил данные, он может получать уведомление.

Из описания вашей проблемы я не уверен, что вам нужны уведомления о запросах. Мне кажется, что вы хотите воздействовать на любые изменения, неважно, когда это произошло, , даже если ваше приложение не запускалось. Это, безусловно, не является аннулированием кэша, это отслеживание изменений. Поэтому вам необходимо развернуть технологию отслеживания изменений, например Изменить сбор данных или Изменить отслеживание, обе из которых Только SQL Server 2008 и более поздние версии (недоступны в SQL Server 2005). С SQL Server 2005 не редкость развернуть триггер и отправить сообщение Service Broker для обработки той же проблемы, которую вы пытаетесь обработать (обнаруживать изменения, реагировать на каждую строку новых данных).

Ответ 2

Прибывая на него с точки зрения разработчика .net, просто хочет использовать его для недействительности кэша, он стал настоящей болью и не полностью надежен.

Настройка и устранение неполадок были особенно болезненными, поэтому мы работаем нормально в одной среде, но затем она не работает в другой. Выяснить, почему было сложно и трудоемко.

Даже когда он работает, он не является полностью надежным. SQL Server может отбрасывать уведомления, если он находится под большой нагрузкой, и есть известные проблемы с его перезапуском, а уведомления не возобновляются: http://connect.microsoft.com/SQLServer/feedback/details/543921/sqldependency-incorrect-behaviour-after-sql-server-restarts.

Я бы избегал, если есть альтернативная технология, которая делает то, что вы хотите, и менее хлопотно.