Выберите один экземпляр веб-приложения для выполнения задачи, инициированной внешним событием?

Question

У меня есть приложение ASP.NET, работающее на нескольких веб-серверах IIS6, с базой данных базы данных SQL Server 2005.

мне нужно:

1. мониторинг базы данных для завершения внешнего события задания, а затем

2. имеют ровно один экземпляр веб-приложения представить некоторую информацию на веб-службы

Для (1) кажется, что SqlDependency будет лучшим подходом (или просто старым опросом). Каждый экземпляр веб-приложения регистрирует такую ​​зависимость при запуске. (Я не хочу настраивать экземпляр «master», потому что сбой этого экземпляра означает, что задача не будет выполняться, даже если доступны другие экземпляры. Таким образом, мой проект должен гарантировать, что если есть доступный экземпляр работа, то работа должна продолжаться.)

Для (2) Я думал о наличии какого-либо флага в базе данных, которые экземпляры веб-приложения пытаются обновить после получения уведомления SqlDependency в (1) , по следующей линии (очень упрощенно):

UPDATE StatusTable SET TaskStatus = 1 WHERE TaskStatus = 0 

SELECT @@ROWCOUNT 

идея заключается в том, что только один экземпляр приложения был бы в состоянии обновить TaskStatus, и, таким образом, только один экземпляр будет иметь @@ ROWCOUNT> 0. Этоn быть экземпляром «избранным» для отправки информации в веб-службу.

Каковы недостатки такого подхода? Каковы мои другие варианты? (Примечание: отдельный сервис, выполняющий эту работу, не является вариантом.)

Answer 1

Глобальный флаг «не работает», помните, что у вас есть несколько официантов и несколько уведомлений, вы не хотите, чтобы один «официант» 'забрать все извещения. Для надежной кирки «ровно один» задачи, использование UPDATE ВЫХОДА:

UPDATE TOP(1) StatusTable 
    SET Status = 1 
OUTPUT DELETED.TaskId 
WHERE Status = 0; 

Это рекомендуется, надежный, способ строки из из очереди таблиц, используемая в качестве очередей, см Очереди пункта в OUTPUT Clause.

Но теперь вы должны понимать, что: 1) вы используете таблицы как очереди; 2) вы получаете уведомления из этих очередей; 3) вы используете Service Broker для доставки этих уведомлений (через SqlDependency, который internally uses Service Broker). Так почему бы не использовать просто Service Broker? Вам нужны queue и service, и каждый экземпляр начинает WAITFOR(RECEIVE...) в этой очереди (не опрос). Задача, представляющая интерес, заканчивается с вашей службой SEND, сообщая, что работа завершена. Именно один из ваших экземпляров подберет это уведомление и продолжит постобработку (т. Е. Дозвонит вызов веб-службы). Таким образом вы отключите все флаги вокруг уведомлений (SqlDependency, глобальный флаг, таблицы, используемые в качестве очередей), и вы идете против инфраструктуры bare-bone, которая в любом случае будет использоваться SqlDependency.