Isolation

Problem

Zwei Personen versuchen gleichzeitig, das letzte Ticket zu kaufen. Beide Transaktionen lesen: Verbleibende Tickets: 1 Beide kommen zu dem Schluss, dass sie es kaufen können. Gleichzeitige Operationen können die Annahmen des jeweils anderen beeinträchtigen.

Lösung — Transaktionsisolierung

Die Datenbank steuert, welche Änderungen gleichzeitig laufende Transaktionen sehen dürfen und wie ihre Zugriffe zusammenwirken. Unterschiedliche Isolationsstufen bieten unterschiedlich starke Garantien und beeinflussen Nebenläufigkeit und Kosten. Read Uncommitted: Kann die unvollendeten Änderungen einer anderen Transaktion lesen, auch wenn sie später zurückgesetzt werden. Read Committed: Liest nur bestätigte Änderungen anderer Transaktionen; eine wiederholte Abfrage kann neuere Daten liefern. Repeatable Read: Bereits gelesene Daten bleiben innerhalb der Transaktion gegenüber fremden Änderungen stabil. Je nach Datenbank kann dieselbe Abfrage später zusätzliche passende Zeilen finden. Read Committed und Repeatable Read schützen beide vor unbestätigten Änderungen anderer Transaktionen. Repeatable Read hält zusätzlich bereits gelesene Daten innerhalb der eigenen Transaktion stabil. Serializable: Bestätigte Ergebnisse entsprechen einer Ausführung der Transaktionen nacheinander. Die Datenbank lässt konkurrierende Transaktionen dafür gegebenenfalls warten oder bricht sie ab, damit die Anwendung sie wiederholen kann. Das genaue Verhalten hängt von der Datenbank ab. PostgreSQL behandelt Read Uncommitted beispielsweise wie Read Committed und verhindert unter Repeatable Read auch neu erscheinende passende Zeilen.
Kerngedanke: Isolation schützt Transaktionen vor problematischen Eingriffen durch gleichzeitige Transaktionen.