Pour un de mes modules DAL J'ai beaucoup de plomberie dupliquée en forme de:En utilisant PostSharp pour réessayer la méthode sur Exception
while (retry)
{
...
try
{
...do something
retry = false;
}
catch (SqlException sqlEx)
{
// Retry only if -2 = Connection Time Out or 1205 = Deadlock
if (sqlEx.Number == -2 || sqlEx.Number == 1205)
{
..retry if attempt < max
}
..log and rethrow exception
}
}
et avoir découvert PostSharp récemment, je suis tenté de remplacer ces codes de plomberie avec un attribut.
Mon plan initial était de: - étendre OnMethodInvocationAspect et rappelez-vous l'événement d'appel de méthode args lors de l'appel de la méthode - mettre en œuvre IOnExceptionAspect et mettre en œuvre OnException pour vérifier le type d'exception et si nouvelle tentative est nécessaire d'utiliser objet l'événement d'appel de méthode args de l'original appel, à savoir:
[Serializable]
public sealed class RetryAttribute : OnMethodInvocationAspect, IOnExceptionAspect
{
[NonSerialized]
private MethodInvocationEventArgs m_initialInvocationEventArgs = null;
public override void OnInvocation(MethodInvocationEventArgs eventArgs)
{
if (m_initialInvocationEventArgs == null)
m_initialInvocationEventArgs = eventArgs;
base.OnInvocation(eventArgs);
}
public void OnException(MethodExecutionEventArgs eventArgs)
{
// check if retry is necessary
m_initialInvocationEventArgs.Proceed();
}
}
mais la méthode de OnInvocation ne se déclenche plus une fois que je l'ai ajouté IOnExceptionAspect ..
est-ce que quelqu'un sait ce que je dois faire ici? Ou peut-être qu'il y a un aspect plus approprié que je devrais utiliser?
Merci,
La question que je voudrais poser est pourquoi êtes-vous ces exceptions (délai d'attente et impasse), et re-conception de l'application pour supprimer l'obligation de rattraper ces - lancer une autre technologie à l'application ne va pas améliorer le design \ implmentation – AwkwardCoder
Eh bien, oui, normalement vous ne devriez pas avoir d'interblocage. Une utilisation typique des tentatives est lorsque vous travaillez dans des transactions concurrentes optimistes. Donc, vous pouvez réessayer, mais je serais d'accord avec Ollie sur ce point. –
Les délais d'attente et les interblocages ne se produisent pas souvent dans notre environnement, mais nous avons tellement d'applications différentes (plus de 100 applications utilisées par des milliers d'utilisateurs dans le monde entier) utilisant le même DB et beaucoup frappent les mêmes tables simultanément. circonstances que nous avons eu des blocages/expirations dans le passé. – theburningmonk