Datenbanktransaktionen im E-Commerce: Isolation, Deadlocks und sichere Wiederholung

Parallelität als Teil des E-Commerce-Ablaufs behandeln

Checkout, Bestandsreservierung, Gutscheineinlösung und Zahlungsbestätigung können innerhalb weniger Millisekunden dieselben Daten verändern. Eine Transaktion schützt eine Gruppe von Operationen, macht aber nicht automatisch jede Ausführungsreihenfolge korrekt. Das Ergebnis hängt von der Isolationsstufe, dem Zugriffsmuster und der Datenbank-Engine ab. Beginne mit der fachlichen Invariante: Der Bestand darf nicht negativ werden, ein einmaliger Gutschein nicht doppelt verbraucht werden und eine Bestellung keine unvereinbaren Zustände annehmen.

Dokumentiere die Invariante an der Transaktionsgrenze und erfasse jede Abfrage, die sie ändern kann. Beziehe auch Lesezugriffe ein, die Entscheidungen auslösen, denn eine scheinbar harmlose Abfrage kann einen vom Isolationsniveau erlaubten, für den Ablauf aber ungeeigneten Zustand sehen. Die nützliche Frage lautet nicht „verwenden wir Transaktionen?“, sondern „welche Anomalien akzeptieren wir und welche Betriebskosten tragen wir, um die anderen zu verhindern?“

Die Grenze kurz und vollständig halten

Die Transaktion muss alle Änderungen umfassen, die gemeinsam erfolgreich sein oder scheitern sollen, aber Netzwerkzugriffe, Rendering und unnötige Berechnungen ausschließen. Eine lange Transaktion hält Ressourcen und kann Ressourcenkonflikte, Wartezeiten und die Gefahr von Deadlocks erhöhen. Bereite Eingaben vorher vor, führe notwendige Lese- und Schreibvorgänge in stabiler Reihenfolge aus, beende mit Commit oder Rollback und antworte erst nach einem eindeutigen Ergebnis.

Isolation nach der zu verhindernden Anomalie wählen

Die Namen der Isolationsstufen wirken portabel, doch ihr konkretes Verhalten unterscheidet sich zwischen PostgreSQL, MySQL und SQL Server. Halte die Engine, die Version, die Konfiguration und die Zugriffsart fest. Modelliere für jeden Ablauf zwei oder drei parallele Sequenzen: Zwei Warenkörbe kaufen die letzte Einheit, eine Erstattung läuft parallel zu einer Zahlungsabbuchung oder ein Abgleich liest während einer Statusänderung. Prüfe, ob Entscheidungen auf inkonsistenten Leseergebnissen beruhen, Aktualisierungen verloren gehen oder ein Zustand vor dem Commit ungültig wird.

Wähle nicht aus Gewohnheit das strengste Niveau und senke es nicht nur für kürzere Laufzeiten. Stärkere Isolation kann Anomalien in Transaktionsabbrüche verwandeln, die wiederholt werden müssen. Ein schwächeres Niveau braucht möglicherweise Constraints, bedingte Updates oder sorgfältig entworfene explizite Sperren. Die Wahl ist ein durch Parallelitätstests belegter Anwendungsvertrag und kein einzelner globaler Schalter.

Constraints und atomare Vergleiche einsetzen

Eindeutigkeitsregeln, Fremdschlüssel und Bedingungen im Update können Invarianten nahe an den Daten schützen. Eine Aktualisierung, die nur erfolgt, wenn Version und Zustand noch den gelesenen Werten entsprechen, macht den konkurrierenden Zugriff durch ein eindeutiges Ergebnis sichtbar. Prüfe stets die Zahl der betroffenen Zeilen und behandle null Zeilen als Konflikt, nicht als stillen Erfolg. Der genaue Mechanismus hängt von der Datenbank ab und muss am realen Schema getestet werden.

Deadlock, Blocking und Timeout trennen

Beim Blocking wartet eine Transaktion auf eine von einer anderen gehaltene Ressource; die Wartezeit kann enden, wenn der Besitzer abschließt. Ein Deadlock ist dagegen ein Zyklus, in dem jeder Beteiligte auf eine Ressource eines anderen wartet. Die Datenbank bricht ein Opfer ab, um den Zyklus zu lösen, wobei sich die Auswahl und die Diagnose zwischen den Engines unterscheiden. Ein Timeout ist nochmals anders: Er meldet das Überschreiten eines Zeitlimits und beweist allein keinen Deadlock.

Klassifiziere Fehler anhand dokumentierter Treibercodes und Zustände statt anhand von Wörtern in lokalisierten Meldungen. Erfasse die Anwendungs-Transaktions-ID, die Operation, den Versuch, die Dauer, die Phase und den Datenbankcode, ohne sensible Werte zu protokollieren. Miss Deadlocks, lange Sperrzeiten, Timeouts und Serialisierungsfehler getrennt. Eine gemeinsame Kategorie „Datenbankfehler“ verbirgt unterschiedliche Gegenmaßnahmen.

Zyklen durch Ordnung und vorhersehbare Zugriffe reduzieren

