Implementación de lógica de reintento para excepciones de punto muerto

Sé que este es un post antiguo, pero quería compartir una respuesta actualizada.

EF 6 ahora tiene una solución incorporada, puede establecer la estrategia de ejecución que sería una implementación de una sola vez. Se crea una clase que hereda de DbExectutionStrategy y anula el método virtual ShouldRetryOn. Puede crear una clase estática de las excepciones que contienen valores de campo constantes que son códigos elegibles para reintentar y recorrer cada uno para determinar si se genera la excepción sql actual coincide con la lista de códigos de reintento elegibles...

 public static class SqlRetryErrorCodes
{
    public const int TimeoutExpired = -2;
    public const int Deadlock = 1205;
    public const int CouldNotOpenConnection = 53;
    public const int TransportFail = 121;
}

public class MyCustomExecutionStrategy : DbExecutionStrategy
{
    public MyCustomExecutionStrategy(int maxRetryCount, TimeSpan maxDelay) : base(maxRetryCount, maxDelay) { }

     private readonly List<int> _errorCodesToRetry = new List<int>
    {
        SqlRetryErrorCodes.Deadlock,
        SqlRetryErrorCodes.TimeoutExpired,
        SqlRetryErrorCodes.CouldNotOpenConnection,
        SqlRetryErrorCodes.TransportFail
    };
    protected override bool ShouldRetryOn(Exception exception)
    {
        var sqlException = exception as SqlException;
        if (sqlException != null)
        {
            foreach (SqlError err in sqlException.Errors)
            {
                // Enumerate through all errors found in the exception.
                if (_errorCodesToRetry.Contains(err.Number))
                {
                    return true;
                }
            }
        }
        return false;
    }
}

Finalmente, una vez que haya configurado su estrategia de ejecución personalizada, simplemente cree otra clase que hereda de DbConfiguration con un constructor público que establece la estrategia de ejecución:

 public class MyEfConfigurations : DbConfiguration
    {
        public MyEfConfigurations()
        {
            SetExecutionStrategy("System.Data.SqlClient",() => new MyCustomExecutionStrategy(5,TimeSpan.FromSeconds(10)));
        }
    }

EntityFramework 6 añadir ExecutionStrategy característica. Todo lo que se necesita es configurar la estrategia correctamente.

Mi política de reintentos:

public class EFRetryPolicy : DbExecutionStrategy
{
    public EFRetryPolicy() : base()
    {
    }
    //Keep this constructor public too in case it is needed to change defaults of exponential back off algorithm.
    public EFRetryPolicy(int maxRetryCount, TimeSpan maxDelay): base(maxRetryCount, maxDelay)
    {
    }
    protected override bool ShouldRetryOn(Exception ex)
    {

        bool retry = false;

        SqlException sqlException = ex as SqlException;
        if (sqlException != null)
        {
            int[] errorsToRetry =
            {
                1205,  //Deadlock
                -2,    //Timeout
            };
            if (sqlException.Errors.Cast<SqlError>().Any(x => errorsToRetry.Contains(x.Number)))
            {
                retry = true;
            }

        }          
        return retry;
    }
}

Dile a EF que aplique mi estrategia:

public class EFPolicy: DbConfiguration
{
    public EFPolicy()
    {
        SetExecutionStrategy(
            "System.Data.SqlClient",
            () => new EFRetryPolicy());
    }
}

Fuentes:

• Implementación de resiliencia de conexión con Entity Framework 6
• Documentación de Microsoft

La estrategia de reintento no funcionará con transacciones iniciadas por el usuario (transacción creada con TransactionScope) como se explica aquí. Si se utiliza obtendrá el Error The configured execution strategy does not support user initiated transactions

¿Ha considerado alguna forma de inyección de pólizas? Podrías usar la interceptación de Unity, solo como ejemplo, para capturar todas tus llamadas al repositorio. A continuación, simplemente escriba la lógica de reintento una vez, en el interceptor, en lugar de repetirla muchas veces en cada método.

La solución funciona aunque prefiero no tener que preocuparme por el número de argumentos a los Action o Func que se retirarán. Si crea un único método de reintento con un Action genérico, puede manejar toda la variabilidad del método que se llamará en una lambda:

public static class RetryHelper
{

    public static void DeadlockRetryHelper(Action method, int maxRetries = 3)
    {
        var retryCount = 0;

        while (retryCount < maxRetries)
        {
            try
            {
                method();
                return;
            }
            catch (System.Data.SqlClient.SqlException ex)
            {
                if (ex.Number == 1205)// Deadlock           
                {
                    retryCount++;
                    if (retryCount >= maxRetries)
                        throw;
                    // Wait between 1 and 5 seconds
                    Thread.Sleep(new Random().Next(1000, 5000));
                }
                else
                    throw;
            }
        }

    }
}

Entonces úsalo así:

RetryHelper.DeadlockRetryHelper(() => CopyAndInsertFile(fileModel));