studyklar
IProg · Skript 9 · Abschnitt 8

Isolation Level: wie getrennt Transaktionen laufen

Laufen zwei Transaktionen gleichzeitig, können sie sich stören. Hier stehen die drei Störungen und die vier Isolation Level, die festlegen, welche davon noch möglich sind. Mit Weiter geht es Schritt für Schritt voran. Ein Klick auf einen Schritt springt direkt dorthin.

Worum es geht

Skript 09, Folien 25 bis 27: Definition von Isolation Level in SQL, Bedeutung der Isolation Level, Umsetzung in Java JDBC.

Isolation verlangt: Jede Transaktion läuft, als wäre sie allein. Ganz streng kostet das Zeit, denn dann müssen andere warten. Die Frage dieses Abschnitts: Welche Störungen gibt es, und wie viel davon lässt man zu?

Aus Skript 09, Folie 24: Isolation: Eine Transaktion muss so ablaufen, als ob sie allein auf der Datenbank arbeitet. Transaktionen müssen serialisierbar sein, also dasselbe Ergebnis liefern wie nacheinander.

Ergänzung zum Skript: Folie 26 nennt die drei Störungen nur beim Namen. Die Beispiele mit der Tabelle Konto (Kontonummer knr, Stand in Euro) sind von uns. T1 und T2 sind zwei Transaktionen, die gleichzeitig laufen.

Abweichung vom Skript: Folie 27 zählt TRANSACTION_NONE zu den zulässigen Werten zum Setzen. Das stimmt nicht; Schritt 7 erklärt, wofür es steht.

So gehen wir vor:

  1. Die drei Störungen an je einem Ablauf.
  2. Der SQL-Befehl SET TRANSACTION.
  3. Die vier Isolation Level und was sie zulassen.
  4. Das Level in JDBC setzen.
  5. Eine Klausurfrage dazu.

Dirty Read: ungültige Daten lesen

ZeitTransaktion T1Transaktion T2
1setzt Konto 1 auf 100 € (kein commit)
2liest Konto 1: 100 €
3rollback: Konto 1 wieder 300 €

T1 setzt Konto 1 auf 100 €, hat aber noch nicht festgeschrieben (kein commit). T2 liest genau jetzt und sieht 100 €. Dann bricht T1 mit rollback ab: Konto 1 hat wieder 300 €.

T2 hat mit 100 € gerechnet, die nie gültig waren. Das heißt Dirty Read, „schmutziges Lesen“: Lesen von Daten, die noch nicht festgeschrieben sind.

Nonrepeatable Read: zweimal lesen, zwei Werte

ZeitTransaktion T1Transaktion T2
1liest Konto 1: 300 €
2setzt Konto 1 auf 100 €, commit
3liest Konto 1 noch einmal: 100 €

T2 liest Konto 1 und sieht 300 €. Dazwischen setzt T1 den Stand auf 100 € und schreibt fest. T2 liest dieselbe Zeile noch einmal und sieht jetzt 100 €.

Diesmal war jeder gelesene Wert gültig. Aber innerhalb von T2 lässt sich das Lesen nicht wiederholen: Nonrepeatable Read, „nicht wiederholbares Lesen“. T2 sieht also nicht mehr einen festen Stand der Datenbank.

Noch 8 Schritte bis zum Ergebnis
Den ganzen Lösungsweg sehen Studierende und Lehrende der HS KL. Registriere dich mit deiner Adresse @stud.hs-kl.de oder @hs-kl.de, dann geht es hier direkt weiter.

Abbildung 1

knrstand in €
1300
2300
Legendemarkierte Code-ZeilenZwei Konten mit je 300 €.