Als Transaktion (von lateinisch trans „(hin-)über“, agere „treiben, handeln, führen“: also wörtlich: Überführung; dt. hier besser: Durchführung) wird in der Informatik eine Folge von Programmschritten bezeichnet, die als eine logische Einheit betrachtet werden, weil sie den Datenbestand nach fehlerfreier und vollständiger Ausführung in einem konsistenten Zustand hinterlassen. Daher wird für eine Transaktion insbesondere gefordert, dass sie entweder vollständig und fehlerfrei oder gar nicht ausgeführt wird.

Transaktionen kommen meist bei Datenbanksystemen zum Einsatz. Fehlerhafte Transaktionen müssen abgebrochen und die bisherigen Änderungen in der Datenbank rückgängig gemacht werden, so dass sie keine Auswirkungen auf den Zustand der Datenbank haben. Transaktionen werden von Transaktionssystemen verarbeitet; diese erzeugen dabei aus mehreren Transaktionen eine Historie.

Beispiel

Um sich die wichtigsten Begriffe dieses Artikels anschaulich vorstellen zu können, soll folgendes Beispiel dienen:

In einer Bücherei wird ein Karteikarten-System zur Verwaltung des Bestandes an Büchern verwendet. Eine Transaktion könnte hier lauten: „Das Buch ‚Die Schatzinsel‘ an den Benutzer Peter Müller ausleihen.“ Diese Transaktion könnte in der formalen Darstellung so aussehen:

Anfang der Transaktion

das Feld „Vorbestellung“ der Karte lesen

„Peter Müller“ in das Feld „ausgeliehen von“ schreiben

„29. Juli 2001“ in das Feld „Rückgabe am“ schreiben

Ende der Transaktion

Konnte die Karte erfolgreich ausgefüllt werden, so ist die Transaktion abgeschlossen und die Karte wird in den Karteikasten zurückgesteckt – dies entspricht dem Commit einer Transaktion. Wurde die Ausführung unterbrochen, so müssen alle bis dahin getätigten Änderungen rückgängig gemacht werden, bevor die Karte zurückgesteckt wird – dies entspricht dem Abort einer Transaktion. Wird dies nicht gemacht, so können Fehler auftreten: Falls etwa „ausgeliehen von“ bereits ausgefüllt ist, das Rückgabedatum aber noch nicht eingetragen wurde, so kann sich Peter Müller bis an sein Lebensende an der „Schatzinsel“ erfreuen, ohne Strafgebühren fürchten zu müssen. Zu einem Konflikt zwischen Transaktionen käme es beispielsweise, wenn das Buch gleichzeitig an einen anderen Benutzer verliehen werden sollte; hier würde die Eigenschaft „Isolation“ verletzt.

Aufbau von Transaktionen

Transaktionen werden durch die Markierungen begin of transaction (Abk. BOT) und end of transaction (Abk. EOT, s. Commit) abgegrenzt:

begin of transaction
   read x
   write y
end of transaction

Die Operationen innerhalb einer Transaktion sind geordnet, ihre Reihenfolge darf also nicht verändert werden. Die Ordnung der Operationen einer Transaktion kann auch als gerichteter Graph dargestellt werden:

${\displaystyle {\begin{matrix}r[x]&\rightarrow &w[x]&\rightarrow &r[y]&\rightarrow &c\\&&&\nearrow \\&&r[z]\end{matrix}}}$

Diese Darstellung betont die Nebenläufigkeit – also die gleichzeitige Ausführbarkeit – von Operationen. In obigem Beispiel kann die Operation r[z] gleichzeitig mit den Operationen r[x] und w[x] ausgeführt werden.

ACID-Prinzip

Bei der Ausführung von Transaktionen muss das Transaktionssystem die ACID-Eigenschaften garantieren:

• Atomarität (Atomicity): Eine Transaktion wird entweder ganz oder gar nicht ausgeführt. Transaktionen sind also „unteilbar“. Wenn eine atomare Transaktion abgebrochen wird, ist das System unverändert.
• Konsistenz (Consistency): Nach Ausführung der Transaktion muss der Datenbestand in einer konsistenten Form sein, wenn er es bereits zu Beginn der Transaktion war.
• Isolation (Isolation): Bei gleichzeitiger Ausführung mehrerer Transaktionen dürfen sich diese nicht gegenseitig beeinflussen.
• Dauerhaftigkeit (Durability): Die Auswirkungen einer Transaktion müssen im Datenbestand dauerhaft bestehen bleiben. Die Effekte von Transaktionen dürfen also nicht verloren gehen oder mit der Zeit verblassen. Eine Verschachtelung von Transaktionen ist wegen dieser Eigenschaft streng genommen nicht möglich, da ein Zurücksetzen (Rollback) einer äußeren die Dauerhaftigkeit einer inneren, bereits ausgeführten Transaktion verletzen würde.

