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

Question

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

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

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

Answer 1

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

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

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

РЕДАКТИРОВАТЬ: Ах, научи меня не использовать Google! Предыдущий пример кода, который я и другие дали, находится на Как получить эффективную обработку взаимоблокировок Sql Server в C # с ADO?

Answer 2

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

Randy