Deadlocks: Entstehung und Vermeidung

In Lektion 6 haben wir gesehen, wie das DBMS Isolation umsetzt – unter anderem über Sperren (Locks). Wenn eine Transaktion eine Zeile ändert, hält sie auf dieser Zeile eine exklusive Sperre bis zum COMMIT oder ROLLBACK. Andere Transaktionen, die diese Zeile auch ändern wollen, warten geduldig.

Was passiert aber, wenn Transaktion A auf Zeile 1 wartet, weil Transaktion B sie hält – und Transaktion B gleichzeitig auf Zeile 2 wartet, weil Transaktion A sie hält? Antwort: beide warten ewig aufeinander. Keine kann weiter. Das ist ein Deadlock. Diese Lektion zeigt wie Deadlocks entstehen, wie das DBMS sie erkennt und auflöst, und – am wichtigsten – wie du sie in deinem Code vermeidest.

1) Das Restaurant-Bild

Stell dir zwei Gäste im Restaurant vor: jeder bestellt Suppe, die mit Löffel und Gabel gegessen werden soll. Auf dem Tisch liegt ein Löffel und eine Gabel. Gast A schnappt sich den Löffel, Gast B die Gabel. Jetzt wartet A auf B's Gabel, B wartet auf A's Löffel. Keiner gibt nach, keiner isst – sie sitzen ewig da. Das ist die exakte Situation in einer Datenbank, nur mit Zeilen statt Besteck.

Der bekannte „Dining Philosophers"-Klassiker beschreibt genau das. In der Praxis braucht es zwei Voraussetzungen: mehrere Ressourcen, die in unterschiedlicher Reihenfolge gesperrt werden. Beides ist im SQL-Alltag schnell der Fall.

2) Ein klassisches Deadlock-Szenario

Banküberweisung in beide Richtungen gleichzeitig – das einfachste Beispiel. Zwei Sessions wollen je 100 € zwischen Konto A und Konto B verschieben, aber in entgegengesetzter Richtung:

Deadlock Schritt für Schritt

Schritt 0

Schritt 1

Schritt 2

Schritt 3

Schritt 4

Session 1 (A → B) bereit

Session 2 (B → A) bereit

konto A 🔓

konto B 🔓

→ Klick „Nächster Schritt" um das Szenario durchzuspielen.

Beobachtet wird hier ein echter Deadlock, kein bloßes Warten: jede Session hat eine Sperre und wartet auf die Sperre der anderen. Würde keiner eingreifen, würden beide Sessions endlos warten. Das DBMS erkennt diese Situation aber – und greift ein.

3) Wie das DBMS Deadlocks erkennt

Das DBMS führt im Hintergrund einen Wait-for-Graph: jeder Knoten ist eine Transaktion, jede Kante zeigt „wartet auf". Wenn eine Transaktion eine Sperre anfordert, die schon vergeben ist, wird die entsprechende Kante hinzugefügt. Wenn dabei ein Zyklus entsteht, ist es ein Deadlock:

Wait-for-Graph mit Zyklus

Der Zyklus T1 → T2 → T1 ist die Signatur eines Deadlocks.

Sobald das DBMS einen Zyklus erkennt – meist innerhalb von Millisekunden – wählt es eine der beteiligten Transaktionen als Opfer aus, rollt sie zurück (alle ihre Sperren werden freigegeben) und meldet sie mit einem Deadlock-Fehler an den Klienten. Die andere Transaktion kann dann weiterlaufen. In MySQL/InnoDB ist das typischerweise die Transaktion mit dem geringsten „Aufwand" (gemessen an Anzahl betroffener Zeilen oder Logvolumen).

4) Wie sich ein Deadlock-Fehler im Code zeigt

Wenn deine Anwendung das Opfer ist, bekommst du eine sehr spezifische Fehlermeldung. In MySQL sieht das so aus:

ERROR 1213 (40001): Deadlock found when trying to get lock;
try restarting transaction

Wichtig ist der SQL-State 40001 – das ist der Standard-Code für „Serialization Failure / Deadlock detected". In PostgreSQL ist es der gleiche Code, der Text leicht anders. Andere Codes für ähnliche Konflikte: 40P01 (PostgreSQL „deadlock detected"), ORA-00060 (Oracle „deadlock detected"). Allen gemein: deine Transaktion wurde bereits zurückgerollt. Du musst kein ROLLBACK mehr senden – die Aufgabe ist erledigt.

Was du tun musst: die ganze Transaktion neu starten. Genau dafür gibt es das Retry-Pattern:

// Pseudocode: Retry-Schleife für Deadlock-Recovery
for (let attempt = 1; attempt <= 3; attempt++) {
  try {
    await db.query('BEGIN');
    // ... Transaktion ...
    await db.query('COMMIT');
    break; // erfolgreich
  } catch (err) {
    if (err.code === '40001' && attempt < 3) {
      await sleep(Math.random() * 100); // random Backoff
      continue;
    }
    throw err;
  }
}

Das Random-Backoff verhindert, dass beide gekoppelten Sessions nach einer fest definierten Zeit gleichzeitig neu starten – und sich wieder gegenseitig blockieren.

5) Strategien zur Vermeidung

