Шаблоны для обработки SQL-тупика в С#?

Я пишу приложение на С#, которое обращается к базе данных SQL Server 2005. Приложение довольно интенсивно для базы данных, и даже если я попытаюсь оптимизировать весь доступ, настройте правильные индексы и т.д. Я ожидаю, что рано или поздно я получу тупики. Я знаю, почему происходят взаимоблокировки базы данных, но я сомневаюсь, что смогу выпустить программное обеспечение без взаимоблокировок, возникающих в какой-то момент. Приложение использует Entity Framework для доступа к базе данных.

Есть ли хороший шаблон для обработки SQLExceptions (deadlocked) в коде клиента С#, например, для повторного запуска пакета операторов после x миллисекунд?

Прояснить; Я не ищу способ, как избежать блокировок в первую очередь (уровни изоляции, индексы, порядок инструкций и т.д.), А скорее как обрабатывать их, когда они на самом деле происходят.

Ответ 1

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

Короткий ответ - оберните вещь в try..catch. Если вы поймаете ошибку, которая выглядит как тупик, засыпайте за короткое случайное время и увеличивайте счетчик. Если вы получите еще одну ошибку или счетчик повторов очистит свой порог, отбросьте ошибку до вызывающей процедуры.

(И если вы можете, попробуйте обмануть это в общей рутине и запустите весь/весь ваш доступ к БД через него, чтобы вы обрабатывали взаимоблокировки по всей программе.)

EDIT: Ах, научи меня не использовать Google! Предыдущий пример кода я и других дал в Как получить эффективную обработку блокировки сервера Sql в С# с помощью ADO?

Ответ 2

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

Ренди