Как получить эффективную обработку взаимоблокировок Sql Server на С# с помощью ADO?

Во-первых, я бы просмотрел свой код SQL 2000 и докопался до сути, почему возникает этот тупик. Исправление этого может скрыть более серьезную проблему (например, отсутствующий индекс или неверный запрос).

Во-вторых, я бы пересмотрел свою архитектуру, чтобы подтвердить, что оператор взаимоблокировки действительно нужно вызывать так часто (должен ли select count(*) from bob вызываться 100 раз в секунду?).

Однако, если вам действительно нужна поддержка взаимоблокировок и у вас нет ошибок в SQL или архитектуре, попробуйте что-нибудь из следующего. (Примечание: мне приходилось использовать эту технику для системы, поддерживающей тысячи запросов в секунду, и довольно редко возникали тупиковые ситуации)

int retryCount = 3;
bool success = false;  
while (retryCount > 0 && !success) 
{
  try
  {
     // your sql here
     success = true; 
  } 
  catch (SqlException exception)
  {
     if (exception.Number != 1205)
     {
       // a sql exception that is not a deadlock 
       throw; 
     }
     // Add delay here if you wish. 
     retryCount--; 
     if (retryCount == 0) throw;
  }
}

Основываясь на ответе @Sam, я представляю метод оболочки повторной попытки общего назначения:

private static T Retry<T>(Func<T> func)
{
    int count = 3;
    TimeSpan delay = TimeSpan.FromSeconds(5);
    while (true)
    {
        try
        {
            return func();
        }
        catch(SqlException e)
        {
            --count;
            if (count <= 0) throw;

            if (e.Number == 1205)
                _log.Debug("Deadlock, retrying", e);
            else if (e.Number == -2)
                _log.Debug("Timeout, retrying", e);
            else
                throw;

            Thread.Sleep(delay);
        }
    }
}

private static void Retry(Action action)
{
    Retry(() => { action(); return true; });
}

// Example usage
protected static void Execute(string connectionString, string commandString)
{
    _log.DebugFormat("SQL Execute \"{0}\" on {1}", commandString, connectionString);

    Retry(() => {
        using (SqlConnection connection = new SqlConnection(connectionString))
        using (SqlCommand command = new SqlCommand(commandString, connection))
            command.ExecuteNonQuery();
    });
}

protected static T GetValue<T>(string connectionString, string commandString)
{
    _log.DebugFormat("SQL Scalar Query \"{0}\" on {1}", commandString, connectionString);

    return Retry(() => { 
        using (SqlConnection connection = new SqlConnection(connectionString))
        using (SqlCommand command = new SqlCommand(commandString, connection))
        {
            object value = command.ExecuteScalar();
            if (value is DBNull) return default(T);
            return (T) value;
        }
    });
}

Если тупиковая ситуация может быть разрешена на уровне данных, это определенно правильный путь. Блокировка подсказок, переработка работы модуля и так далее. Однако NoLock не является панацеей - иногда его невозможно использовать по причинам целостности транзакций, и у меня были случаи прямого (хотя и сложного) чтения данных со всеми соответствующими таблицами NoLock, которые по-прежнему вызывали блокировки других запросов.

В любом случае - если вы не можете решить это на уровне данных по какой-либо причине, как насчет

bool OK = false;
Random Rnd = new Random();

while(!OK)
{
    try
    {
        rows = Command.ExecuteNonQuery();
        OK = true;
    }
    catch(Exception exDead)
    {
        if(exDead.Message.ToLower().Contains("deadlock"))
            System.Threading.Thread.Sleep(Rnd.Next(1000, 5000));
        else
            throw exDead;
    }
}

Если у вас возникают проблемы с взаимоблокировками, лучше посмотреть, что делает код SQL. Например, взаимные блокировки эскалации блокировок очень легко создать, если у вас есть сериализуемый уровень изоляции (или любой эквивалент в вашей rdbms) — и их можно смягчить несколькими способами, такими как изменение порядка запросов или (в SQL Server по крайней мере) используя (UPDLOCK) для блокировки записи раньше (чтобы вы не получили конкурирующую блокировку чтения).

Повторная попытка будет смешанной... например, если вы находитесь в TransactionScope, она уже может быть прервана. Но только на пуристском уровне - если у меня возникнут проблемы с общением с БД, я хочу, чтобы мой код паниковал, и паниковал рано... повторная попытка кажется немного хакерской в ​​этом конкретном сценарии.