Retry ist Symptombehandlung. Besser ist, Deadlocks gar nicht erst entstehen zu lassen. Es gibt vier bewährte Strategien – klick dich durch:

Vermeidungsstrategien

1. Konsistente Reihenfolge

2. Kurze Transaktionen

3. Geringere Isolation

4. SELECT FOR UPDATE

Die mit Abstand wichtigste Strategie ist konsistente Reihenfolge. Wenn alle Transaktionen Ressourcen immer in derselben Reihenfolge sperren (z.B. nach Primärschlüssel aufsteigend), ist ein Zyklus mathematisch unmöglich – kein Deadlock. Diese Disziplin ist die billigste und wirksamste Maßnahme. Sie zu erzwingen ist allerdings nicht trivial, weil sie sich über mehrere Stellen im Code verteilen kann.

6) Deadlock vs. einfaches Lock-Wait

Wichtig zu unterscheiden: nicht jedes Warten ist ein Deadlock. Wenn Transaktion A einfach nur auf B's Sperre wartet, ohne dass B umgekehrt auf etwas wartet, ist das ein normales Lock-Wait – das löst sich auf, sobald B fertig ist. Erst wenn ein Zyklus entsteht (A wartet auf B wartet auf A), ist es ein Deadlock.

Beide Phänomene haben getrennte Timeouts:

Lock-Wait-Timeout (MySQL: innodb_lock_wait_timeout, Default 50s): wie lange eine Transaktion auf eine Sperre wartet bevor sie aufgibt. Schlägt mit ERROR 1205 fehl.
Deadlock-Detection (MySQL: innodb_deadlock_detect = ON, Default an): das DBMS prüft aktiv den Wait-for-Graph und greift sofort ein.

Praxis: bei langen Hänger-Symptomen in Production hilft SHOW ENGINE INNODB STATUS; in MySQL – das zeigt aktuelle Sperren und die letzten Deadlocks mit allen Details. PostgreSQL bietet SELECT * FROM pg_locks; und Logging-Optionen für lange Locks.

7) Monitoring & Diagnose

In großen Systemen kommen Deadlocks unter Last vor – nicht laufend, aber regelmäßig. Wichtig ist sie zu messen, nicht zu ignorieren. Drei Diagnose-Tools:

InnoDB-Statusausgabe: SHOW ENGINE INNODB STATUS\G zeigt unter „LATEST DETECTED DEADLOCK" das letzte Ereignis mit beteiligten Queries und gehaltenen Sperren. Goldstandard für Post-mortem-Analyse.
Performance Schema (MySQL): Tabelle events_statements_history kombiniert mit data_locks zeigt was zur Deadlock-Zeit lief.
Anwendungs-Logging: jeder gefangene Deadlock-Error sollte mit Stack-Trace und beteiligten Tabellen geloggt werden. Häufungen weisen auf Hot-Spots hin, die du anpassen kannst.

Eine niedrige Deadlock-Rate (z.B. <0,01% aller Transaktionen) ist normal. Wenn 5% deiner Transaktionen Deadlocks sehen, hast du ein Strukturproblem – meist falsche Sperrreihenfolge oder zu lange Transaktionen.

8) Wann Deadlocks akzeptabel sind

Vollständig deadlock-freier Code wäre teuer – jede Transaktion müsste pessimistisch das gesamte System sperren bevor sie startet, oder über Anwendungslogik-Locks gehen, die noch komplexer sind. In der Praxis akzeptiert man eine kleine Deadlock-Quote als Kosten der Nebenläufigkeit.

Die richtige Frage ist nicht „wie verhindere ich JEDEN Deadlock?", sondern „wie minimiere ich die Häufigkeit und wie handle ich sie sauber wenn sie passieren?". Antwort: konsistente Sperrreihenfolge, kurze Transaktionen, Retry-Pattern auf Anwendungsseite. Damit lebt jedes professionelle System.

Zusammenfassung

Ein Deadlock ist eine zyklische Wartesituation zwischen zwei oder mehr Transaktionen: jede hält eine Sperre, auf die eine andere wartet. Das DBMS erkennt solche Zyklen über einen Wait-for-Graph, wählt eines der Opfer aus, rollt es zurück (Sperren werden freigegeben) und meldet dem Klienten einen Deadlock-Fehler (SQL-State 40001, MySQL ERROR 1213). Die andere Transaktion läuft weiter. Vermeidungsstrategien: konsistente Sperrreihenfolge (wichtigste!), kurze Transaktionen, geringere Isolationsstufe wo akzeptabel, gezieltes SELECT … FOR UPDATE zur Sperrlokalisierung. Unterscheide Deadlock (zyklisch, sofort erkannt) von Lock-Wait (einfaches Warten, läuft nach Timeout ab). Im Anwendungscode immer ein Retry-Pattern mit Random Backoff für Deadlock-Errors implementieren. Eine niedrige Quote ist normal und akzeptabel – Häufungen weisen auf strukturelle Probleme hin.