Wenn mehrere Abläufe Bestellungen, Bestandszeilen und Zahlungen ändern, sollten sie Ressourcen in derselben logischen Reihenfolge anfordern. Halte die Abfragen selektiv, richte die Indizes an den Prädikaten aus und begrenze die Batches, denn breite Zugriffe berühren mehr Zeilen und halten Ressourcen länger. Diese Disziplin verringert die Wahrscheinlichkeit solcher Zyklen, macht Deadlocks aber nicht unmöglich. Die Anwendung muss das dokumentierte Ergebnis weiterhin beherrschen.

Reproduziere Konflikte mit Tests, die zwei Sitzungen an festgelegten Punkten synchronisieren. Verlasse dich nicht nur auf zufällige Pausen; solche Tests können bestehen, ohne die kritische Überlappung auszulösen. Prüfe die Abfragereihenfolge, die gewählten Indizes und die Ausführungspläne und wiederhole nach Schema- oder Versionsänderungen. Ein anderer Plan kann die physische Zugriffsreihenfolge ändern, obwohl der Anwendungscode gleich aussieht.

Die ganze Transaktion statt der letzten Anweisung wiederholen

Nach einem Deadlock oder Serialisierungsfehler sind zuvor gelesene Daten keine zuverlässige Entscheidungsgrundlage mehr. Eine korrekte Wiederholung beginnt neu: Sie öffnet eine frische Transaktion, liest den aktuellen Zustand, berechnet die Entscheidung erneut und führt alle Schreibvorgänge vor dem Commit aus. Nur die fehlgeschlagene Abfrage zu wiederholen kann eine alte Entscheidung mit einem neuen Zustand verbinden und genau die zu schützende Invariante verletzen.

Versuche, Laufzeit und Druck begrenzen

Wiederhole nur als vorübergehend klassifizierte Fehler. Lege eine maximale Anzahl von Versuchen, ein gesamtes Zeitbudget und ansteigende Pausen mit zufälliger Variation fest und gib bei Erschöpfung ein eindeutiges Ergebnis zurück. Eine Endlosschleife verstärkt Ressourcenkonflikte, kann den Dienst überlasten und verlängert die Checkout-Warteschlange. Erfasse die nötigen Versuche und brich früher ab, wenn die Client-Anfrage abgelaufen oder der Dienst überlastet ist.

Die Wiederholungslogik sollte eine vollständige Transaktionsfunktion erhalten und keine Objekte aus dem vorherigen Versuch behalten. Jede Iteration erstellt die Verbindung oder den Kontext gemäß den Vorgaben des Treibers neu, setzt dieselben Grenzen und liefert genau ein Ergebnis. Teste auch das erschöpfte Budget: Der Aufrufer muss entscheiden können, ob er eine neue Aktion anbietet, Arbeit einreiht oder einen behebbaren Fehler zeigt.

Nebeneffekte schützen, die Rollback nicht rückgängig macht

Ein Datenbank-Rollback macht weder eine E-Mail noch eine Anfrage an einen Zahlungsdienst, eine veröffentlichte Nachricht oder eine geschriebene Datei rückgängig. Liegen solche Effekte im wiederholbaren Block, kann jeder Versuch sie duplizieren. Speichere die Absicht in der Datenbank, nutze eine stabile Idempotenz-ID und versende nach dem Commit über einen zuverlässigen Prozess. Ist ein externer Aufruf unvermeidbar, wende dessen Idempotenzvertrag an und bewahre die Zuordnung von Anfrage und Ergebnis auf.

Unterscheide den Fehler vor dem Commit, den erfolgreichen Commit mit einer verlorenen Antwort und den Fehler eines nachgelagerten Effekts. Das sind verschiedene Zustände, die Abgleich statt pauschaler Wiederholung verlangen. Eine transaktionale Outbox kann die Fachänderung und die Veröffentlichungsabsicht in derselben Transaktion speichern; die Zustellung kann dennoch mindestens einmal erfolgen und Empfänger müssen Duplikate tolerieren.

Beobachten und ausrollen, ohne erfundene Benchmarks

Erstelle eine Basislinie für die eigene Last. Miss dafür den Anteil abgeschlossener Transaktionen, die Fehler pro Klasse, die typischen und hohen Versuchszahlen, die Wartezeit, die Gesamtdauer und die Operationen, die das Budget ausschöpfen. Verknüpfe Telemetrie mit der Anwendungsversion, dem Abfrage-Fingerprint und dem Plan, ohne personenbezogene Werte offenzulegen. Mehr Wiederholungen können durch legitimes Wachstum, eine neue Zugriffsreihenfolge oder einen unpassenden Index entstehen; Korrelation ist wichtiger als ein universeller Grenzwert.

Rolle jeweils eine Änderung auf einen kontrollierten Verkehrsanteil aus. Bereite einen Rollback für den Code, das Schema und die Konfiguration vor und halte einen deterministischen Parallelitätstest in der CI aufrecht. Um Transaktionsgrenzen, Beobachtbarkeit und Wiederherstellung für deinen Shop zu gestalten, entdecke unsere Leistungen für digitale Systeme und E-Commerce. Ziel ist nicht, Konflikte wegzudefinieren, sondern sie erwartbar, begrenzt und überprüfbar zu machen.