Transaktionsgrenzen
Eine Transaktionsgrenze fasst Änderungen zusammen, die gemeinsam gelingen oder scheitern. Außerhalb dieser Grenze braucht Zusammenarbeit eine eigene Fehlerbehandlung.
- AtomaritätAlles oder nichts.
- Commit und RollbackFestschreiben oder verwerfen.
- GrenzeNur Gemeinsames, keine externen Aufrufe.
Einordnung
Warum das wichtig ist
Stürzt das System mitten im Speichern ab, bleibt ein halber Zustand zurück. Eine Transaktion macht daraus alles oder nichts. Ihre Grenze umfasst nur, was gemeinsam gelten muss, typischerweise ein Aggregate. Externe Aufrufe liegen außerhalb. Über mehrere Transaktionen hinweg braucht es eine Saga.
Dieser Baustein erklärt lokale atomare Änderungen. Für Abläufe über mehrere Transaktionen siehe Saga.
Auf einen Blick · Alles oder nichts in einer Grenze
Wo bricht es ab?
Der Checkout speichert Auftrag B-1042 mit Position P-7 und Bestellsumme in der Shop-Datenbank. Die Belastung beim Zahlungsanbieter ist ein externer Aufruf.
So liest du das Bild
- Atomarität Mit einer Transaktion liegt nach dem Absturz entweder alles oder nichts in der Datenbank.
- Commit und Rollback Vor dem Commit wird zurückgerollt; erst nach dem Commit bleiben alle drei Felder gefüllt.
- Grenze Der Zahlungsanbieter bleibt belastet, auch wenn die Datenbank zurückrollt.
- Auftrag anlegen
- Position P-7 schreiben
- Bestellsumme setzen
- Commit
In der Datenbank nach dem Absturz · nach Schritt 1
- Auftrag B-1042
- —
- Position P-7
- —
- Bestellsumme
- —
Nichts gespeichert, der Zustand ist sauber, und der Kunde kann die Bestellung neu aufgeben.
Nutzen & Grenzen
Hilft, wenn
- Eine gemeinsame Invariante bleibt durch eine atomare Transaktion über alle dazugehörigen lokalen Änderungen erhalten.
- Isolation und Konfliktbehandlung geben konkurrierenden Schreibvorgängen einen sicheren Ausgang.
- Eine lokale Transaktion speichert Datenbankänderung und Versandabsicht gemeinsam dauerhaft.
Grenzen
- Externe Aufrufe liegen außerhalb der lokalen Transaktion; ihr Ausgang braucht einen eigenen dauerhaften Status, siehe Transactional Outbox.
- Lange Transaktionen halten Sperren und bremsen andere; miss Laufzeit und Sperrwartezeit.
- Transaktionen über fremde Datenbereiche koppeln Module; besser Saga oder Outbox.
In der Praxis
- Benenne die Invariante, die gemeinsam geschützt werden soll, und beschränke die lokale Transaktion auf die dafür nötigen Änderungen. So bleibt ihre Grenze fachlich begründet.
- Prüfe Parallelzugriffe mit den gewählten Isolations- oder Versionsregeln. Miss Sperrzeit und Konflikte, damit Atomarität nicht unbemerkt den Durchsatz begrenzt.
- Behandle Veröffentlichung und externe Wirkungen außerhalb einer lokalen Transaktion explizit. Transactional Outbox koppelt Versandabsicht; Saga koordiniert verteilte Schritte.
Ausführliche Erklärung lesen
Eine lokale Transaktion macht zusammengehörige Änderungen atomar sichtbar: Alle enthaltenen Schreibvorgänge werden gemeinsam festgeschrieben oder gemeinsam zurückgerollt. Isolation beschreibt zusätzlich, wie konkurrierende Transaktionen einander beobachten.
Die Grenze sollte genau die fachlichen Invarianten einschließen, die gemeinsam gelten müssen. Sie umfasst nur Ressourcen, für die ein gemeinsamer Transaktionsmechanismus tatsächlich gilt. Externe Effekte brauchen eine gesonderte Koordination; bei verteilten Abläufen werden Fortschritt und Zwischenzustände Teil des Modells.
Transactional Outbox nutzt die lokale Atomarität für einen dauerhaften Versandauftrag; Saga koordiniert dagegen mehrere lokale Transaktionen mit fachlich bestimmten Folgeaktionen.
ACID steht für Atomarität, Konsistenz, Isolation und Dauerhaftigkeit; so beschreibt man die Zusagen einer lokalen Transaktion. Der Zwei-Phasen-Commit (2PC) dehnt sie auf mehrere Teilnehmer aus, kann diese aber blockieren, weshalb verteilte Abläufe oft auf Saga setzen.
Auch eine einzelne Transaktion hat eine Schwäche: Ändern zwei Nutzer gleichzeitig dieselbe Bestellung, kann die zweite Änderung die erste überschreiben (Lost Update). Abhilfe schaffen passende Isolationsstufen oder eine Versionsprüfung beim Schreiben (optimistisches Sperren).
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Du wählst Autocommit und lässt das System nach Schritt 1 abstürzen. Was liegt danach in der Datenbank?
Lösung mit Begründung ansehen
Nur der Auftrag B-1042. Position P-7 und Bestellsumme fehlen, die Invariante „mindestens eine Position“ ist verletzt.
AnwendenAuf eine neue Lage übertragen
Eine Transaktion, der Zahlungsanbieter wird vor dem Commit belastet, Absturz nach Schritt 3. Was liegt in der Datenbank, was beim Anbieter?
Lösung mit Begründung ansehen
Die Datenbank rollt zurück und enthält nichts. Der Anbieter hat 49,90 € aber schon belastet, denn der externe Aufruf liegt außerhalb der Transaktion.
BewertenEine Alternative abwägen
Das Team will Bestellung und Lagerreservierung in eine gemeinsame Transaktion packen, weil beide in derselben Datenbank liegen. Wie bewertest du das?
Lösung mit Begründung ansehen
Vorteil: Beides gelingt oder scheitert gemeinsam, ohne Zwischenzustand. Nachteil: Die Transaktion koppelt zwei Datenbereiche mit je eigener Datenhoheit und verlängert Sperren. Empfehlung: Nur zusammenlegen, wenn eine gemeinsame Invariante es verlangt; sonst getrennte Transaktionen mit Saga oder Outbox.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- PostgreSQL · Transactions (öffnet in neuem Tab)Erklärt atomare Änderungen, Commit und Rollback.
- PostgreSQL · Transaction Isolation (öffnet in neuem Tab)Vergleicht Isolationsstufen und erlaubte Nebenläufigkeitseffekte.
- microservices.io · Saga (öffnet in neuem Tab)Erklärt lokale Transaktionen und fachliche Kompensationen.