La mise en œuvre de logique de nouvelle tentative de blocage des exceptions

J'ai mis en place un référentiel générique et je me demandais si il n'y est une façon intelligente de mettre en œuvre une logique de nouvelle tentative en cas d'impasse exception?

La démarche doit être la même pour tous référentiel de méthodes. Donc, il y a de toute façon je peux éviter d'écrire 'try/catch - méthode call de nouveau avec retry-comte", dans chaque méthode unique?

Tout suggetsion sont les bienvenus.

Un peu de mon code de Référentiel:

public class GenericRepository : IRepository
{
    private ObjectContext _context;

    public List<TEntity> ExecuteStoreQuery<TEntity>(string commandText, params object[] parameters) where TEntity : class
    {
        List<TEntity> myList = new List<TEntity>();

        var groupData = _context.ExecuteStoreQuery<TEntity>(commandText, parameters);

        return myList;
    }


    public IQueryable<TEntity> GetQuery<TEntity>() where TEntity : class
    {          
        var entityName = GetEntityName<TEntity>();
        return _context.CreateQuery<TEntity>(entityName);
    }

    public IEnumerable<TEntity> GetAll<TEntity>() where TEntity : class
    {
        return GetQuery<TEntity>().AsEnumerable();
    }

EDIT:

1.Solution:

Légèrement modifié à partir de chris.maison.00's solution

 public static T DeadlockRetryHelper<T>(Func<T> repositoryMethod, int maxRetries)
    {
        var retryCount = 0;

        while (retryCount < maxRetries)
        {
            try
            {
                return repositoryMethod();
            }
            catch (System.Data.SqlClient.SqlException ex)
            {
                if (ex.Number == 1205)//Deadlock                         
                    retryCount++;
                else
                    throw;                   
            }
        }
        return default(T);
    }

Et vous l'appeler comme ceci:

    public TEntity FirstOrDefault<TEntity>(Expression<Func<TEntity, bool>> predicate) where TEntity : class
    {
        return RetryUtility.DeadlockRetryHelper<TEntity>( () =>p_FirstOrDefault<TEntity>(predicate), 3);
    }

