Modellierung von Transaktionen Zur Formalisierung der ACID-Garantien muss Verhalten von Transaktionen modelliert werden. Folge aus der Forderung nach lokaler.

Präsentation zum Thema: "Modellierung von Transaktionen Zur Formalisierung der ACID-Garantien muss Verhalten von Transaktionen modelliert werden. Folge aus der Forderung nach lokaler."—  Präsentation transkript:

1 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.

2 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.

3 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).

4 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.)

5 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.