Лучший вариант для обновлений статуса очереди. NET

Question

Я ищу информацию о наилучшем варианте проблемы, над которой я работаю.

Чтобы дать вам некоторый фон, я недавно унаследовал разбитое бизнес-приложение (наш проект использовал его, поэтому мы получили ответственность за его устранение). Я исхожу из фона разработки SharePoint, поэтому немного C#, ASP.NET и SQL.

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

Без полного ремонта этого приложения я решил, что наш лучший вариант - разгрузить эти хранимые процедуры для работы в фоновом режиме и не привязываться к пользовательскому интерфейсу. Я рассмотрел несколько вариантов, в том числе:

• Создание отдельного потока для обработки исполнения. (Still times out)
• Использование BackgroundWorker (по-прежнему не работает, очевидно, это не должно, но я не могу понять, что вызывает его дождитесь завершения BackgroundWorker)
• Перемещение выполнения хранимой процедуры на задание, которое я затем вызываю из другого SP. (Это работает, но ограничение заключается в том, что я могу выполнить только одно задание сразу, и если несколько пользователей обновляют объекты, они получают исключение, потому что задание не запускается)

Сейчас мы переместили эти хранимые процедуры в сценарий два раза в день, который обновляет все объекты, однако это лишь временное исправление.

У меня есть два варианта, которые я смотрю, и я надеюсь получить некоторые рекомендации по реализации того, что вы считаете лучшим вариантом:

• Продолжайте использовать эту работу и иметь исполняемые хранимые процедуры обрабатывают объекты в db, которые задание будет проходить до пустого. Выполняемый хранимый proc должен будет проверить, выполняется ли задание, когда оно добавляет новую запись, а затем действует соответствующим образом.

• Было рекомендовано, чтобы я взглянул на использование Service Broker, но я не знаком с его использованием вообще. Я понимаю, что это, скорее всего, будет лучшим общим решением, поскольку оно позволяет мне ставить в очередь эти обновления более транзакционным способом.

Я думаю, что оба эти варианта жизнеспособны, хотя мне нужна помощь в понимании реализации второго варианта. Моя другая проблема заключается в том, что эти хранимые процедуры работают от 45 до 20 м, как я могу уведомить пользователя, который изменил объект, который был сделан его/ее обновлениями? Здесь я отказываюсь от использования задания, потому что я могу просто добавить поле пользователя в «очередь» и сохранить в конце хранимую процедуру отправки быстрого письма.

Мысли, предложения? Может, я передумал?

Answer 1

Если вы используете .NET 4.5 и C# 5.0, используйте async, и если вы используете .NET 4.0, используйте TPL. У них есть одна и та же базовая (почти), а асинхронная функция построена на TPL (с некоторыми дополнительными внутренними элементами).

В любом случае TPL будет правильным выбором.

Answer 2

Похоже, что Service Broker будет отличным решением этой проблемы. Это правда, что есть немного кривой обучения, чтобы подняться, чтобы разгадать, как это работает, но это принципиально довольно просто, особенно когда ваша реализация находится в одной базе данных.

Там хорошая (и милосердно короткая) интро, как она работает на http://msdn.microsoft.com/en-US/library/ms345108(v=SQL.90).aspx

Answer 3

Посмотрите Asynchronous Procedure Execution. Но сначала я бы посмотрел, если обновления могут быть улучшены, возможно, простой индекс может устранить таймауты и/или попытаться использовать snapshot isolation. Это было бы намного проще пробовать, если бы не «капитальный ремонт» кода приложения.

Я также должен настоятельно просить вас прочитать Waits and Queues. Это методология SQL Server для определения узких мест производительности. Является отличным способом сужения проблем «тайм-аутов» на что-то более действенное (блокирование, ввод-вывод, индексы и т. Д.).