Action d'exception verrouillée d'instance
Cette rubrique s'applique à Windows Workflow Foundation 4.
La propriété Action d'exception verrouillée d'instance du magasin d'instances de workflow SQL vous permet de spécifier l'action que le fournisseur de persistance SQL doit effectuer lorsqu'il reçoit une InstanceLockedException. Le fournisseur de persistance reçoit cette exception lorsqu'il essaye de verrouiller une instance de service de workflow actuellement verrouillée par un autre hôte de service. Les valeurs autorisées pour cette propriété sont No Retry, Basic Retry et Aggressive Retry. La valeur par défaut est No Retry. La liste suivante décrit ces trois options :
No Retry (valeur par défaut). Le fournisseur de persistance ne réessaye pas de verrouiller l'instance et passe l'InstanceLockedException à l'appelant.
Basic Retry. Le fournisseur de persistance réessaye de verrouiller l'instance avec un intervalle de tentative linéaire et soit réussit à verrouiller l'instance, soit passe l'InstanceLockedException à l'appelant à la fin de la séquence.
Aggressive Retry. Le fournisseur de persistance réessaye de verrouiller l'instance avec un délai exponentiellement croissant, et soit réussit à verrouiller l'instance, soit passe InstanceLockedException à l'appelant à la fin de la séquence. Au début, les intervalles sont courts dans une tentative d'acquérir le verrou aussi rapidement que possible et les intervalles s'allongent à chaque tentative infructueuse.
La fonctionnalité Action d'exception verrouillée d'instance prend en charge les scénarios ci-après. Dans tous les scénarios, si la propriété instanceLockedExceptionAction du SqlWorkflowInstanceStore est définie sur BasicRetry ou AggressiveRetry, l'hôte réessaye de façon transparente d'acquérir régulièrement le verrou sur les instances.
Activation de l'arrêt approprié et du recyclage avec chevauchement des domaines d'application. Imaginez qu'un AppDomain avec un hôte de service exécutant des instances de service de workflow est en cours de recyclage. Un nouveau AppDomain est affiché pour gérer de nouvelles requêtes en parallèle, pendant que l'ancien AppDomain est arrêté correctement. L'arrêt attend jusqu'à ce que les instances de service de workflow soient inactives, puis il les rend persistantes et les décharge. Toute tentative de verrouillage d'une instance par les hôtes dans le nouveau AppDomain déclenche une InstanceLockedException.
Mise à l'échelle horizontale des flux de travail durables parmi une batterie homogène de serveurs. Imaginez qu'un nœud d'une batterie de serveurs sur laquelle une instance de workflow s'exécute tombe en panne 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 reçoit un message pour cette instance de workflow, il essaye d'acquérir des verrous sur ces instances et reçoit l'InstanceLockedException. Les verrous expirent après un certain temps, car l'hôte qui était censé renouveler le verrou n'existe plus.
Mise à l'échelle horizontale des flux de travail durables parmi une batterie homogène de serveurs. Imaginez que vous souhaitez mettre à l'échelle horizontalement un flux de travail durable à l'aide de plusieurs hôtes derrière un NLB (équilibrage de charge réseau). Le flux de travail hôte s'exécutant sur un nœud de la batterie charge une instance de workflow et traite un message. Le message suivant destiné à l'instance est acheminé vers l'hôte qui s'exécute sur un autre nœud, car le NLB n'a pas d'algorithme de routage pour remettre des messages à l'hôte qui exécute déjà l'instance. À la réception du message, le second hôte essaye de charger l'instance de workflow et reçoit l'objet InstanceLockedException, car le premier hôte a un verrou sur l'instance. Le premier hôte déverrouille l'instance une fois lorsqu'il a terminé de traiter le premier message et le second hôte acquiert le verrou lorsqu'il réessaye une nouvelle fois. Il charge alors l'instance et traite le second message.