Persistenzteilnehmer

  • Artikel

Ein Persistenzteilnehmer kann an einem von einem Anwendungshost ausgelösten Persistenzvorgang (Speichern oder Laden) teilnehmen. Im Lieferumfang von .NET Framework 4.6.1 sind zwei abstrakte Klassen enthalten, 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. Beim Beibehalten einer Workflowinstanz sucht der Anwendungshost möglicherweise nach Workflowerweiterungen dieser Art und ruft auf den Persistenzteilnehmern zur richtigen Zeit jeweils die entsprechenden Methoden auf.

In der folgenden Liste werden die Aufgaben beschrieben, die das Persistenzsubsystem in den einzelnen Phasen des Persistenzvorgangs (Speichern) ausführt. Die Persistenzteilnehmer werden in der dritten und vierten Phase verwendet. Falls der Teilnehmer ein E/A-Teilnehmer ist (ein Persistenzteilnehmer, der auch an E/A-Vorgängen beteiligt ist), wird der Teilnehmer auch in der sechsten Phase verwendet.

  1. Erfasst integrierte Werte, einschließlich Workflowstatus, Lesezeichen, zugeordnete Variablen und Timestamps.

  2. Erfasst alle Persistenzteilnehmer, die der Erweiterungsauflistung mit Zuordnung zur Workflowinstanz hinzugefügt wurden.

  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. Falls der Persistenzabschnitt transaktionsgebunden ist, wird die Transaktion in der Transaction.Current-Eigenschaft 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 E/A-Persistenzteilnehmer wird von der PersistenceIOParticipant-Klasse abgeleitet und kann die BeginOnSave-Methode zusätzlich zur Implementierung der Methoden CollectValues und MapValues implementieren.

Jede Phase wird abgeschlossen, bevor die nächste Phase beginnt. In der ersten Phase werden z. B. Werte von allen Persistenzteilnehmern erfasst. Alle in der ersten Phase erfassten Werte werden in der zweiten Phase dann für alle Persistenzteilnehmer bereitgestellt, um die Zuordnung sicherzustellen. Alle in der ersten und zweiten Phase erfassten Werte werden dann für alle Persistenzteilnehmer in der dritten Phase bereitgestellt usw.

In der folgenden Liste werden die Aufgaben beschrieben, die das Persistenzsubsystem in den einzelnen Phasen des Ladevorgangs ausführt. Die Persistenzteilnehmer werden in der vierten Phase verwendet. Die E/A-Persistenzteilnehmer (Persistenzteilnehmer, die auch an E/A-Vorgängen beteiligt sind) werden auch in der dritten Phase verwendet.

  1. Erfasst alle Persistenzteilnehmer, die der Erweiterungsauflistung mit Zuordnung zur Workflowinstanz hinzugefügt wurden.

  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. Falls der Persistenzabschnitt transaktionsgebunden ist, wird die Transaktion in der Transaction.Current-Eigenschaft bereitgestellt.

  4. Lädt die Workflowinstanz basierend auf den aus dem Persistenzspeicher abgerufenen Daten in den Arbeitsspeicher.

  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 in einem Szenario mit mehreren Knoten von mehr als einem Host geladen wird. Wenn Sie versuchen, eine gesperrte Workflowinstanz zu laden, wird eine mit der folgenden vergleichbare Ausnahme angezeigt: Die Ausnahme " System.ServiceModel.Persistence.InstanceLockException: Der angeforderte Vorgang konnte nicht abgeschlossen werden, da die Sperre für die Instanz '00000000-0000-0000-0000-000000000000' nicht abgerufen werden konnte". Dieser Fehler tritt auf, wenn eine der folgenden Situationen vorliegt:

  • In einem Szenario mit mehreren Knoten wird die Instanz von einem anderen Host geladen. Es gibt mehrere Möglichkeiten, diese Art von Konflikten zu beheben: Leiten Sie die Verarbeitung an den Knoten weiter, der die Sperre besitzt, und wiederholen Sie den Vorgang, oder erzwingen Sie das Laden, wodurch der andere Host daran gehindert wird, die Arbeit zu speichern.

  • In einem Szenario mit einem einzelnen Knoten ist der Host abgestürzt. Wenn der Host erneut gestartet wurde (durch die Wiederverwendung eines Prozesses oder die Erstellung einer neuen Persistenzanbieterfactory), 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 zu einem bestimmten Zeitpunkt abgebrochen, und es wird eine neue Persistenzanbieterinstanz erstellt, die eine andere Host-ID aufweist.

Das Sperrtimeout hat einen Standardwert von 5 Minuten, Sie können beim Aufrufen von Load einen anderen Timeoutwert angeben.

In diesem Abschnitt

Siehe auch