Правильный ли подход к опросу базы данных?

Question

Я создаю службу WCF (CALLER) для Azure. Служба (CALLER) вызывает асинхронные методы другой сторонней службы (EXTN). Служба третьей стороны вызывает методы обратного вызова другой службы WCF (LISTNER), размещенной мной на Azure. CALLER введите данные службы в databsae со статусом = PENDING.

В службе обратного вызова (LISTNER) Я обновляю статус запроса как ЗАВЕРШЕНО/НЕИСПРАВНО в базе данных.

Но я хочу, чтобы CALLER был уведомлен о статусе, обновленном в SQL Azure db.

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

Есть ли другая лучшая/эффективная альтернатива этому подходу?

Answer 1

Не совсем. Существует другой способ (не уверен, что он работает на лазурном), используя интегрированную очередь запросов SQL (очередь на обновления через триггер), и ваш поток может непрерывно опросаться тогда (есть способ, чтобы прочитать WAIT для etnry в в очереди, поэтому вы выпускаете один, и он ждет), но кроме того ...

... нет, а не из базы данных.

У меня есть аналогичное приложение, и я обрабатываю его с помощью триггера NITATION. База данных (то есть уведомления отправляются из бизнес-логики, значения которых меняются).

Answer 2

Функции, которые вы ищете, реализованы в AppFabricservice bus.

Answer 3

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

Очереди, вероятно, являются наиболее эффективным способом отправки уведомлений - вот почему они были созданы в первую очередь. Шина обслуживания используется для создания полупостоянных соединений между различными службами, предоставляя гораздо больше возможностей, чем простая передача сообщений. Это делает его немного менее гибким, требует немного больше программирования. Его модель выставления счетов (плата за соединение SB) также отражает это. Вы не должны использовать много соединений SB.