Modellierung von Transaktionen Zur Formalisierung der ACID-Garantien muss Verhalten von Transaktionen modelliert werden. Folge aus der Forderung nach lokaler Konsistenz: Die Transaktionsverwaltung soll nichts über die Semantik der TA wissen müssen. Annahme: Die TA teilt der TAV auch nichts darüber mit. Folge: Die TAV ist auf das beobachtbare Verhalten der TA angewiesen: Dies sind die Bekanntgabe der Transaktionsgrenzen sowie die Transportvorgänge zwischen Arbeitsspeicher der TA und dem Hintergrundspeicher, also die individuellen Lese- und Schreibzugriffe.

Lese-Schreib-Modell Transaktionsverwaltung eines DBMS arbeitet daher mit einfachem Lese-Schreib-Modell von Transaktionen: –Bearbeitung der Daten erfolgt in einem privaten Arbeitsspeicherbereich der Transaktion. –Transaktionen können durch Operationen read(x) und write(x) Transfer eines Datenelements x (z.B. Block, Tupel oder Relation) vom Hintergrund- in den Arbeitsspeicher und umgekehrt anfordern. –Transaktionen können durch Operationen commit und abort erfolgreichen bzw. nicht erfolgreichen Abschluss mitteilen. Im ersten Fall müssen alle durchgeführten write-Operationen dauerhaft, im zweiten rückgängig gemacht werden. –Interaktion von Transaktionen mit der Datenbasis beschränkt sich auf die Operationen read, write, commit und abort. Nur diese werden von der Transaktionsverwaltung bearbeitet.

Implikationen des Lese-Schreib- Modells Information über TA-Semantik geht verloren: –TA-Verwaltung muss davon ausgehen, dass abgesetzte Folge von read, write, commit bzw. abort-Operationen intendierten Zustandsübergang einer Transaktion reflektiert; fälschlich abgesetzte Operationen (z.B. durch Programmierfehler) werden nicht erkannt. –Da innere Zusammenhänge einer Transaktion nicht bekannt sind, muss worst case-Annahme getroffen werden: Jeder geschriebene Wert hängt von allen bisher gelesenen Werten ab. Interaktion Transaktion Außenwelt wird nicht erfasst: –Transaktionen können unumkehrbare Effekte in der Außenwelt auslösen (z.B. Ausgabe von Geld an einem Geldautomaten).

Formale Beschreibung von Transaktionen (1) Eine Operation o hat eine der folgenden vier Formen: –r i (x)Lesen von Datenelement x durch Transaktion i –w i (x)Schreiben von Datenelement x durch Transaktion i –c i Abschluss von Transaktion i –a i Abbruch von Transaktion i (Wenn es auf Details nicht ankommt, werden Operationen kurz als o i bzw. o i (x) notiert.)

Formale Beschreibung von Transaktionen (2) Eine Transaktionsbeschreibung (kurz: Transaktion) ist eine total geordnete Menge T i von Operationen mit: –T i {r i (x), w i (x) | x Datenelement} {a i,c i }. –T i kann höchstens eine der Operationen a i oder c i enthalten. –Falls T i a i oder c i enthält, so ist dies die letzte Operation in T i. –Falls es o,o' T i gibt mit o = r i (x), o' = w i (x), so folgt o < o'. Konsequenzen aus Definition: –Transaktion kann, muss aber nicht abgeschlossen sein. –Mehrfaches Lesen oder Schreiben desselben Datums nicht zulässig. –Schreiben und anschließendes Lesen eines Datums nicht zulässig.