Transaction

SQL:

BEGIN; -- Start der Transaktion
UPDATE konten SET saldo = saldo - 100 WHERE id = 'Ich';
UPDATE konten SET saldo = saldo + 100 WHERE id = 'Oma';
-- Hier ist noch nichts gespeichert!
COMMIT; -- Jetzt wird alles auf einmal dauerhaft geschrieben.

Wenn ein Fehler passiert: ROLLBACK; -- Alles zurück auf Anfang.

1. ACID Eigenschaften

Jede echte Transaktion muss ACID sein:

• Atomicity: Ganz oder gar nicht.
• Consistency: Datenbank bleibt logisch valide (keine negativen Kontostände, wenn verboten).
• Isolation: Wenn zwei Leute gleichzeitig überweisen, kommen sie sich nicht in die Quere.
• Durability: Nach COMMIT sind die Daten sicher, auch wenn der Server brennt (WAL Protokoll).

2. Isolation Levels

Wie stark sind Transaktionen isoliert?

• Read Uncommitted: Ich sehe Daten, die du noch gar nicht committed hast (Dirty Read). Schnell, aber gefährlich.
• Read Committed: Ich sehe nur fertige Daten (Standard in Postgres).
• Serializable: Das System tut so, als ob wir nacheinander arbeiten würden. Extrem sicher, aber langsam (Deadlocks möglich).

3. Distributed Transactions (2PC)

Was, wenn mein Konto bei Bank A (DB 1) und Omas Konto bei Bank B (DB 2) liegt? Transaktionen über zwei Datenbanken sind die Hölle. Protokoll: Two-Phase Commit (2PC). Teure Koordination ("Bist du bereit?" - "Ja" - "Alle committen!"). In Microservices vermeidet man das oft (nutzt stattdessen Sagas / Eventual Consistency), weil 2PC nicht skaliert.

1. Write-Ahead Logging (WAL)

Wie garantiert die Datenbank die Durability (Haltbarkeit), wenn der Strom mitten beim Schreiben ausfällt? Sie nutzt ein WAL. Bevor die echten Daten in die Datenbank-Tabellen geschrieben werden (was teuer ist, da sie an verschiedenen Stellen auf der Festplatte liegen), schreibt der Server eine kurze Notiz in ein fortlaufendes Log: "Ich ziehe jetzt 100€ von A ab und gebe sie B." Dieses Log-Schreiben ist extrem schnell, da es nur ans Ende einer Datei angehängt wird (Sequential I/O). Erst wenn der Log-Eintrag sicher auf der Platte gelandet ist, meldet die DB COMMIT OK. Wenn der Server danach crashed, liest er beim Neustart einfach das Log und führt die Operationen sauber zu Ende oder macht sie rückgängig.

2. MVCC (Multi-Version Concurrency Control)

Moderne Datenbanken wie PostgreSQL oder Oracle nutzen MVCC, um Leser nicht durch Schreiber zu blockieren. Wenn du eine Zeile änderst, wird die alte Zeile nicht gelöscht oder überschrieben. Die Datenbank erstellt eine neue Version der Zeile. Andere Transaktionen, die gerade erst angefangen haben, lesen einfach die alte Version weiter ("Snapshot Isolation"), während deine Transaktion an der neuen Version arbeitet. Erst wenn du fertig bist, wird die neue Version zur "offiziellen" Wahrheit. Das verhindert, dass das gesamte System stehen bleibt, nur weil eine große Abfrage läuft.

3. Das Problem der Distributed Transactions (Sagas)

In der Welt der Microservices hat jeder Service seine eigene Datenbank. Eine Transaktion über Service A und Service B hinweg (z. B. "Bestellung aufgeben" und "Lagerbestand mindern") ist mit klassischen Mitteln (2PC) extrem fehleranfällig und langsam. Stattdessen nutzt man oft das Saga Pattern: Man führt die Schritte nacheinander aus. Wenn Schritt 2 (Lager) fehlschlägt, sendet das System ein Event zurück an Schritt 1 (Bestellung): "Bitte Rückgängig machen!". Das nennt man Compensating Transactions. Es gibt keine harte Garantie in Echtzeit, aber das System wird über die Zeit hinweg konsistent (Eventual Consistency).