Eine kleine Geschichte der Transaktionen (1. Grundlagen )

Zur Einführung sollte ich wohl zuerst definieren was man eigentlich unter einer Transaktion in der bunten Welt des Programmierens und der Datenbanken versteht. Hierzu schnell in Wikipedia nachgeschaut und die Erklärung, die man dort findet, ist wie folgt:

“Eine Transaktion bezeichnet eine Menge von Datenbankänderungen, die zusammen ausgeführt werden (müssen). So ist beispielsweise die Buchung (als Transaktion) eines Geldbetrags durch zwei atomare Datenbankoperationen „Abbuchen des Geldbetrages von Konto A“ und „Buchung des Geldbetrages auf Konto B“ gekennzeichnet. Kann die vollständige Abarbeitung der elementaren Datenbankoperationen der Transaktion nicht durchgeführt werden (z. B. aufgrund eines Fehlers), müssen alle durchgeführten Änderungen an dem Datenbestand auf den Ausgangszustand zurückgesetzt werden.

Der Vorgang, der alle Änderungen einer Transaktion zurücksetzt, wird als Rollback bezeichnet. Der Begriff Commit bezeichnet das Ausführen einer Transaktion. Transaktionen sind eine Möglichkeit, die Konsistenz des Datenbestandes zu sichern. Im Beispiel der doppelten Kontenführung wird durch das Verhindern von ungültigen Teilbuchungen eine ausgeglichene Kontobilanz gewährleistet.”

Man könnte also auch sagen, dass man mehrere Operationen zu einer atomaren Ausführung zusammenfassen kann, damit entweder alle Änderungen bzw. Operationen durchgeführt werden oder gar keine. Das bedeutet, dass bei einem Rollback zwischenzeitlich durchgeführte Änderungen wieder rückgängig gemacht werden müssen.

Was oft auch benutzt wird ist der Begriff ACID, wobei hier nicht irgendwelche bewusstseinserweiternde Stoffe gemeint sind, sondern ACID als Abkürzung für:

• Atomicity - eine Transaktion wird entweder "comitted" oder "aborted". Wenn eine Transaktion ein Commit ausführt, bleiben alle ihre Änderungen erhalten; Wenn eine Transaktion abgebrochen wird, werden alle Änderungen rückgängig gemacht.
• Consistency - eine Transaktion ist eine korrekte Transformation des Systemstatus; Sie stellt sicher, dass das System in einem konsistenten Zustand bleibt. Beispielsweise wenn man in einer doppelt verknüpften Liste ein Element hinzufügt, werden alle vier vorwärts- und Rückwärts-Zeiger aktualisiert.
• Isolation - gleichzeitige Transaktionen sind isoliert von den Updates der anderen unvollständigen Transaktionen; Diese Updates stellen keinen konsistenten Zustand dar. Diese Eigenschaft wird oft Serialisierbarkeit genannt. Zum Beispiel wenn eine zweite Transaktion auf die doppelt verknüpfte Liste aus dem vorigen Consistency Beispiel zugreift, sieht entweder den Zustand vor den Änderungen, oder den Zustand nachdem alle Änderungen durchgeführt sind, also niemals einen Zustand dazwischen.
• Durability - sobald eine Transaktion ein Commit ausgeführt hat, bleibt der Zustand bestehen, auch wenn es Systemausfälle geben sollte.

In manchen Anwendungsfällen wird aber nicht der volle “Schutz” einer Transaktion benötigt. Dafür gibt es im SQL Standard verschiedene Einstellungen um verschiedene Isolation Level zu definieren.

So jetzt muss ich natürlich noch erklären was die Begriffe Dirty Read, Nonrepeadable Read und Phantom Rows bedeuten.

Dirty Read - Wenn eine Transaktion „uncommitted“ Änderungen einer anderen Transaktion lesen kann.

Nonrepeadable Read - Wenn von Transaktion A bereits gelesene Daten von Transaktion B modifiziert werden, bevor Transaktion A abgeschlossen ist.

Phantom Rows - Wenn Transaktion A das Resultat einer Abfrage auswertet und dann Transaktion B eine Zeile einfügt, welche die Kriterien erfüllt, um in das Resultat der Abfrage von Transaktion A zu gehören, bevor Transaktion A abgeschlossen ist.

Der Ausdruck kommt daher, wenn Transaktion A die Abfrage ein zweites mal ausführen würde, wäre eine neue Zeile wie ein Phantom im Resultat aufgetaucht.

So das war es fürs Erste. In der nächsten Folge möchte ich mich dann mit APIs auseinandersetzen, die es dem Entwickler ermöglichen Transaktionen in eigenen Anwendungen zu verwenden.

Bis demnächst Euer Martin