Ausführung von Transaktionen in einem Transaktionssystem

Ziel eines Transaktionssystems ist es stets, möglichst viele Transaktionen in möglichst kurzer Zeit abzuwickeln. Die serielle Ausführung von Transaktionen – also die Ausführung der Transaktionen nacheinander – ist zwar einfach zu realisieren, führt aber oft nicht zu einer optimalen Erfüllung dieses Leistungskriteriums. Transaktionssysteme spalten daher Transaktionen in ihre Operationen auf und setzen diese zu Historien zusammen, wobei die ACID-Eigenschaften bewahrt bleiben müssen.

Durch diesen Vorgang ergeben sich zwei Möglichkeiten, eine Transaktion zu beenden:

• Commit (abschließen, Abk. c): Die Transaktion wurde erfolgreich und ohne Probleme beendet, die Auswirkungen der Transaktion auf den Datenbestand werden dauerhaft gespeichert. Oft werden die Begriffe „commit“ und „end of transaction“ synonym verwendet.
• Abort (abbrechen, Abk. a): Bei der Ausführung der Transaktion sind Probleme aufgetreten, ihre Ausführung wird nicht fortgesetzt. Die Bedingung der Atomarität fordert zusätzlich, dass sämtliche Auswirkungen der Transaktion auf den Datenbestand rückgängig gemacht werden müssen.

Das Rückgängigmachen der Effekte einer Transaktion wird als Rollback (Zurücksetzen) bezeichnet. Es kann dabei vorkommen, dass das Zurücksetzen einer Transaktion das Zurücksetzen einer anderen Transaktion notwendig macht, was zur Bildung regelrechter Ketten von Zurücksetzungen führen kann; dies wird als kaskadierendes Rücksetzen bezeichnet.

Wenn eine Transaktion aufgrund einer anderen Transaktion nicht ausgeführt werden kann, spricht man von einer Blockierung. Wird die erste Transaktion durch die zweite und gleichzeitig die zweite durch die erste blockiert, so spricht man von einem Deadlock (Verklemmung).

Verschachtelte Transaktionen

Eine verschachtelte Transaktion ist eine Transaktion, die vollständig von einer anderen Transaktion umschlossen wird. Die innere Transaktion sieht die Veränderungen, die von der äußeren gemacht werden. Für das Verhalten der beiden Transaktionen gibt es mehrere Varianten.

Falls die Transaktionen flach sind, führt der Abbruch der inneren Transaktion auch zu einem Abbruch der äußeren Transaktion. Die Änderungen der inneren Transaktion sind nicht gültig falls die äußere Transaktion nicht erfolgreich abgeschlossen wird.

Sind die Transaktionen geschlossen, führt ein Abbruch der inneren Transaktion nicht automatisch zu einem Abbruch der äußeren Transaktion. Schließt die innere Transaktion ihre Aktionen erfolgreich ab, sind die gemachten Änderungen nur für die äußere Transaktion sichtbar. Für das ganze System ist die Änderung erst sichtbar, wenn die äußerste Transaktion erfolgreich terminiert.

Im Gegensatz dazu wird bei offenen Transaktionen die Änderung der inneren Transaktion sofort nach deren Termination im ganzen System sichtbar. Diese Änderungen bleiben bestehen auch wenn die äußere Transaktion später abgebrochen wird.

Verteilte Transaktionen

Verteilte Transaktionen sind Transaktionen, die in mehreren Teiltransaktionen in verteilten Systemen ausgeführt werden. Um die Atomarität verteilter Transaktionen zu gewährleisten, werden entsprechende Commit-Protokolle verwendet. Ein Beispiel ist die Durchführung einer Überweisung auf dem Datenbanksystem der Bank des Überweisers und dem Datenbanksystem der Bank des Empfängers. Geht nach dem Geldtransfer auf der zweiten Bank etwas schief (z. B. Kontonummer ist ungültig), muss das Geld automatisch wieder zurücküberwiesen werden.

Wirkungslose Transaktionen

Eine Transaktion innerhalb eines Schedules wird als wirkungslos bezeichnet, wenn sie eine der folgenden Bedingungen erfüllt:

• es werden ausschließlich Leseoperationen ausgeführt
• es werden ausschließlich Schreiboperationen ausgeführt und die geschriebenen Werte werden – ohne zwischenzeitlich ausgelesen zu werden – von anderen Transaktionen wieder überschrieben (z. B. Daten für Kontrollzwecke wie Datum / Zeit der letzten Änderung)

Wirkungslos bedeutet, dass die Transaktionen keinen Einfluss auf den Datenbestand der Datenbank hatte. Wirkungslose Transaktionen müssen demnach bei einem Rollback nicht zurückgesetzt werden.

Siehe auch

• Transaktionsprotokoll
• Atomare Operation
• Distributed Transaction Coordinator
• Protokoll
• Transaktionsmonitor
• X/Open XA