Freigeben über

Persistenzteilnehmer

Ein Persistenzteilnehmer kann an einem Persistenzvorgang (Speichern oder Laden) teilnehmen, der von einem Anwendungshost ausgelöst wird. Das .NET Framework 4.6.1 enthält zwei abstrakte Klassen, PersistenceParticipant und PersistenceIOParticipant, mit denen Sie einen Persistenzteilnehmer erstellen können. Ein Persistenzteilnehmer leitet sich von einer dieser Klassen ab, implementiert die passenden Methoden und fügt dann der WorkflowExtensions-Auflistung im WorkflowServiceHost eine Instanz der Klasse hinzu. Der Anwendungshost kann nach solchen Workflowerweiterungen suchen, wenn eine Workflowinstanz beibehalten wird, und geeignete Methoden für die Persistenzteilnehmer zu geeigneten Zeiten aufrufen.

In der folgenden Liste werden die Aufgaben beschrieben, die vom Persistenzsubsystem in verschiedenen Phasen des Persistenzvorgangs (Speichern) ausgeführt werden. Die Persistenzteilnehmer werden in der dritten und vierten Stufe verwendet. Wenn der Teilnehmer ein E/A-Teilnehmer ist (ein Persistenzteilnehmer, der auch an E/A-Vorgängen teilnimmt), kommt er auch in der sechsten Stufe zum Einsatz.

  1. Sammelt integrierte Werte, einschließlich Workflowstatus, Lesezeichen, zugeordnete Variablen und Zeitstempel.

  2. Sammelt alle Persistenzteilnehmer, die der Erweiterungsauflistung hinzugefügt wurden, die der Workflowinstanz zugeordnet ist.

  3. Ruft die CollectValues-Methode auf, die von allen Persistenzteilnehmern implementiert wurde.

  4. Ruft die MapValues-Methode auf, die von allen Persistenzteilnehmern implementiert wurde.

  5. Beibehalten oder Speichern des Workflows im persistenten Speicher.

  6. Ruft die BeginOnSave-Methode auf allen E/A-Persistenzteilnehmern auf. Wenn der Teilnehmer kein E/A-Teilnehmer ist, wird diese Aufgabe übersprungen. Wenn die Persistenz-Episode transaktional ist, wird die Transaktion in der Eigenschaft Transaction.Current bereitgestellt.

  7. Wartet, bis die Vorgänge aller Persistenzteilnehmer abgeschlossen sind. Falls alle Teilnehmer das Beibehalten der Instanzdaten erfolgreich abschließen, wird für die Transaktion ein Commit ausgeführt.

Ein Persistenzteilnehmer wird von der PersistenceParticipant-Klasse abgeleitet und kann die Methoden CollectValues und MapValues implementieren. Ein Persistenz-E/A-Teilnehmer wird von der PersistenceIOParticipant-Klasse abgeleitet und kann zusätzlich zur Implementierung der Methoden CollectValues und MapValues die BeginOnSave-Methode implementieren.

Jede Phase wird abgeschlossen, bevor die nächste Phase beginnt. Beispielsweise werden Werte von allen Persistenzteilnehmern in der ersten Phase erfasst. Dann werden alle in der ersten Phase gesammelten Werte allen Persistenzteilnehmern in der zweiten Phase für die Zuordnung bereitgestellt. Anschließend werden alle in den ersten und zweiten Phasen gesammelten und zugeordneten Werte dem Persistenzanbieter in der dritten Stufe usw. bereitgestellt.

In der folgenden Liste werden die Aufgaben beschrieben, die vom Persistenzsubsystem in verschiedenen Phasen des Ladevorgangs ausgeführt werden. Die Persistenzteilnehmer kommen in der vierten Stufe zum Einsatz. Die E/A-Persistenzteilnehmer (Persistenzteilnehmer, die auch an E/A-Vorgängen beteiligt sind) werden auch in der dritten Phase verwendet.

  1. Sammelt alle Persistenzteilnehmer, die der Erweiterungsauflistung hinzugefügt wurden, die der Workflowinstanz zugeordnet ist.

  2. Lädt den Workflow aus dem Persistenzspeicher.

  3. Ruft BeginOnLoad auf allen E/A-Persistenzteilnehmern auf und wartet, bis die Vorgänge aller Persistenzteilnehmer abgeschlossen sind. Wenn die Persistenz-Episode transaktional ist, wird die Transaktion in Transaction.Current bereitgestellt.

  4. Lädt die Workflowinstanz im Arbeitsspeicher basierend auf den Daten, die aus dem Persistenzspeicher abgerufen wurden.

  5. Ruft PublishValues für jeden Persistenzteilnehmer auf.

Ein Persistenzteilnehmer wird von der PersistenceParticipant-Klasse abgeleitet und kann die PublishValues-Methode implementieren. Ein E/A-Persistenzteilnehmer wird von der PersistenceIOParticipant-Klasse abgeleitet und kann die BeginOnLoad-Methode zusätzlich zur Implementierung der PublishValues-Methode implementieren.

Beim Laden einer Workflowinstanz erstellt der Persistenzanbieter eine Sperre für diese Instanz. Dadurch wird verhindert, dass die Instanz von mehreren Hosts in einem Szenario mit mehreren Knoten geladen wird. Wenn Sie versuchen, eine Workflowinstanz zu laden, die gesperrt wurde, wird eine Ausnahme wie die folgende angezeigt: Die Ausnahme " System.ServiceModel.Persistence.InstanceLockException: Der angeforderte Vorgang konnte nicht abgeschlossen werden, da die Sperre beispielsweise '0000000-0000-0000-00000-00000000' nicht erworben werden konnte". Dieser Fehler wird ausgelöst, wenn einer der folgenden Fehler auftritt:

  • In einem Szenario mit mehreren Knoten wird die Instanz von einem anderen Host geladen. Es gibt einige verschiedene Möglichkeiten, diese Arten von Konflikten zu lösen: Leiten Sie die Verarbeitung an den Knoten weiter, der die Sperre besitzt, und versuchen Sie es erneut, oder erzwingen Sie die Last, die dazu führt, dass der andere Host ihre Arbeit nicht speichern kann.

  • In einem Szenario mit einem einzelnen Knoten ist der Host abgestürzt. Wenn der Host erneut gestartet wird (ein Prozess wird wiederverwendet oder eine neue Persistenzanbieterfactory erstellt), versucht der neue Host, eine Instanz zu laden, die noch vom alten Host gesperrt ist, da die Sperre noch nicht abgelaufen ist.

  • In einem Szenario mit einem einzelnen Knoten wurde die betreffende Instanz irgendwann abgebrochen, und es wird eine neue Persistenzanbieterinstanz erstellt, die eine andere Host-ID besitzt.

Der Wert für das Sperrtimeout weist einen Standardwert von 5 Minuten auf, Sie können beim Aufrufen Loadeinen anderen Timeoutwert angeben.

In diesem Abschnitt

Siehe auch

  • Last updated on