Instance Locked Exception Action
Mit der InstanceLockedExceptionAction-Eigenschaft des SQL-Workflowinstanzspeichers können Sie angeben, welche Aktion der SQL-Persistenzanbieter ausführen soll, wenn er InstanceLockedException empfängt. Der Persistenzanbieter empfängt diese Ausnahme, wenn er versucht, eine Workflowdienstinstanz zu sperren, die von einem anderen Diensthost gesperrt wurde. Folgende Werte sind für diese Eigenschaft möglich: NoRetry, BasicRetry und AggressiveRetry. Standardwert: NoRetry. In der folgenden Liste werden die drei Optionen beschrieben:
NoRetry. Der Diensthost versucht nicht, die Workflowdienstinstanz zu sperren, und übergibt die InstanceLockedException an den Aufrufer. Wenn Ihr Workflow für einen Zeitraum von mehr als 60 Sekunden im Arbeitsspeicher bleibt, verwenden Sie NoRetry als erneuten Versuch. Standardwert: NoRetry.
BasicRetry. Der Diensthost versucht erneut, die Workflowdienstinstanz mit einem linearen Intervall zwischen Wiederholungsversuchen zu sperren, und übergibt am Ende der Sequenz InstanceLockedException an den Aufrufer. Wenn der Workflow etwa zwischen 5-60 Sekunden im Arbeitsspeicher verbleibt und Nachrichten in Batches empfangen werden, wobei es wahrscheinlicher ist, dass die Nachrichten an dieselbe Instanz auf demselben Host gesendet werden, um alle Nachrichten zu verarbeiten, bevor der Workflow entladen wird, verwenden Sie BasicRetry, um die beste Latenz zu erreichen, ohne Ressourcen zu vergeuden.
AggressiveRetry. Der Diensthost versucht erneut, die Workflowdienstinstanz mit einem exponentiellen Backoffintervall zwischen Wiederholungsversuchen zu sperren, und übergibt am Ende der Sequenz die Ausnahme an den Aufrufer. Wenn der Workflow nur sehr kurze Zeit (weniger als 5 Sekunden) im Arbeitsspeicher verbleibt oder eine Webfarm umfangreich ist und die Wahrscheinlichkeit, dass demselben Host eine weitere Nachricht zugestellt wird, nicht sehr hoch ist, verwenden Sie AggressiveRetry, um die beste Latenz zu erzielen.
Die Funktion Instance Locked Exception Action unterstützt die folgenden Szenarios. Für alle Szenarios gilt: Wenn die instanceLockedExceptionAction-Eigenschaft von SqlWorkflowInstanceStore auf BasicRetry oder AggressiveRetry festgelegt ist, versucht der Host in regelmäßigen Abständen und transparent erneut, die Sperre für die Instanzen durchzusetzen.
Ordnungsgemäßes Herunterfahren und überlappende Wiederverwendung von Anwendungsdomänen. Angenommen, eine AppDomain mit einem Diensthost, der Workflowdienstinstanzen ausführt, wird wiederverwendet, und eine neue AppDomain wird für neue Anforderungen geladen, während die alte AppDomain ordnungsgemäß heruntergefahren wird. Mit dem Herunterfahren wird gewartet, bis die Workflowdienstinstanzen sich im Leerlauf befinden. Dann werden die Instanzen in den Persistenzspeicher verschoben und entladen. Versuche von Hosts in der neuen AppDomain, eine Instanz zu sperren, lösen InstanceLockedException aus.
Horizontale Skalierung permanenter Workflows in einer homogenen Serverfarm. Nehmen Sie an, ein Knoten in einer Serverfarm, auf dem eine Workflowinstanz ausgeführt wird, stürzt ab, und der Workflowhost kann die Sperren der ausgeführten Instanz nicht aufheben. Wenn an einem Diensthost, der auf einem anderen Knoten der Farm ausgeführt wird, eine Meldung für diese Workflowinstanz eingeht und dieser versucht, die Instanzen zu sperren, erhält er InstanceLockedException. Die Sperren laufen nach einem gewissen Zeitraum ab, da der für die Erneuerung der Sperren zuständige Host nicht mehr vorhanden ist.
Horizontale Skalierung permanenter Workflows in einer homogenen Serverfarm. Nehmen Sie an, Sie möchten einen permanenten Workflow mit mehreren Hosts horizontal skalieren, denen ein Netzwerklastenausgleich (Network Load Balancer, NLB) vorgeschaltet ist. Der Workflowhost, der auf einem Knoten der Farm ausgeführt wird, lädt eine Workflowinstanz und verarbeitet eine Meldung, und die nächste Meldung für die Instanz wird an einen Host weitergeleitet, der auf einem anderen Knoten ausgeführt wird, da der Netzwerklastenausgleich über keinen Routingalgorithmus zur Weiterleitung von Meldungen an den Host verfügt, der die Instanz bereits ausführt. Bei Erhalt der Meldung versucht der zweite Host, die Workflowinstanz zu laden. Da diese jedoch durch den ersten Host gesperrt wurde, wird die InstanceLockedException-Ausnahme ausgelöst. Der erste Host entsperrt die Instanz, wenn die Verarbeitung der ersten Meldung abgeschlossen ist, und der zweite Host kann die Instanz beim nächsten Versuch erfolgreich sperren, laden und die zweite Meldung verarbeiten.
