Параметры регулирования службы WCF для параллелизма с транзакцией SQL - PullRequest
Новая
       20

Параметры регулирования службы WCF для параллелизма с транзакцией SQL

0 голосов
/ 18 мая 2011

У меня есть служба WCF со сложным контрактом операции, который должен выполняться атомарно, т. Е. Либо вся операция завершается успешно, либо не выполняется. Служба WCF размещается на сервере IIS в приложении ASP .NET . Эта операция имеет последовательность команд SQL, которые выполняются в транзакции. Во время тестов я обнаружил, что при одновременном доступе от 4 до 5 пользователей, по крайней мере, один пользователь получает ошибку «тупик транзакции».

Затем я посмотрел на настройки serviceThrottling , которые я установил на 

<serviceThrottling  maxConcurrentCalls ="5" maxConcurrentInstances ="50" maxConcurrentSessions ="5" />

и изменил его на 

<serviceThrottling  maxConcurrentCalls ="1" maxConcurrentInstances ="1" maxConcurrentSessions ="1" />

Я отключил сеанс, поскольку мне не нужен контракт на обслуживание. Так что я не знаю, будет ли maxConcurrentSessions иметь какой-либо эффект 

<ServiceContract([Namespace]:="http://www.8343kf393.com", SessionMode:=SessionMode.NotAllowed)>

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

Мне было интересно

  1. Является ли serviceThrottling единственным способом решения этой проблемы?

  2. Как настроить serviceThrottling таким образом, чтобы служба одновременно принимала много запросов, но обрабатывала по одному?

  3. Уместно ли здесь задавать InstanceContextMode = InstancePerContext.PerCall , поскольку приложение является приложением ASP .Net, которое само по себе является многопоточным?

Ответы [ 2 ]

3 голосов
/ 18 мая 2011
  1. Что ж, я думаю, что вы поступили неправильно, пытаясь решить тупик базы данных с помощью регулирования WCF.Вы должны попытаться понять, почему операции с вашей базой данных вызывают взаимоблокировку, и попытаться ее избежать (используя, возможно, подсказки блокировки).
  2. синглтон будет делать то, что вы просите, но это не очень масштабируемо.
  3. это уместно, но я думаю, что вы понимаете, что нужно, устраните тупик в базе данных, а не в WCF.

, если используемый вами SQL-сервер является отличным инструментом дляанализировать тупики (и многое другое), и его называют SQL Profiler.Также это довольно хорошо задокументированная тема в SQL Books Online

0 голосов
/ 18 мая 2011

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

Я бы рекомендовал использовать другой подход, чтобы убрать штраф за блокировку клиента. Вы должны рассмотреть возможность создания этой службы или, по крайней мере, извлечения этой операции в новую службу, которая использует netMsmqBinding (хороший обзор здесь) . Это означает, что клиент никогда не будет заблокирован, и это гарантирует доставку запроса в сервис. Компромисс в том, что немедленного ответа на запрос не может быть, вам нужно будет добавить еще одну операцию, чтобы узнать статус завершения и получить ожидаемые результаты. Чтобы ускорить работу службы на основе MSMQ, требуется больше работы, но надежность обычно стоит усилий.

...