Instance Locked Exception Action
Dieses Thema gilt für Windows Workflow Foundation 4.
Mit der Eigenschaft Instance Locked Exception Action des SQL-Workflowinstanzspeichers können Sie angeben, welche Aktion der SQL-Persistenzanbieter durchführen soll, wenn er eine InstanceLockedException-Ausnahme empfängt. Der Persistenzanbieter empfängt diese Ausnahme, wenn er versucht, eine Workflowdienstinstanz zu sperren, die von einem anderen Diensthost gesperrt wurde. Die zulässigen Werte für diese Eigenschaft sind No Retry, Basic Retry und Aggressive Retry. Der Standardwert ist No Retry. In der folgenden Liste werden die drei Optionen beschrieben:
No Retry (Standardwert). Der Persistenzanbieter versucht nicht erneut, die Instanz zu sperren, und übergibt die InstanceLockedException-Ausnahme an den Aufrufer.
Basic Retry. Der Persistenzanbieter versucht innerhalb eines linearen Wiederholungsintervalls erneut, die Instanz zu sperren, und kann die Instanz entweder erfolgreich sperren oder übergibt die InstanceLockedException-Ausnahme am Ende der Sequenz an den Aufrufer.
Aggressive Retry. Der Persistenzanbieter versucht innerhalb exponentiell zunehmenden Verzögerungsintervallen erneut, die Instanz zu sperren, und kann die Instanz entweder erfolgreich sperren oder übergibt die InstanceLockedException-Ausnahme am Ende der Sequenz an den Aufrufer. Die Intervalle sind zu Anfang kurz, um zu versuchen, die Sperre so schnell wie möglich vorzunehmen, und werden mit jedem fehlgeschlagenen Versuch länger.
Die Funktion Instance Locked Exception Action unterstützt die folgenden Szenarios. Für alle Szenarios gilt: Wenn die instanceLockedExceptionAction-Eigenschaft des SqlWorkflowInstanceStore-Objekts 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. Nehmen Sie an, 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 eine InstanceLockedException-Ausnahme 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 die InstanceLockedException-Ausnahme. 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.