SqlDependency потеряла подписку со временем

Я использую SqlDependency в приложении .NET 3.5 более 3 лет без каких-либо проблем. Сценарий выглядит следующим образом:

  • Служба центральных окон с SqlDependency просмотра таблицы (позвоните в эту таблицу A)
  • Несколько пользователей, использующих приложение WPF с уникальным SqlDependency для пользователя, просматривающего таблицу (таблица A еще раз)
  • Пользователь ставит в очередь единицу работы для обработки в таблице A
  • SqlDependency срабатывает служба Windows
  • Служба Windows обрабатывает все выдающиеся элементы в таблице A и сохраняет результаты в таблице A
  • Уникальный SqlDependency запускается для каждого пользователя, результаты которого доступны
  • Пользователь обрабатывает свою работу.

Недавно я обновил систему до .NET 4.5 и начал видеть проблемы, в которые будут внесены изменения в таблицу, которую мы отслеживаем, но SqlDependency никогда не будет срабатывать (как в сервисе, так и в пользовательском приложении). Я начал копаться в этом дальше и заметил в своих журналах, что в какой-то момент я перерегистрирую SqlDependency, но затем уведомление будет никогда не стреляйте после этого.

После просмотра этого поведения я решил запустить профилировщик на SQL-сервере для захвата событий подписки. Из данных, которые были захвачены, я заметил, что иногда подписка будет регистрироваться (с уникальным идентификатором) одним пользователем, но затем она будет запущена (с тем же уникальным идентификатором) другим пользователем. Обычно это происходит со службой, о которой я упоминал выше, и одним или несколькими пользователями приложения WPF. (Я прикрепил скриншот проблемы в результатах профилировщика)

Является ли это ожидаемым поведением? Что уведомление может быть запущено для другого пользователя, чем оно было зарегистрировано? Означает ли это проблему на уровне приложения? Любая помощь приветствуется.

Profiler Results

Ответы

Ответ 1

Поскольку создаются множественные экземпляры SqlDependency, я бы проверил для Duplicate Subscriptions, как описано здесь. Подписки могут считаться дублирующими в зависимости от вашей конфигурации. Поведение "означает, что, если уведомление запрашивается для идентичных запросов, отправляется только одно уведомление."

Еще одна вещь, которую нужно проверить, - это то, действительно ли событие OnChange может работать, но не появляется из-за того, что оно срабатывает в другом потоке. Многопоточный характер SqlDependency отмечен здесь.

Трассировка Profiler указывает, что Service Broker выполняет свою работу. Добавление дополнительной трассировки в .NET-уровнях показало бы, если подписка активируется на уровне базы данных, но не приводит к запуску события OnChange. Дополнительные советы по устранению неполадок можно найти здесь.