Instanz gesperrte Ausnahmeaktion

Mit InstanceLockedExceptionAction der Eigenschaft des SQL-Workflowinstanzspeichers können Sie angeben, welche Aktion der SQL-Persistenzanbieter ausführen soll, wenn er eine InstanceLockedException. Der Persistenzanbieter empfängt diese Ausnahme, wenn versucht wird, eine Workflowdienstinstanz zu sperren, die derzeit von einem anderen Diensthost gesperrt ist. Die Werte für diese Eigenschaft sind NoRetry, BasicRetryund AggressiveRetry. Der Standardwert ist NoRetry. In der folgenden Liste werden die drei Optionen beschrieben:

• NoRetry. Der Diensthost versucht nicht, die Workflowdienstinstanz zu sperren und den InstanceLockedException Aufrufer zu übergeben. Wenn Ihr Workflow für einen Zeitraum von mehr als 60 Sekunden im Arbeitsspeicher bleibt, verwenden Sie NoRetry diesen Vorgang als Wiederholung. Der Standardwert ist NoRetry.

• BasicRetry. Der Diensthost versucht erneut, die Workflowdienstinstanz mit einem linearen Intervall zwischen Wiederholungsversuchen zu sperren und den InstanceLockedException Aufrufer am Ende der Sequenz an den Aufrufer zu übergeben. Wenn Der Workflow ungefähr zwischen 5 und 60 Sekunden im Arbeitsspeicher bleibt und Nachrichten in Batches eingehen, bei denen es wahrscheinlicher ist, dass Nachrichten an dieselbe Instanz auf demselben Host gesendet werden, um alle Nachrichten vor dem Entladen des Workflows zu verarbeiten, verwenden Sie BasicRetry die beste Latenz, ohne Ressourcen zu verschwenden.

• AggressiveRetry. Der Diensthost versucht erneut, die Workflowdienstinstanz mit einem exponentiellen Backoffintervall zwischen Wiederholungsversuchen zu sperren und die Ausnahme an den Aufrufer am Ende der Sequenz zu übergeben. Wenn Ihr Workflow für eine sehr kurze Zeit im Arbeitsspeicher bleibt (weniger als 5 Sekunden), oder eine Webfarm groß ist und die Wahrscheinlichkeit, dass eine andere Nachricht an denselben Host übermittelt wird, nicht sehr hoch ist, verwenden AggressiveRetry Sie die beste Latenz.

Das Feature "Instanz gesperrte Ausnahmeaktion" unterstützt die folgenden Szenarien. In allen Szenarien, wenn die instanceLockedExceptionAction-Eigenschaft des SqlWorkflowInstanceStore auf BasicRetry oder AggressiveRetryfestgelegt ist, versucht der Host transparent, die Sperre für Instanzen regelmäßig abzurufen.

1. Aktivieren des ordnungsgemäßen Herunterfahrens und überlappenden Recyclings von Anwendungsdomänen. Angenommen, eine AppDomain mit einem Diensthost, auf dem Workflowdienstinstanzen ausgeführt werden, werden wiederverwendet, und eine neue AppDomain wird zur parallelen Behandlung neuer Anforderungen angezeigt, während die alte AppDomain ordnungsgemäß heruntergezogen wird. Das Herunterfahren wartet, bis Workflowdienstinstanzen im Leerlauf sind, und die Instanzen werden dann beibehalten und entladen. Alle Versuche von Hosts in der neuen AppDomain zum Sperren einer Instanz führen zu einer InstanceLockedException.

2. Horizontale Skalierung dauerhafter Workflows über eine homogene Farm von Servern. Angenommen, ein Knoten einer Serverfarm, auf der eine Workflowinstanz abstürzt, und der Workflowhost kann keine Sperren für die ausgeführte Instanz entfernen. Wenn ein Diensthost, der auf einem anderen Knoten der Farm ausgeführt wird, eine Meldung für diese Workflowinstanz empfängt, versucht er, Sperren für diese Instanzen abzurufen, die er empfängt InstanceLockedException. Die Sperren laufen nach einiger Zeit ab, da der Host, der die Sperre erneuern soll, nicht mehr vorhanden ist.

   Horizontale Skalierung dauerhafter Workflows über eine homogene Farm von Servern. Angenommen, Sie möchten einen dauerhaften Workflow horizontal skalieren, indem Sie mehrere Hosts hinter einem NLB (Netzwerklastenausgleich) verwenden, der Workflowhost, der auf einem Knoten der Farm ausgeführt wird, eine Workflowinstanz lädt und eine Nachricht verarbeitet, und die nächste Nachricht an die Instanz wird an den Host weitergeleitet, der auf einem anderen Knoten ausgeführt wird, da der NLB keinen Routingalgorithmus zum Übermitteln von Nachrichten an den Host hat, der bereits die Instanz ausführt. Beim Empfang der Nachricht versucht der zweite Host, die Workflowinstanz zu laden und empfängt den InstanceLockedException , weil der erste Host eine Sperre für die Instanz hat. Der erste Host entsperrt die Instanz, wenn sie mit der Verarbeitung der ersten Nachricht fertig ist, und der zweite Host erhält die Sperre, wenn sie das nächste Mal erneut ausgeführt wird, lädt die Instanz und verarbeitet die zweite Nachricht.