Atomische Transaktionen

BizTalk-Orchestrierungen können zum Ausführen einzelner Arbeitsfragmente – gemäß dem klassischen Konzept einer ACID-Transaktion – ausgelegt werden. Beim Ausführen dieser einzelnen bzw. atomarischen Arbeitseinheiten wechselt der Geschäftsprozess aus einem konsistenten Status in einen neuen, konsistenten und dauerhaften Status, der von anderen Arbeitseinheiten isoliert ist. Dies erfolgt in der Regel mithilfe des Bereichskonstrukts, das die Arbeitseinheiten mit der Transaktionssemantik kapselt. Die gesamte Orchestrierung kann auch ohne Verwendung von Bereichen als eine atomarische Transaktion definiert werden. Die Bereiche können jedoch nur dann als transaktional gekennzeichnet werden, wenn die Orchestrierung selbst als ein lang ausgeführter oder atomarischer Transaktionstyp gekennzeichnet ist. Durch atomarische Transaktionen wird gewährleistet, dass beim Auftreten eines Fehlers während einer Transaktionsaktualisierung für alle unvollständigen Aktualisierungen automatisch ein Rollback durchgeführt wird, und dass die Auswirkungen der Transaktion rückgängig gemacht werden (mit Ausnahme der Auswirkungen von .NET-Aufrufen, die während der Transaktion vorgenommen werden). Atomarische Transaktionen in BizTalk-Orchestrierungen ähneln DTC-Transaktionen (Distributed Transaction Coordinator) dahingehend, dass sie im Allgemeinen kurzlebig sind und die vier ACID-Merkmale (Atomicity, Consistency, Isolation und Durability – Unteilbarkeit, Konsistenz, Isolation und Beständigkeit) besitzen:

• Unteilbarkeit

  Eine Transaktion stellt eine atomarische Arbeitseinheit dar. Es werden entweder sämtliche in einer Transaktion enthaltenen Änderungen durchgeführt oder keine.

• Konsistenz

  Beim Ausführen eines Commit-Vorgangs muss eine Transaktion die Integrität der Daten im System aufrecht erhalten. Wenn durch eine Transaktion eine Datenänderung in einer Datenbank durchgeführt wird, die vor dem Starten der Transaktion intern konsistent war, muss die Datenbank weiter intern konsistent sein, wenn der Commit durchgeführt wird. Diese Eigenschaft sicherzustellen, liegt im Wesentlichen in der Verantwortung des Anwendungsentwicklers.

• Isolation

  Änderungen, die von gleichzeitigen Transaktionen ausgeführt werden, müssen von den Änderungen, die von anderen gleichzeitigen Transaktionen ausgeführt werden, isoliert sein. Isolierte Transaktionen, die gleichzeitig ausgeführt werden, führen Änderungen so durch, dass die interne Datenbankkonsistenz exakt so beibehalten wird, als ob die Transaktionen nacheinander ausgeführt würden.

• Dauerhaftigkeit

  Nach dem für eine Transaktion ein Commit durchgeführt wurde, bleiben standardmäßig alle Änderungen im System dauerhaft bestehen. Die Änderungen bleiben sogar bei einem Systemausfall erhalten.

  Die folgenden Isolationsebenen werden von den in BizTalk-Orchestrierungen verwendeten atomarischen Transaktionen unterstützt:

• Lesen zugesichert

  Beim Lesen der Daten werden gemeinsame Sperren verwendet, um das Lesen geänderter Daten zu verhindern. Die Daten können jedoch vor dem Ende der Transaktion geändert werden, was zu nicht wiederholbaren Lesevorgängen oder Phantomdaten führen kann.

• Wiederholbarer Lesevorgang

  Die Sperren gelten für alle in einer Abfrage verwendeten Daten, damit die Daten nicht durch andere Benutzer aktualisiert werden können. Dies verhindert Lesevorgänge, die sich nicht wiederholen lassen, Phantomzeilen sind jedoch weiterhin möglich.

• Serializable

  Eine Bereichssperre wird eingesetzt, die verhindert, dass andere Benutzer vor Abschluss der Transaktion Zeilen in die Datenbank einfügen oder diese aktualisieren.

  BizTalk Server stellt sicher, dass innerhalb einer atomarischen Transaktion stattfindende Statusänderungen (wie Änderungen an Variablen, Nachrichten und Objekten) nur nach Durchführen eines Commit-Vorgangs für die Transaktion außerhalb des Bereichs der atomarischen Transaktion sichtbar sind. Die dazwischen stattfindenden Statusänderungen sind vor anderen Teilen einer Orchestrierung isoliert.

Hinweis

Wenn eine atomische Transaktion ein Empfangs-Shape , ein Senden-Shape oder ein Startorchestrierungs-Shape enthält, werden die entsprechenden Aktionen erst ausgeführt, wenn für die Transaktion ein Commit ausgeführt wurde.

Wenn für Daten alle vier ACID-Kriterien erfüllt sein sollen (z. B. wenn die Daten vor anderen Transaktionen isoliert werden müssen), dürfen Sie ausschließlich atomarische Transaktionen verwenden.

