Ausführungsmodell Zustandsübergang einer Transaktion aus Nutzersicht: NULL Arbeitsbeginn aktiv Aufräumen Rücksetzen Aufräumen Festschreiben dauerhaft gescheitert

Transaktionsgeschützter SQL-Dialog Erste SQL-Anfrage Beginn der ersten Transaktion Folge von SQL-Anfragen commit Festschreiben Nächste SQL-Anfrage Beginn der nächsten Transaktion rollback Rücksetzen zum vorhergehenden commit ......

Konsistenzklassen für Transaktionen (1) Grundsatz: Der im Schema vereinbarte Grad an Datenbasiskonsistenz (Schemakonsistenz, Konsistenzbedingungen, Transaktionsprozeduren) wird immer garantiert  die Datenbasis wird nicht korrumpiert. Freiräume: Grad an Konsistenz, der beim Lesen garantiert wird. Er ist durch das Maß an durchgesetzter Isolation definiert.

Konsistenzklassen für Transaktionen (2) Ebene 1: Dirty Read erlaubt. Nebenläufige Transaktionen werden nicht aufgehalten. Die durch sie bewirkten Zustände sind sichtbar, auch auf das Risiko eines Abbruchs einer nebenläufigen Transaktion. Ebene 2: Non-repeatable Read erlaubt. Nebenläufige Transaktionen werden nicht aufgehalten. Die durch sie bewirkten Zustände sind sichtbar, wenn sie vor Beginn oder nach erfolgreichem Abschluss einer nebenläufigen Transaktion gelten. Die Transaktion sieht u.U. einen zeitlich verschmierten Zustand. Ebene 3: Phantome erlaubt. Nebenläufige Transaktionen werden aufgehalten. Durch sie neu eingebrachte Zustände sind sichtbar, sobald die nebenläufige Transaktion zum erfolgreichen Abschluss kommt. Ebene 4: Unbedingte Isolation.

Vereinbarung bei Transaktionsprozeduren set transaction sperrenart, konsistenzebene read only read write read uncommitted Ebene 1 read committed Ebene 2 repeatable read Ebene 3 serializable Ebene 4 Beachte von der Literatur abweichende Terminologie!

Transaktionen bei ODMG (1) Transaktionen sind selbst Objekte, die man zunächst erzeugen muss, bevor man sie startet, abschließt oder abbricht Erzeugen, Modifizieren, Lesen und Löschen persistenter Objekte nur innerhalb von Transaktionen möglich interface TransactionFactory { Transaction new(); }; interface Transaction { ... void begin(); void commit(); void abort(); boolean isOpen(); ... };

Transaktionen bei ODMG (2) Verbot des Zugriffs auf persistente Objekte außerhalb von Transaktionen ist recht hinderlich. Typisches Szenario: Applikation öffnet DB, navigiert zu bestimmten Objekten. Applikation liest Objekte aus DB und präsentiert sie Benutzer. Benutzer modifiziert Objekte. Applikation schreibt Objekte zurück. Zwei Transaktions-Strategien möglich, beide unangenehm: Transaktion bleibt während Benutzer-Interaktion offen (aber was ist, wenn Benutzer in Urlaub fährt?). Zurückschreiben der Daten erfolgt in separater Transaktion (aber dann muss die gesamte Navigation wiederholt werden).

Transaktionen bei ODMG (3) Ausweg (nur in bestimmten ODBMS, nicht ODMG-konform!): Nach Transaktionsende bleiben Verweise auf Hauptspeicherkopien persistenter Objekte gültig. Hauptspeicherkopien sind jedoch außerhalb von Transaktionen von unterliegenden persistenten Objekten abgekoppelt. Bei Neubeginn einer Transaktion erfolgt automatischer Zustandsabgleich mit unterliegenden persistenten Objekten.

Transaktionen bei ODMG (4) Transaktions-Strategie nun: Lese Objekte in kurzer Lesetransaktion, aber behalte nach Transaktionsende Verweise auf Kopien im Hauptspeicher. Nach Abschluss der Benutzer-Interaktion beginne Schreibtransaktion und bringe Änderungen direkt in Hauptspeicherkopien ein, deren Verweise ja noch existieren.

Transaktionen bei ODMG (5) Bewertung: Vorteil: Effizienterer und einfacherer Code: Zweite Navigationsphase beim Schreiben wird erspart. Höhere Programmschichten müssen nicht darauf ausgerichtet sein, dass ihre Verweise fortlaufend ungültig werden. Nachteil: Schwerwiegende semantische Probleme: Von anderen Benutzern zwischenzeitlich eingebrachte Änderungen können überschrieben werden. Hauptspeicherkopien reflektieren möglicherweise Verweisketten und Objekte, die in unterliegender Datenbasis gar nicht mehr existieren. Grund: Isolation wurde aufgegeben. Insgesamt eher als Hack einzustufen, Anwendung nur nach sorgfältiger Analyse aller potentiell nebenläufigen Zugriffe.