Action d’exception verrouillée de l’instance

La InstanceLockedExceptionAction propriété du magasin d’instances de workflow SQL vous permet de spécifier l’action que le fournisseur de persistance SQL doit prendre lorsqu’il reçoit un InstanceLockedException. Le fournisseur de persistance reçoit cette exception lorsqu’il tente de verrouiller une instance de service de workflow actuellement verrouillée par un autre hôte de service. Les valeurs de cette propriété sont NoRetry, BasicRetryet AggressiveRetry. La valeur par défaut est NoRetry. La liste suivante décrit les trois options suivantes :

• NoRetry. L’hôte de service ne tente pas de verrouiller l’instance de service de workflow et passe l’appelant InstanceLockedException . Si votre flux de travail reste en mémoire pendant une période supérieure à 60 secondes, utilisez-le NoRetry comme nouvelle tentative. La valeur par défaut est NoRetry.

• BasicRetry. L’hôte de service réattempte pour verrouiller l’instance du service de flux de travail avec un intervalle linéaire entre les tentatives de nouvelle tentative et passe l’appelant InstanceLockedException à la fin de la séquence. Si vous flux de travail reste en mémoire environ entre 5 et 60 secondes, et que les messages arrivent par lots, où il est plus probable que les messages envoyés à la même instance sur le même hôte traitent tous les messages avant de décharger le flux de travail, utilisez BasicRetry pour obtenir la meilleure latence sans perdre de ressources.

• AggressiveRetry. L’hôte de service réattempte pour verrouiller l’instance de service de workflow avec un intervalle d’interruption exponentiel entre les tentatives de nouvelle tentative et transmet l’exception à l’appelant à la fin de la séquence. Si votre flux de travail reste en mémoire pendant une durée très courte (moins de 5 secondes), ou si une batterie de serveurs Web est volumineuse et que le risque d’une autre remise d’un autre message au même hôte n’est pas très élevé, utilisez cette option AggressiveRetry pour obtenir la meilleure latence.

La fonctionnalité Action d’exception verrouillée d’instance prend en charge les scénarios suivants. Dans tous les scénarios, si la propriété instanceLockedExceptionAction de SqlWorkflowInstanceStore est définie BasicRetry ou AggressiveRetryque l’hôte tente de manière transparente d’acquérir le verrou sur les instances régulièrement.

1. Activation de l’arrêt normal et du recyclage superposé des domaines d’application. Supposons qu’un AppDomain avec un hôte de service exécutant des instances de service de flux de travail soit recyclé et qu’un nouveau AppDomain soit mis en place pour gérer de nouvelles requêtes en parallèle tandis que l’ancien AppDomain est mis hors service correctement. L’arrêt attend que les instances de service de workflow soient inactives, puis conserve et décharge les instances. Toutes les tentatives effectuées par les hôtes dans le nouveau AppDomain pour verrouiller une instance entraînent un InstanceLockedException.

2. Mise à l’échelle horizontale des flux de travail durables sur une batterie homogène de serveurs. Supposons qu’un nœud d’une batterie de serveurs sur laquelle une instance de workflow s’exécute se bloque et que l’hôte de workflow ne peut pas supprimer les verrous sur l’instance qu’il exécute. Lorsqu’un hôte de service s’exécutant sur un autre nœud de la batterie de serveurs reçoit un message pour cette instance de flux de travail, il tente d’acquérir des verrous sur ces instances qu’il reçoit InstanceLockedException. Les verrous expireront après un certain temps, car l’hôte censé renouveler le verrou n’existe plus.

   Mise à l’échelle horizontale des flux de travail durables sur une batterie homogène de serveurs. Supposons que vous souhaitez mettre à l’échelle horizontalement un flux de travail durable à l’aide de plusieurs hôtes derrière un équilibreur de charge réseau (Network Load Balancer), l’hôte de flux de travail s’exécutant sur un nœud de la batterie de serveurs charge une instance de flux de travail et traite un message, et le message suivant à l’instance est acheminé vers l’hôte qui s’exécute sur un autre nœud, car l’algorithme de routage n’a pas d’algorithme de routage pour remettre des messages à l’hôte qui exécute déjà l’instance. Lors de la réception du message, le deuxième hôte tente de charger l’instance de workflow et reçoit le InstanceLockedException message, car le premier hôte a un verrou sur l’instance. Le premier hôte déverrouille l’instance lorsqu’elle est terminée avec le traitement du premier message et le deuxième hôte acquiert le verrou lorsqu’il réessaye la prochaine fois, charge l’instance et traite le deuxième message.