Erklär die Transaction Isolation Levels und welchen deine Datenbank standardmäßig verwendet.

Die vier Level sind read uncommitted, read committed, repeatable read und serializable, und sie tauschen Nebenläufigkeit gegen die Anomalien, die sie zulassen: Dirty Reads, Non-Repeatable Reads, Phantom Reads und Write Skew. PostgreSQL steht standardmäßig auf read committed, wo jedes Statement einen frischen Snapshot sieht; MySQL mit InnoDB steht standardmäßig auf repeatable read, wo die ganze Transaktion einen Snapshot sieht. Serializable ist das einzige Level, das garantiert, dass das Ergebnis irgendeiner seriellen Reihenfolge entspricht.

Sie gehen von read uncommitted bis serializable, und jeder Schritt beseitigt eine Anomalie, kostet aber Nebenläufigkeit. Read committed stoppt Dirty Reads, aber jedes Statement bekommt seinen eigenen Snapshot, dieselbe Query zweimal in einer Transaktion kann also unterschiedliche Zeilen liefern. Repeatable read fixiert einen Snapshot für die ganze Transaktion. Serializable garantiert zusätzlich, dass das Ergebnis äquivalent dazu ist, die Transaktionen nacheinander laufen zu lassen, was Postgres über Predicate Tracking löst, es blockiert also nicht, sondern kann eine Transaktion abbrechen, und du musst zum Retry bereit sein. Defaults sind wichtig: Postgres ist read committed, InnoDB ist repeatable read, was Leute beim Wechsel zwischen beiden überrascht. Der Bug, den ich wirklich hatte, war Write Skew auf einer Buchungstabelle: zwei Requests prüften jeweils, dass keine überlappende Reservierung existiert, beide sahen einen sauberen Snapshot, und beide haben eingefügt. Repeatable read half nicht, weil sie unterschiedliche Zeilen geschrieben haben. Wir haben es mit serializable plus Retry gelöst, später mit einem Exclusion Constraint, was billiger ist.