Lang andauernde Transaktionen

Lang ausgeführte Transaktionen sind wichtige, in BizTalk-Orchestrierungen häufig verwendete Konstrukte. Sie bieten Möglichkeiten für benutzerdefinierte bereichsbasierte Kompensierungen und Ausnahmehandler sowie zur Verschachtelung von Transaktionen. All diese Optionen ermöglichen Ihnen beim Entwickeln robuster Transaktionsarchitekturen eine größere Flexibilität.

Lang ausgeführte Transaktionen können verwendet werden, wenn die Transaktion über einen größeren Zeitraum ausgeführt werden muss und keine vollständigen ACID-Eigenschaften erforderlich sind (d. h. wenn Daten von anderen Transaktionen nicht isoliert werden müssen). Lang ausgeführte Transaktionen können über längere Zeiträume inaktiv sein, da sie während dieser Zeiten auf das Eintreffen externer Nachrichten warten.

Sie sind konsistent und dauerhaft, nicht jedoch atomarisch und bieten keine Isolation. Die Daten in lang ausgeführten Transaktionen sind nicht gesperrt, sodass sie von anderen Vorgängen oder Anwendungen geändert werden können. Die Isolationseigenschaft für Statusaktualisierungen ist nicht verfügbar, da es nicht sinnvoll ist, Sperren für einen längeren Zeitraum aufrecht zu erhalten.

Das Commit einer lang ausgeführten Transaktion unterscheidet sich vom Commit einer atomarischen Transaktion. Es gibt keine implizite Annahme zur verteilten Koordination hinsichtlich des Ergebnisses (eine lang ausgeführte Transaktion ist lediglich in einer Orchestrierungsinstanz vorhanden). Stattdessen gilt eine lang ausgeführte Transaktion als abgeschlossen (mit einem Commit), sobald die letzte darin enthaltene Anweisung beendet ist. Im Falle eines Transaktionsabbruchs wird kein automatisches Rollback des Status ausgeführt. Mithilfe der Ausnahme- und Kompensationshandler können Sie ein Rollback programmgesteuert ausführen.

Ein Bereich kann seinen eigenen Status definieren, indem Variablen, Nachrichten und .NET-Komponenten deklariert werden. Lang ausgeführte Transaktionen verfügen über Zugriff auf die Statusinformationen des eigenen Bereichs und aller Bereiche, die sie einschließen, sowie auf alle in der Orchestrierung global definierten Statusinformationen. Sie verfügen nicht über Zugriff auf die Statusinformationen von Bereichen, die sie nicht einschließen.

Verschachtelung

Lang ausgeführte Transaktionen können atomarische Transaktionen oder weitere lang ausgeführte Transaktionen enthalten. Sie können beliebig verschachtelt werden. Eine Transaktion kann beispielsweise zwei weitere lang ausgeführte Transaktionen enthalten, von denen jede atomarische Transaktionen enthalten kann.

Eine Verschachtelung ist besonders dann sinnvoll, wenn mindestens eine der Komponenten der Gesamttransaktion atomarisch sein muss, während die Gesamttransaktion lang ausgeführt sein muss. Als Beispiel kann das Empfangen und Ausführen einer Bestellung dienen. Die Bestellung kann zu einem beliebigen Zeitpunkt eingehen, und es dauert möglicherweise eine gewisse Zeit, bis die verschiedenen Schritte zum Ausführen eintreten. Dennoch soll der gesamte Vorgang als Transaktion behandelt werden. Die Gesamttransaktion muss in diesem Fall lang ausgeführt sein, ein einzelner Schritt hingegen (z. B. eine Zahlungsbestätigung) muss möglicherweise atomarisch sein.

Hinweis

Transaktionsbereiche können in nicht transaktionalen Bereichen oder Orchestrierungen nicht verschachtelt werden. Nicht transaktionale umschließende Bereiche oder Orchestrierungen können den Status nicht verwalten, da dieser die Statusverwaltung aller enthaltenen Bereiche verarbeiten muss.

Hinweis

Eine synchronisierte Transaktion kann keine weiteren Transaktionen oder synchronisierte Bereiche enthalten.

Kompensierung

Eine lang ausgeführte Transaktion kann einen Kompensierungsblock festlegen, der aufgerufen wird, um nach dem Commit die Aktivitäten der Transaktion zu kompensieren. Dieser kann gegebenenfalls die Transaktion rückgängig machen oder andere Funktionen (z. B. Benachrichtigungen) ausführen, die dazu beitragen, die Auswirkungen der Transaktion zu mildern. Wenn kein eigener Kompensierungscode hinzugefügt wird, werden in der Standardeinstellung die Kompensierungsblöcke der inneren Transaktionen von der Runtime-Engine aufgerufen. Dabei werden in umgekehrter Reihenfolge sowohl lang ausgeführte als auch atomarische Transaktionen aufgerufen, beginnend mit der letzten abgeschlossenen Transaktion und endend mit der ersten abgeschlossenen Transaktion.

Hinweis

Eine Kompensierung kann nur für erfolgreich abgeschlossene Transaktionen erfolgen.

Fehlertoleranz

Transaktionen unterstützen die Fehlertoleranz hinsichtlich der Wiederherstellung sowohl für interne (z. B. Computer- und Softwarefehler) als auch für externe Fehler (z. B. Abbruchmeldungen). Für teilweise ausgeführte Aktualisierungen erfolgt beim Auftreten eines Transaktionsfehlers innerhalb von lang ausgeführten Transaktionen kein Rollback, da sie sich in ACID-Transaktionen befinden.

Beim Auftreten eines Fehlers wird der Ausnahmecodeblock für die lang ausgeführte Transaktion aufgerufen. Der Ausnahmecodeblock beinhaltet eine Reihe von Fehlerhandlern, die geschrieben werden, um mit allen Fehlern umgehen zu können, die beim Ausführen der Transaktion auftreten können. Bei der Fehlerbehandlung können Sie sich auf den letzten bekannten Status der Nachrichten, Variablen und Objekte verlassen.

In der Regel soll der Ausnahmehandler den Status der Orchestrierung beim Auftreten der Ausnahme prüfen, alle für den Status angemessenen Aktionen durchführen und die Kompensierungen für alle verschachtelten Transaktionen aufrufen.

Beim Auftreten eines Fehlers wird die Ausführung der lang ausgeführten Transaktion unterbrochen. Sie kann im Anschluss an das Auftreten eines Fehlers nicht fortgesetzt werden.

Weitere Informationen

Szenarios, die lang ausgeführte Transaktionen verwenden
Atomarische Transaktionen
Verwenden von Transaktionen und Behandeln von Ausnahmen