Databases Reference
In-Depth Information
Die strengste Anforderung wird mit
SERIALIZABLE
spezifiziert. Nur sie gewährleis-
tet die volle Erfüllung aller Eigenschaften einer Transaktion, die mit dem ACID-
Prinzip umschrieben werden. Die anderen Werte definieren, welche Abweichun-
gen davon zulässig sind.
Wir bezeichnen mit A und B zwei nebenläufige Transaktionen.
READ UNCOMMITTED
Hier kann A Tupel lesen, die von einer zweiten Transaktion B geändert werden,
auch wenn B diese Änderungen noch nicht durch
COMMIT
dauerhaft an die Da-
tenbank übergeben hat oder sie sogar mit
ROLLBACK
zurücknimmt. Dies wird
auch mit dem Begriff
»dirty read
« umschrieben.
READ COMMITTED
Bei dieser Variante ist das
dirty read
ausgeschlossen. A sieht nur solche Daten,
die von B per COMMIT an die Datenbank übergeben werden. Es ist dann aber
möglich, dass zwei identische Lesevorgänge innerhalb von A für dasselbe Tu-
pel zu unterschiedlichen Ergebnissen führen. Der Lesevorgang innerhalb von A
ist also nicht beliebig wiederholbar (
»non repeatable read
«).
REPEATABLE READ
Letzteres ist bei diesem Isolation-Level ausgeschlossen. Es kann aber noch der
Fall eintreten, dass B ein neues Tupel in die von A gelesene Tabelle einfügt, so
dass ein zweiter Lesevorgang innerhalb A ein Tupel findet, das vorher nicht
vorhanden war (
»phantom read
«).
Eine Übersicht über die Isolation-Level und die von ihnen erlaubten Verstöße
gegen das ACID-Prinzip gibt Tabelle 7.1 wieder:
2
Isolation-Level
dirty read
nonrepeatable read
Phantom
J
J
J
READ UNCOMMITTED
READ COMMITTED
N
J
J
N
N
J
REPEATABLE READ
N
N
N
SERIALIZABLE
Tabelle 7.1: Definition der Isolation-Level
Das Lost-Update-Problem wäre bereits mit dem Isolation-Level
REPEATABLE READ
gelöst. Zur Vermeidung der inkonsistenten Analyse muss der Isolation-Level
SERI-
ALIZABLE
angefordert werden. Dabei kann aber der Zugriffsmodus mit
READ ONLY
beschränkt werden, so dass andere, nur lesende Transaktionen zugleich stattfin-
den können, ohne die Serialisierbarkeit zu gefährden.
2
Vgl. [DaDa90 S. 56].