Bricht eine atomarische Transaktion mit einem Fehler ab, werden alle Status wieder so hergestellt, als ob die Orchestrierungsinstanz nie in dem Bereich war. In BizTalk lautet die Regel für atomarische Transaktionen, dass alle Variablen (nicht nur lokal im Bereich) an der Transaktion teilnehmen. Alle in einer atomarischen Transaktion verwendeten nicht serialisierbaren Variablen und Nachrichten müssen lokal für den Bereich deklariert werden, andernfalls wird vom Compiler die Fehlermeldung "variable….is not marked as serializable" ausgegeben. Bei allen atomarischen Bereichen wird davon ausgegangen, dass sie "synchronisiert" werden sollen. Wenn das Schlüsselwort "synchronized" für atomarische Bereiche explizit angegeben wird, gibt der Orchestrierungscompiler eine Warnung bezüglich redundanter Verwendung aus. Bei den freigegebenen Daten reicht die Synchronisierung vom Beginn bis zum erfolgreichen Abschluss des Bereichs (einschließlich der Statuspersistenz am Ende des Bereichs) bzw. bis zum Abschluss der Ausnahmehandler (bei Fehlern). Die Synchronisierungsdomäne erstreckt sich nicht bis zum Kompensationshandler.

Atomarische Transaktionen können Timeoutwerte zugeordnet werden, bei denen die Transaktion von der Orchestrierung beendet und die Instanz angehalten wird. Wenn eine Transaktion eine Form vom Typ Empfangen, Senden oder Orchestrierung starten enthält, finden die zugehörigen Aktionen erst statt, wenn für die Transaktion ein Commit-Vorgang ausgeführt wurde.

Eine atomische Transaktion wird wiederholt, wenn der Benutzer absichtlich eine RetryTransactionException auslöst oder wenn eine PersistenceException ausgelöst wird, wenn die atomische Transaktion versucht, einen Commit auszuführen. Der letztere Fall kann eintreten, wenn beispielsweise die atomarische Transaktion zu einer verteilten DTC-Transaktion gehört und diese Transaktion von einem anderen Teilnehmer an dieser Transaktion beendet wird. Ebenso würde bei Datenbankkonnektivitätsproblemen zum Zeitpunkt des Commits der Transaktion auch eine PersistenceException ausgelöst. Wenn dies für einen atomaren Bereich mit Retry=True geschieht, wird der Vorgang bis zu 21 Mal wiederholt. Die Pause zwischen den einzelnen Wiederholungen beträgt in der Standardeinstellung zwei Sekunden. (Dies kann aber geändert werden). Wenn für die Transaktion auch nach 21 Wiederholungen kein Commit-Vorgang ausgeführt werden kann, wird die gesamte Orchestrierungsinstanz angehalten. Sie kann manuell fortgesetzt werden und startet dann wieder mit leerem Zähler am Anfang des betreffenden atomarischen Bereichs.

Hinweis

Nur retryTransactionException und PersistenceException können dazu führen, dass ein atomischer Bereich erneut versucht wird. Jede andere Ausnahme, die in einem atomaren Bereich ausgelöst wird, kann nicht dazu führen, dass sie wiederholt wird, auch wenn die Retry-Eigenschaft auf True festgelegt ist. Die Standardverzögerung von zwei Sekunden zwischen den beiden aufeinanderfolgenden Wiederholungen kann mithilfe einer öffentlichen Eigenschaft für RetryTransactionException überschrieben werden (wenn dies die Ausnahme ist, die zum Auslösen der Wiederholungen verwendet wird).

Die atomischen Bereiche haben Einschränkungen beim Schachteln anderer Transaktionen, die keine anderen Transaktionen verschachteln oder Catch - Exception-Blöcke enthalten können.

DTC-Transaktionen

Auch wenn sich atomarische Transaktionen wie DTC-Transaktionen verhalten, handelt es sich bei ihnen in der Standardeinstellung nicht explizit um DTC-Transaktionen. Sie können sie explizit als DTC-Transaktionen deklarieren, wenn es sich bei allen in der Transaktion verwendeten Objekten um COM+-Objekte handelt, die von System.EnterpriseServices.ServicedComponents abgeleitet sind, und die Isolationsebenen zwischen den Transaktionskomponenten übereinstimmen.

Hinweis

Eine atomarische Transaktion kann weder andere Transaktionen noch Ausnahmehandler enthalten.

Hinweis

Eine atomarische Transaktion kann keine zusammengehörigen Sende- und Empfangsaktionen enthalten, d. h. keine Kombinationen von Anforderung/Antwort oder Senden/Empfangen, die denselben Korrelationssatz verwenden.

Nicht serialisierbare Objekte

Wenn Sie in einer Orchestrierung ein nicht serialisierbares Objekt verwenden möchten, darf dies nur innerhalb einer atomarischen Transaktion erfolgen. Bei Verwendung solcher Objekte außerhalb einer atomarischen Transaktion besteht die Gefahr, dass Daten verloren gehen, wenn die Orchestrierung von der Engine persistent gespeichert wird.

Achtung

Jeder atomarische Bereich stellt einen Persistenzspeicherpunkt dar (d. h. an jedem Persistenzspeicherpunkt wird der Status der Orchestrierung in der Datenbank gespeichert). Bei ausgiebiger Verwendung des atomarischen Bereichs erhöht sich die Wartezeit in der Orchestrierung. Anstatt zur Erstellung nicht serialisierbarer Objekte atomarische Bereiche zu verwenden, können Sie statische Methodenaufrufe verwenden, die keine atomarischen Bereiche erfordern, wodurch Persistenzspeicherpunkte überflüssig werden.

Weitere Informationen

Verwendungsszenarios für atomarische Transaktionen
Lang andauernde Transaktionen