Как я могу избежать тупиков с медленными запросами

Question

У меня есть служба WCF, которая иногда вызывает тупик базы данных. Мой сервис позволяет вам подавать заявки в совет, а также позволяет загружать их снова, потому что совет может их обновить. С каждым приложением связан ряд документов.

Так что если такие события происходят на моем сервисе

1) Application #1 is submitted
2) A document is uploaded for application #1
3) Application #1 is loaded
4) Part 2 above finishes

Тупик в части 3. Я полагаю, что причина в том, что документ в части 2 требует времени для отправки на сервер SQL из службы WCF, и в течение этого времени он блокирует таблицу.

Так что, если мы загружаем из базы данных приложение № 1 и связанные с ним документы, у нас возникают проблемы.

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

Кстати, это конкретная ошибка, которую я получаю,

Message: Transaction (Process ID 93) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

ОБНОВЛЕНИЕ: У меня было несколько комментариев, которые я мог изменить порядок операций. На самом деле я не могу этого сделать, потому что часть 2 и часть 3 относятся к разным вызовам службы WCF. Таким образом, пользователь сервиса должен заказывать операции. «Попросите их изменить это», говорите вы, но это не так просто. Порядок действий на самом деле зависит от того, как конечный пользователь «обновляет» свой браузер в нужный момент.

Обновление № 2: Мне нужен совет о том, как повторить эту проблему. Я написал тестовое приложение, и часть 2 выше блокирует операцию в части 3, но последствия для меня таковы, что операция 3 просто блокирует, пока операция 2 не будет завершена, а затем операция 3 завершится.

Таким образом, это означает, что часть 3 занимает 1 минуту 50 секунд вместо 3, как обычно. Любые идеи, почему это будет блокировать для меня, а не создавать тупик? Может ли это быть связано с общим объемом трафика базы данных на этом сервере, если я использую тестовый сервер, или некоторые параметры базы данных могут повлиять на него?

Answer 1

Пара решений:

• Используйте уровень изоляции READ UNCOMMITTED, если вы не возражаете против того, чтобы на шаге 3 появлялись незафиксированные строки (это зависит от вашей ситуации).

ИЛИ

• Пакетно вносите изменения в свой контекст EF более эффективно и убедитесь, что они выполняются сразу (не видя ваш код, я не уверен, делаете ли вы это или нет)

РЕДАКТИРОВАТЬ

Ссылка ниже также может быть полезна при устранении неполадок и решении вашей проблемы:

http://blogs.msdn.com/b/bartd/archive/2006/09/09/deadlock-troubleshooting_2c00_-part-1.aspx

Answer 2

Существует несколько способов избежать взаимных блокировок (SQL Server и другие базы данных):

1) Вызовите saveChanges() только в конце транзакции, чтобы выполнить все запросы вместе.

2) Измените порядок выполнения обновления базы данных, сначала выполните все операции чтения (SELECT), а затем выполните все обновления.

3) Выполните считывание из транзакции данных, которые не были бы изменены в транзакции.

4) Измените уровень изоляции транзакции на SERIALIZABLE (низкая производительность) или SNAPSHOT или другое промежуточное соединение без блокировки, как READ UNCOMMITTED, если логика приложения позволяет.

5) Создайте синхронизированные кодовые блоки с помощью lock(lock_object), чтобы избежать двух потоков, выполняющих одну и ту же транзакцию параллельно, или двух разных транзакций, которые блокируют себя.