DynamoDB TransactionConflictException

TL;DR — Eine andere Transaktion arbeitet bereits auf demselben Item wie dein Request, also hat DynamoDB deinen abgelehnt, um die Isolation zu wahren. Das ist vorübergehende Konkurrenz, kein Fehler in deinen Daten — wiederhole mit exponentiellem Backoff, halte Transaktionen klein und reduziere gleichzeitige Writes auf dasselbe heiße Item.

Was es bedeutet

TransactionConflictException: Transaction is ongoing for the item

DynamoDB serialisiert konkurrierende Writes gegen laufende Transaktionen. Du triffst auf diese Exception, wenn ein einfaches PutItem, UpdateItem oder DeleteItem mit einem laufenden TransactWriteItems kollidiert, das dasselbe Item enthält. Statt zu blockieren, lehnt DynamoDB den Einzel-Item-Write mit TransactionConflictException (HTTP 400) ab. Er ist wiederholbar — der Konflikt löst sich, sobald die andere Transaktion committet oder abbricht.

Beachte die Unterscheidung von TransactionCanceledException: Wenn der unterlegene Request selbst ein TransactWriteItems oder TransactGetItems ist, bricht DynamoDB stattdessen die ganze Transaktion ab — du bekommst einen Cancellation, dessen CancellationReasons TransactionConflict als Reason-Code pro Item tragen, nicht diese Exception.

Warum es passiert

• Gleichzeitige Writes auf dasselbe Item — ein einfaches PutItem/UpdateItem überlappt ein laufendes TransactWriteItems, das dieses Item berührt.
• Zwei Transaktionen, die ein Item teilen — zwei TransactWriteItems-Requests enthalten denselben Schlüssel zur selben Zeit; einer gewinnt, der andere wird mit einem TransactionConflict-Reason-Code abgebrochen (als TransactionCanceledException zutage gefördert).
• Ein heißes Item unter starken gleichzeitigen Updates — z. B. ein gemeinsamer Zähler oder eine einzelne Aggregat-Zeile, die jeder Request aktualisiert.
• Lange oder große Transaktionen, die Items lange genug halten, um andere Writer zu überlappen.
• Ein Retry-Sturm — Retries ohne Backoff häufen mehr gleichzeitige Versuche auf dasselbe umkämpfte Item.

So behebst du es

1. Wiederhole mit exponentiellem Backoff + Jitter. Das ist die primäre Lösung — der Konflikt ist vorübergehend und löst sich, wenn die andere Transaktion abschließt. Behalte Jitter, damit sich Retries nicht in eine weitere Kollision resynchronisieren.
2. Halte Transaktionen klein und kurz — weniger Items pro TransactWriteItems bedeutet kürzere Haltezeiten und weniger Überlappung.
3. Reduziere die Konkurrenz auf heißen Items — sharde einen heißen Zähler über mehrere Items und aggregiere, oder nutze einen atomaren Zähler mit einem einfachen UpdateItem (ADD) statt einer Transaktion, wenn du keine Alles-oder-Nichts-Semantik brauchst.
4. Mische nicht gleichzeitig eine Transaktion und einen einfachen Write auf demselben Item, wenn du es vermeiden kannst — leite beide durch denselben Pfad.
5. Überwache die TransactionConflict-CloudWatch-Metrik, um zu sehen, ob die Konkurrenz steigt und wo.

Wenn der konkurrierende Writer du selbst bist — du bearbeitest Items von Hand, während deine App in dieselbe Tabelle schreibt — bündelt DynoTables Staging-Bereich deine manuellen Änderungen in einen einzigen transaktionalen Write, den du auf einmal prüfst und committest, statt in einen Strom sich überlappender Einzel-Item-Writes.

In DynoTable prüfen

Wenn der konkurrierende Schreiber du selbst bist, bündle manuelle Änderungen über Staging (⌘S) — DynoTable committet sie als einen geprüften Write statt als Strom überlappender Einzel-Item-Updates. Öffne umkämpfte Items mit ⌘K und sieh dir den Live-Zustand an, bevor du es erneut versuchst.

Size transactional traffic with the Pricing-Rechner. Wechsle Profile mit ⌘P; Verbindung testen on Einstellungen → Profile. Siehe Mit AWS verbinden und Installation.

Quellen

• Amazon DynamoDB Transactions: How it works (verifiziert 2026-07-13)
• PutItem — Amazon DynamoDB API Reference (verifiziert 2026-07-13)

FAQ

Wie behebe ich TransactionConflictException in DynamoDB? Wiederhole den Request mit exponentiellem Backoff und Jitter — der Konflikt ist vorübergehende Konkurrenz mit einer anderen laufenden Transaktion auf demselben Item. Halte außerdem Transaktionen klein, sharde heiße Items und vermeide, eine Transaktion und einen einfachen Write gleichzeitig gegen dasselbe Item laufen zu lassen.

Ist TransactionConflictException dasselbe wie TransactionCanceledException? Nein. TransactionConflictException bedeutet, dass eine andere Transaktion gerade auf dem Item operiert. TransactionCanceledException bedeutet, dass eine ganze Transaktion zurückgerollt wurde; ihre CancellationReasons erklären, warum, und ein Transaktionskonflikt kann einer dieser Gründe sein.

Verwandte Fehler

• TransactionCanceledException — eine ganze Transaktion zurückgerollt (Bedingungen, Kapazität oder ein Konflikt).
• ConditionalCheckFailedException — die Bedingung eines einzelnen Writes ist fehlgeschlagen.
• Code-Beispiel: TransactWriteItems in Node.js — eine Transaktion mit Retry/Backoff zum Anpassen.
• Learn: DynamoDB-Transaktionen · Atomare Zähler

Referenzen

• Amazon DynamoDB Transactions: How it works — Amazon DynamoDB Developer Guide
• PutItem — Amazon DynamoDB API Reference
• TransactWriteItems — Amazon DynamoDB API Reference
• DynamoDB metrics and dimensions — Amazon DynamoDB Developer Guide

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.