    protected TEntity p_FirstOrDefault<TEntity>(Expression<Func<TEntity, bool>> predicate) where TEntity : class
    {
        return GetQuery<TEntity>().FirstOrDefault<TEntity>(predicate);
    }

Quoi de mal avec une instruction try?
Je pense que l'OP veut éviter de répéter les blocs try...catch dans chaque pensions de méthode.
Assurer votre référentiel peut gérer les tentatives de blocage pourrait être difficile. Même si vous consolidez les appels vers le référentiel, chaque respository fonction devra encore être testé.

InformationsquelleAutor user1638662 | 2012-10-31

c#database-deadlocks entity-framework repository-pattern try-catch

34

Comment quelque chose comme cela:
```
public T DeadlockRetryHelper<T>(Func<T> repositoryMethod, int maxRetries)
{
  int retryCount = 0;

  while (retryCount < maxRetries)
  {
    try
    {
      return repositoryMethod();
    }
    catch (SqlException e) //This example is for SQL Server, change the exception type/logic if you're using another DBMS
    {
      if (e.Number == 1205)  //SQL Server error code for deadlock
      {
        retryCount++;
      }
      else
      {
        throw;  //Not a deadlock so throw the exception
      }
      //Add some code to do whatever you want with the exception once you've exceeded the max. retries
    }
  }
}
```
Avec le code ci-dessus, votre logique de nouvelle tentative est tous dans cette méthode et vous pouvez passer votre référentiel de la méthode en tant que délégué.
- Attention à attraper le blocage des exceptions. Sinon, vous pouvez peut-être simplement de répéter une erreur ou, pire, la même fonction avec les mêmes effets secondaires à plusieurs reprises.
- L'OP ne spécifiez pas ce SGBD ou ORM, il l'utilise j'ai donc choisi de ne pas faire des hypothèses sur la façon dont il venait de détecter un blocage. Cela étant dit, vous soulevez un bon point donc j'ai édité pour que l'exemple spécifique à SQL Server/ADO.Net donner le code de la clarté.
- A été quelque chose comme cela, je faisais des expériences avec. Modifié la vôtre un peu au cas ou quelqu'un voudrais ré-utiliser pour les blocages 🙂
- Si vous avez épuisé vos tentatives, alors la fonction retourne sans lancer une exception.
- Yup, c'est sûr qu'il n'. Voir le commentaire dans le code que les etats de cette. Depuis l'OP n'a pas d'état exactement ce genre de comportement qu'il voulait, j'ai ajouté le commentaire, il est clair que si certains comportement désiré lorsque max tentatives de dépassement, le code doit être ajouté à ce point.
- votre code est fragile parce que la repositoryMethod() ne peut fonctionner qu'en son propre code sql de la transaction, mais l'utilisation de la transaction en tant que paramètre à la fermeture. Et dans ce cas, vous devriez réessayer l'ensemble de la pile des appels.
- Vous devriez faire une brève pause entre les tentatives de donner le lock-titulaire le temps de libérer ses écluses. Vous devriez aussi faire une pause pour un intervalle aléatoire pour éviter mutuelle des blocages de réessayer en même temps et de blocage nouveau.
- Avec C# 6 catch (SqlException ex) when (ex.Number == 1205)
InformationsquelleAutor chris.house.00

Je sais que c'est un vieux post, mais je voulais partager une mise à jour de réponse.

EF 6 a maintenant une solution intégrée, vous pouvez définir la stratégie d'exécution qui serait un temps de mise en œuvre. Vous créez une classe qui hérite de DbExectutionStrategy et remplace la ShouldRetryOn méthode virtuelle. Vous pouvez créer une classe statique des exceptions contenant champ constant valuess qui sont réessayer admissibles codes et boucle à travers chacun de déterminer si le cours de sql exception levée correspond à la liste des admissibles réessayer codes...

 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;
    }
}

Enfin, une fois, vous avez mis en place votre personnalisé de l'exécution de la stratégie, il vous suffit de créer une autre classe qui hérite de DbConfiguration avec un constructeur public qui Définit la stratégie d'exécution:

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

InformationsquelleAutor CodeAlchemist

EntityFramework 6 ajouter ExecutionStrategy fonctionnalité. Tout ce qui est nécessaire est de configurer correctement la stratégie.

Mon réessayer politique:

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;
    }
}

Dire EF pour appliquer ma stratégie:

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

Sources:

Les tentatives de stratégie ne fonctionnera pas avec initiées par l'utilisateur des transactions (transaction créé avec TransactionScope) comme expliqué ici. Si elle est utilisée, vous obtiendrez l'Erreur The configured execution strategy does not support user initiated transactions

InformationsquelleAutor MiguelSlv

1

Avez-vous considéré comme une certaine forme de politique de l'injection? Vous pouvez utiliser l'Unité d'interception, par exemple, pour capturer tous vos référentiel des appels. Ensuite, il vous suffit d'écrire la logique de nouvelle tentative une fois, dans l'intercepteur, plutôt que de répéter plusieurs fois dans chaque méthode.
- Sonne comme ce que je suis en train de regarder en avant. Avez-vous un exemple ou un lien vers similaires utiliser?
InformationsquelleAutor Sean H

La solution fonctionne mais je préfère ne pas avoir à vous soucier du nombre d'arguments de la Action ou Func qui seront à la retraite. Si vous créez une nouvelle tentative de la méthode avec un générique Action, vous pouvez gérer l'ensemble de la variabilité de la méthode à appeler dans un 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;
            }
        }

    }
}

De l'utiliser ensuite comme suit:

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

InformationsquelleAutor Josh Russo

Vous devez vous connecter pour publier un commentaire.