Isolation

Veröffentlicht am:

Die wichtigsten Befehle zum Merken

  • psql -X -d lab — jede unabhängige Testsitzung öffnen.
  • BEGIN ISOLATION LEVEL REPEATABLE READ — einen Transaktionssnapshot behalten.
  • COMMIT — die Transaktion für spätere frische Ansichten beenden.

Befehle und Optionen

Befehl oder Syntax Bedeutung
-X -d lab Startdateien überspringen und Testdatenbank wählen.
CREATE TABLE / INSERT Gemeinsame Testtabelle und Startzeile erzeugen.
PRIMARY KEY / NOT NULL Eindeutige Zeilenkennung / nichtleeren Wert verlangen.
BEGIN ISOLATION LEVEL REPEATABLE READ Eine Repeatable-Read-Transaktion starten.
SELECT … WHERE id = 1 Die Testzeile lesen.
UPDATE … SET value = 200 Sie in Sitzung B ändern.
COMMIT / DROP TABLE As Transaktion beenden / Testtabelle entfernen.
-- A1 / ; / \q SQL-Kommentar zur Sitzungsreihenfolge / Anweisungsende / psql beenden.

Ohne ausdrückliche Transaktion bestätigt normales psql-Autocommit jede erfolgreiche Anweisung separat.

Die entscheidenden Konzepte

1. Isolation bestimmt die Sicht auf gleichzeitige Arbeit

Transaktionen laufen nicht allein. Während eine Sitzung liest, kann eine andere dieselben Daten ändern und bestätigen. Isolation definiert sichtbare Änderungen und verhindert bestimmte konkurrierende Kombinationen.

Atomarität beantwortet das nicht. Zwei jeweils vollständige Transaktionen können unvereinbare Entscheidungen treffen, wenn ihre Ansichten die Arbeit der anderen nicht berücksichtigen.

2. Ein Snapshot ist eine Sichtbarkeitsregel

PostgreSQL verwendet Multiversion Concurrency Control. Leser können passende Zeilenversionen sehen, statt grundsätzlich auf jeden Schreiber zu warten. Ein Snapshot bestimmt sichtbare Transaktionsänderungen.

Er ist keine komplette Datenbankkopie pro Abfrage. Alte Zeilenversionen und Sichtbarkeitsinformationen ermöglichen die Ansicht. Lange Transaktionen können benötigte Versionen festhalten und Bereinigung beeinflussen. Auch scheinbar untätige offene Transaktionen haben Folgen.

3. Read Committed und Repeatable Read setzen verschiedene Grenzen

Unter PostgreSQLs üblichem Read Committed erhält jede Anweisung einen neuen Snapshot. Wiederholte Abfragen innerhalb einer Transaktion können deshalb inzwischen bestätigte neue Werte sehen.

Repeatable Read behält den Snapshot der ersten Anweisung außerhalb der Transaktionssteuerung. Spätere normale Abfragen behalten diese Sicht; eigene Änderungen bleiben sichtbar. Andere Sitzungen können neuere Daten bestätigen, ohne sie im bestehenden Snapshot sichtbar zu machen.

4. Serializable schützt eine stärkere Korrektheitsbedingung

Serializable strebt Ergebnisse an, die einer seriellen Reihenfolge bestätigter Transaktionen entsprechen. PostgreSQL kann eine Transaktion mit Serialisierungsfehler ablehnen, wenn diese Garantie sonst nicht erhalten bleibt.

Die Anwendung muss dann die gesamte Transaktion mit frischen Abfragen wiederholen können, nicht nur ihre letzte Anweisung. Stärkere Isolation ersetzt weder Constraints noch Geschäftsregeln oder externe Effektkoordination. Entscheidend sind die zu schützenden konkurrierenden Entscheidungen.

Ein kleines Beispiel

Optional: Öffne den ersten Befehl in A und B mit derselben Datenbank und demselben Schema. Führe A1, B1 und A2 in dieser Reihenfolge aus. Stoppe bei fehlgeschlagener Tabellenerstellung; verwende oder lösche keine vorhandene Tabelle. Beende danach beide Sitzungen mit dem letzten Befehl.

psql -X -d lab
-- A1
CREATE TABLE btc_isolation_lab (id integer PRIMARY KEY, value integer NOT NULL);
INSERT INTO btc_isolation_lab VALUES (1, 100);
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT value FROM btc_isolation_lab WHERE id = 1;
-- B1
UPDATE btc_isolation_lab SET value = 200 WHERE id = 1;
-- A2
SELECT value FROM btc_isolation_lab WHERE id = 1;
COMMIT;
SELECT value FROM btc_isolation_lab WHERE id = 1;
DROP TABLE btc_isolation_lab;
\q

A1 sollte 100 lesen. B1 bestätigt seine Änderung unabhängig. A2 sieht im bestehenden Snapshot zunächst weiterhin 100; nach COMMIT sollte die nächste Abfrage 200 zeigen. Das sind Erwartungen für diese Reihenfolge.

Das Beispiel zeigt Snapshotsichtbarkeit, keinen Lost Update oder Serialisierungsfehler. DROP entfernt die selbst erstellte Tabelle. Bei Unterbrechung zuerst offene Transaktionen beenden oder zurückrollen und dann die Testtabelle entfernen. Sitzungsende allein löscht diese gewöhnliche gemeinsame Tabelle nicht.

Merke dir: Isolation bestimmt sichtbare konkurrierende Änderungen und die Gültigkeit der darauf aufgebauten Entscheidungen.