Atomicity

Für alle beteiligten Ressourcen werden entweder alle (commit) oder keine der Veränderungen durchgeführt (rollback). Die Veränderungen innerhalb einer Transaktion kommen entweder ganz oder gar nicht zum Tragen.

Dieser Ansatz setzt voraus, dass jede Ressource ihre eigenen Änderungen innerhalb der Transaktion protokolliert. Eine Ressource, die in eine Transaktion involiert ist, besitzt daher einen transaktionalen Zustand (transactional state). Dieser transaktionale Zustand beschreibt die Menge an Änderungen, welche einem commit/rollback unterliegen. Die Art und Weise, wie eine Resource die Änderungen protokolliert, bleibt ihr überlassen. Entscheidend ist, dass im Fall eines commit alle Änderungen durchgeführt werden, bzw. im Fall eines rollback keine der Änderungen aktiv wird.

Consistency

Konsistenz ist eine Anforderungen an die fachliche Logik, die innerhalb einer Transaktion umgesetzt wird, und nicht eine Anforderung an die Transaktion selbst. Transaktionen wissen nichts über die Sematik der Änderungen.

Konsistenz bleibt daher immer Aufgabe der Programmlogik.

Isolation

Zwischenzeitliche Änderungen an der Resource innerhalb der Transaktion sind nur in der Transaktion sichtbar. Relationale Datenbanken bieten i.d.R. unterschiedliche Level von Isolation an ( siehe http://www.oracle.com/technetwork/issue-archive/2010/10-jan/o65asktom-082389.html) , die teilweise lesenden Zugriff auf innerhalb einer anderen Transaktion veränderter Daten zulassen. Mindestens muss aber der Grad an Isolation sicherstellen, dass die Daten, die in einer Transaktion geändert werden, nicht gleichzeitig durch eine andere Transaktion geändert werden können.

Diese Forderung der Isolation wird i.d.R. (zumindest bei vielen Datenbanken, JMS) durch ein pessimistisches Sperrkonzept (locking) umgesetzt. Wird eine Ressource innerhalb Transaktion verändert, so muss diese gegenüber allen anderen Transaktion gegen Änderungen geschützt werden. Dies geschieht, indem sie vor der Änderung gesperrt wird. Pessimistische Sperren müssen vor dem ersten Zugriff auf die zu verändernden Daten gesetzt werden. Als Konsequenz ergibt sich die Gefahr von Deadlocks ( - gegenseitiges Warten unterschiedlicher Transaktionen auf die Aufhebung einer Sperre) und sie können unter ungünstigen Voraussetzungen die Parallelsierung der Verarbeitung stark einschränken.

Insbesondere müssen alle Transaktionen diese Ressource und ihren alle konkurrierend zu verändernden Daten kennen. Dies setzt voraus, dass die Ressource auf einem gemeinsamen, für alle Transaktionen (und damit deren ausführende Prozesse) sichtbaren Datenbestand operiert. Dieser zentralistische Ansatz ist in Zeiten von Big Data nicht immer einzuhalten. Nach dem CAP-Theorem (siehe http://www.allthingsdistributed.com/2007/12/eventually_consistent.html) bedingt dieser Ansatz Abstriche bei der Parallelisierung. Es ist also nicht immer dieses starke Maß an Konsistenz wünschenswert.

Durability

Aus Datenbanken ist bekannt, dass die Änderungen am Datenbestand persistiert werden und nach der erfolgreichen Transaktion außerhalb des verändernden Prozesses bekannt sind. Diese Forderung ist bei den bekannten transaktionalen Ressourcen wie Datenbanken und JMS gegeben.

Es lassen sich aber auch Szenarien von Transaktionen und Ressourcen vorstellen, in denen die Dauerhaftigkeit der Daten keine Rolle spielt. Z.B. spielt die Kopplung des command pattern mit Transaktionen und Persistenzsystemen eine große Rolle, um die Konsistenz von Anwendungen sicherzustellen. Die commands des command pattern werden nicht dauerhaft gespeichert. Daher eignen sich leichtgewichtigere Ansätze, um command pattern in Transaktionen einzubetten.

Zustandsübergänge einer TA-gesicherten Resource

In gupta-1997 Kap 3.2.1 sind die Zustandsübergänge einer transaktionsgesicherten Ressource in einem 2 phase commit-Protokoll beschrieben. (Abort(-ing) entspricht dem gängigeren rollback(-ing).)

Bzgl. des 1 phase commit protocols lassen diese wie in Abbildung 1 reduzieren.

Abbildung 2: Zustandsübergänge bei 2 Phase Commit (nach gupta-1997 Kap 3.2.1)

Verbindungsaufnahme

Eine JTA-Transaktion wartet darauf, dass sich die Ressource bei ihr anmeldet, um an der Transaktion teilzunehmen. Es ist Aufgabe der Ressource zu erkennen, wann sie an einer Transaktion teilnehmen möchte. In diesem Fall meldet sie sich bei der Transaktion an.

Die Anwendungslogik nutzt eine Connection, um mit dieser Verbindung die zugrunde liegende Ressource zu verändern.

Der komplexe Prozess, wie sich die Ressource an einer Transaktion anmeldet und die zugehörige connection aufbaut, läuft versteckt und im Hintergrund ab.

Die Connection wird durch den RessourceManager geliefert. Dieser prüft, ob eine aktuelle Transaktion vorliegt und ob die aktuelle Ressource bereits an dieser teilnimmt. Abbildung 3 zeigt den Anmeldungsprozess, welcher durch die Anforderung einer connection durch die Anwendungslogik ausgelöst wird. Nach dieser Anmeldung hat die Anwendungslogik Zugriff auf eine connection. Die Ressource hat sich mit einer XAResource bei der Transaktion angemeldet und verwaltet die zugehörige connection und damit den transactional state der Ressource bzgl. der Transaktion.

Abbildung 3 : Zugriff auf eine Connection mit Verbindungsaufnahme im Hintergrund

Globale Transaktionen werden via XAResource.start mit einer transaktionalen Ressource verbunden. Zu einem bestimmten Zeitpunkt darf eine connection höchstens einer Transaktion zugeordnet sein.

UserTransaction

Beginn und Ende einer Transaktion (transaction demarcation) können auf unterschiedliche Weise bestimmt werden

• deklarativ
• programmatisch

Der deklarative Weg erlaubt es, Methoden zu annotieren. Diese Annotationen werden durch transaktionale Aspekte ausgewertet und die durch die Aspekte umschlossene Verarbeitung wird innerhalb einer Transaktion ausgeführt.

Das Interface UserTransaction erlaubt es Transaktionsgrenzen programmatisch zu bestimmen. Folgendes Codefragment zeigt den Einsatz von UserTransaction, wobei das UserTransaction-Objekt via JNDI bereitgestellt wird. Dieses Szenario beschreibt den Einsatz innerhalb eines ApplicationServers.

// get the system property value configured by administrator
String utxPropVal = System.getProperty(“jta.UserTransaction”);

// use JNDI to locate the UserTransaction object 
Context ctx = new InitialContext();
UserTransaction utx = (UserTransaction)ctx.lookup(utxPropVal);

// start transaction work..
utx.begin();
... do work
utx.commit();

Transaktion

Ein Transktion wird in JTA durch javax.transaction.Transaction repräsentiert. Durch die statische Methode TransactionManager.getTransaction() wird die für den aktuellen Thread aktive Transaktion vom Transactionmanager bereitgestellt. Er ist für die korrekte Zuordnung zwischen Thread und Transaktion verantwortlich.

Eine Transaction wird durch einen Transaktion-ID identifiziert, die sogenannte XID. Diese wird durch den Transaktionsmanager der XAResource übergeben, wenn diese eine Connection bereitstellen soll.

Integration in JEE

Der Spezifikation JTA 1.2 lässt erkennen, dass diese für den Einsatz in einem ApplicationServer-Szenario ausgerichtet ist. Ist eine Resource gemäß JCA 1.7 entworfen, so wird ihr Lebenszyklus durch den ApplicationServer bestimmt. In JCA 1.7 Cap. 7 ist der Zusammenhang zwischen einer JCA-Resource und einem JTA-TransactionManager beschrieben.

Anforderung an Zustandsprotokollierung

Die Recoveryinformationen müssen bestimmte Bedingungen erfüllen

• rollback data müssen Aktionen beschreiben, welche auf dem Persistenzmedium invertierbar sein.
• Die Aktionen müssen idempotent sein, d.h. eine mehrfache Ausführung der Invertierung muss immer zum selben Ergebnis im Persistenzsystem führen. Dies ist wichtig, wenn beim Recovery Probleme auftreten und das Recovery eventuell wiederholt werden muss.
• Die committing phase wird beim Recovery nicht invertiert, sondern zum vollständigen Abschluss gebracht ( rollforward ). Dabei ist ebenfalls zu berücksichtigen, dass die Aktionen auch nur teilweise durchgeführt wurden. Auch dies muss durch das Recoreyprotokoll unterstützt werden.

Anforderungen an eine Protokollierung

Sind die Inhalte des Recoveryprotokolls auch spezifisch für jedes Persistenzsystem, so kann das Verfahren der Protokollierung selbst sehr wohl allgemein zur Verfügung gestellt werden. Es müssen folgende Anforderungen an eine allgemeines Verfahren zur Protokollierung erfüllt sein :

1. dauerhafte und atomare Protokollierung
2. performante, konkurrierende Protokollierung

Punkt (1) ist eine Grundvorausetzung für einen Protokollmechanismus. Die Daten müssen einem späteren Recovery zur Verfügung stehen und müssen daher persistiert werden. Falls bei der Protokollierung Fehler auftreten, so führt dies zum Abbruch der Transaktion. Um das Protokoll konsistent und korrekt zu halten, muss das Schreiben des Protokolls atomar sein. Daten müssen entweder ganz oder gar nicht geschrieben werden.

Phynixx stellt ein solches Protokollierungsverfahren zur Verfügung, welches durch ResourceManager genutzt werden kann. Eine connection protokolliert ihre rollforward/rollback data über ein definiertes Interface und Phynixx stellt sicher, dass die Informationen für ein eventuelles Recovery bereit stehen. Der Inhalt und die Bedeutung der Protokolldaten unterscheiden sich wiederum zwischen den Persistenzsystem und daher muss das Recoveryprotokoll jeweils für jedes Persistenzsysten spezifisch entworfen werden.

In Tutorial (siehe Tutorial) wird gezeigt, wie sequentielles Schreiben in eine Datei transaktional mit Phynixx unterstützt wird. Insbesondere wird dort gezeigt, wie das Recoveryprotokoll für diese Ressource aussieht und wie der allgemeine Protokollierungsmechanismus von Phynixx angesprochen wird.

Recorveryinformationen

Eine XAResource wird zu einem Recoveryfall, wenn einer der folgenden Situationen eintritt

• Ressource verabschiedet sich undefiniert aus der Transaktion
• Ausführungsthread/ -prozess stirbt wegen Verbindungverlust zu Servern (Datenbanken,..),Plattencrash, Stromausfall oder ähnliche apokalyptische Szenarien
• Transaktionsmanager verabschiedet sich undefiniert, weil Ausführungsthread/ -prozess stirbt. Gründe können auch hier Hardwarefehler wie Plattencrash, Stromausfall oder ähnliche Szenarien sein. Insbesondere im Fall von verteilten Transaktionen kann der Transaktionmaneger in anderen Prozessen/Knoten ausgeführt werden als die transaktionale Resource.

Unabhängig von dem Zustand (siehe Abbildung 4/5), in dem sich die Ressource beim Abbruch der Transaktion befunden hat, läßt sich allein aus den Recoveryinformationen ableiten, was beim Recovery zu tun ist.

1. Falls rollforward data vorliegen, wird rollforward durchgeführt. Eventuell vorhanden rollback data werden ignoriert.
2. Falls rollback data vorhanden sind, so wird ein rollback durch geführt.

Integration in das Recoverykonzept des Transaktiomanagers ( nach JTA)

coming soon

Transaktionale Ressource

Wie oben beschrieben, beinhaltet der transaktionale Zustand einer Ressource die Daten, welche durch ein Commit/Rollback betroffen sind. Dieser wird durch eine connection repräsentiert. Eine XAResource stellt die Verbindung einer Transaktion und einer connection her. Auf den ersten Augenschein sollte man meinen, dass eine XAResource höchstens eine resource connection besitzen kann, denn sie kann nicht an mehr als einer aktiven Transaktion teilnehmen.

Transaktionen können allerdings unterbrochen (suspend) und zu einem späteren Zeitpunkt wieder aktiviert (resume) werden.
Ist eine XAResource bereits an eine Transaktion gebunden und soll diese Ressource an einer weiteren Transaktion teilnehmen, so kann die bisherige Transaktion entweder beendet oder unterbrochen werden (suspend). In beiden Fällen wird XAResource.end() (mit jeweils unterschiedlichen Parametern ) gerufen. Im Fall von suspend bleibt die dieser Transaktion zugeordnete Connection weiterhin bestehen. Eine XAResource muss also intern wissen, welche connection welcher Transaktion (identifiziert durch XID) zugeordnet ist. Die Verbindnung zwischen connection und Transaktion heißt transational resource.

Eine XAResource ordnet jeder XID, an der sie beteilig ist, die passende connection zu.

Das Commit auf der aktiven Transaktion darf nur die Änderungen bestätigen, die im Rahmen dieser Transaktion vorgenommen wurden. Änderungen an suspended Transaktionen müssen unbenommen bleiben. Daher muss die XAResource in diesem Fall zwei transaktionale Ressourcen unterstützen.

Der einer XAResource zugeordnete transaktionale Kontext wird über Transaktion (genauer die XID) qualifiziert. Mit den Angaben (XAResource, XID) wird die transaktionale Ressource qualifiziert. Es bedarf beider Angaben, um diese zu bestimmen.

Identifizierungen von ResourceManagern

Falls sich zwei unterschiedliche Instanzen von XAResource des selben ResourceManagers an einer Transaktion beteiligen, so sollten deren transaktionale Zustände zusammengefasst werden und sie sich ihre connection teilen. Um zu entscheiden, ob zwei XAResource-instanzen vom selben ResourceManager stammen, implementieren diese XAResource.isSameRM().

Anforderungen an die Zuordnung von XAResource und transaktionalem Kontext

Entgegen ersten Eindrücken entspricht eine XAResource nicht immer genau einer connection. Folgende Situationen können diese Zuordnungen beinflussen

• XAResource nimmt an einer zeitweilig stillgelegten Transaktion (suspended) und einer aktiven Transaktion teil.
• In einer Transaktion werden unterschiedliche XAResourcen zu einem transaktionalen Kontext zusammengefasst. Falls die XAResourcen im Sinne von isSameRM gleich sind, so werden diese zusammengefasst (start(.., TMJOIN)

Der transaktionale Zustand (==connection) entspricht pro Ressource der XID. Eine XAResource kann mehreren *XID*s zugeordnet sein und umgekehrt kann sich XID auf mehrere XAResourcen beziehen.

Der ResourceManager muss diese Beziehung im Hintergrund intern verwalten. Die jeweiligen Anlässe für die Aktualisierungen dieser Zuorndungen werden durch den Transaktionmanager geliefert.

Lokale Transaktionen in JTA

Gemäß JTA 1.2 Chap. 3.4.7 soll ein ResourceManager sowohl lokale als auch globale Transaktionen unterstützen. Während lokale Transaktionen durch den Resourcemanager intern gestartet werden, werden globale Transaktionen durch einen Transaktionsmanager koordiniert, welcher mittels XAResource mit dem ResourceManager kommuniziert. Für die Koexistenz von lokalen und globalen Transaktionen gelten laut JTA 1.2 3.4.7 folgende Anforderungen + Die lokale Transaktion muss abgeschlossen sein, bevor bzgl der gleichen connection eine globale Transaktion gestartet werden kann. + Die globale Transaktion muss von der connection getrennt sein, bevor eine lokale Transaktion geöffnet sein darf.

Es ist Aufgabe des ResourceManager, jeweils zu entscheiden, ob die angeforderte connection an einer lokalen oder globalen Transaktion teilnimmt. Er hat die oben genannten Regeln für die Koexistenz zu beachten.

Recovery in JTA

Der JTA-Recoveryprozess sieht vor, dass der TransaktionsManager die Resourcen nach Transaktionen befragt, die noch nicht abgeschlossen sind.

siehe http://docs.oracle.com/cd/E12839_01/web.1111/e13731/jtatxexp.htm#WLJTA288

When implementing XAResource.recover, you should use the flags as described in the X/Open XA specification as follows: + When the WebLogic Server transaction manager calls XAResource.recover with TMSTARTRSCAN, the resource returns the first batch of in-doubt Xids.

• The WebLogic Server transaction manager then calls XAResource.recover with TMNOFLAGS repeatedly, until the resource returns either null or a zero-length array to signal that there are no more Xids to recover. If the resource has already returned all the Xids in the previous XAResource.recover(TMSTARTRSCAN) call, then it can either return null or a zero-length array here, or it may also throw XAER_PROTO, to indicate that it has already finished and forgotten the previous recovery scan. A common XAResource.recover implementation problem is ignoring the flags or always returning the same set of Xids on XAResource.recover(TMNOFLAGS). This will cause the WebLogic Server transaction manager recovery to loop infinitely, and subsequently fail.

• The WebLogic Server transaction manager XAResource.recover with TMENDRSCAN flag to end the recovery scan. The resource may return additional Xids.

siehe auch [docs.jboss.org/jbosstm/5.0.0.M1/guides/failure_recovery_guide/ch02.html](docs.jboss.org/jbosstm/5.0.0.M1/guides/failure_recovery_guide/ ch02.html “docs.jboss.org/jbosstm/5.0.0.M1/guides/failure_recovery_guide/ch02.html”)

Insbesondere müssen die Recoveryinformationen im Fall eine 2 phase commit-Transaktion die aktuelle Transaktion (d.h. XID) kennen, um diese Beziehung wieder herstellen zu können.

Die Spezifikation macht keine Aussagen über der Recoveryprozess selbst oder über Schnittstellen, diesen anzusprechen oder aufzurufen. Daher implementiert jeder JTA-Transaktionsmanager seinen eigenen Recoverymanager, der den Recoverprozeß steuert und ausführt.

Aufgaben der Integration JTA

• Imnplementierung eines XAResource
• Managements der Zuordnung zwischen XAResource und transaktionaler resource
• Managements der Zuordnung zwischen connection und aktueller Transaktion
• Teilnahme an lokalen und globalen Transaktionen
• Unterstützungen des Recoveryprotokolls in JTA 1.2
• Integrationsszenarien mit Spring
• Integrationsszenarien in JEE und JCA

Phynixx unterstützt all diese Anforderungen vollständig. In Tutorial wird demonstriert, wie eine JTA-konforme Ressource entwickelt werden kann. Mehr Informationen zu Integrationsszenarien in Spring Integration und zu JEE Integration.