DynamoDB TransactionConflictException

TL;DR — Une autre transaction opère déjà sur le même élément que ta requête, donc DynamoDB a rejeté la tienne pour préserver l'isolation. C'est une contention transitoire, pas un bug dans tes données — réessaie avec un backoff exponentiel, garde des transactions petites, et réduis les écritures concurrentes vers le même élément à forte activité.

Ce que ça signifie

TransactionConflictException: Transaction is ongoing for the item

DynamoDB sérialise les écritures conflictuelles face aux transactions en cours. Tu rencontres cette exception quand un simple PutItem, UpdateItem ou DeleteItem entre en collision avec un TransactWriteItems en cours qui inclut le même élément. Plutôt que de bloquer, DynamoDB rejette l'écriture à élément unique avec TransactionConflictException (HTTP 400). Elle est réessayable — le conflit se dissipe une fois que l'autre transaction est commitée ou avortée.

Note la distinction avec TransactionCanceledException : quand la requête perdante est elle-même un TransactWriteItems ou un TransactGetItems, DynamoDB annule plutôt toute cette transaction — tu obtiens une annulation dont les CancellationReasons portent TransactionConflict comme code de motif par élément, pas cette exception.

Pourquoi ça arrive

• Écritures concurrentes vers le même élément — un simple PutItem/UpdateItem chevauche un TransactWriteItems en cours touchant cet élément.
• Deux transactions partageant un élément — deux requêtes TransactWriteItems incluent la même clé au même moment ; l'une gagne, l'autre est annulée avec un code de motif TransactionConflict (remonté sous forme de TransactionCanceledException).
• Un élément à forte activité sous de lourdes mises à jour concurrentes — par exemple un compteur partagé ou une seule ligne agrégée que chaque requête met à jour.
• Des transactions longues ou volumineuses retenant des éléments assez longtemps pour chevaucher d'autres écrivains.
• Une tempête de retries — des retries sans backoff empilent davantage de tentatives concurrentes sur le même élément contendu.

Comment le corriger

1. Réessaie avec un backoff exponentiel + jitter. C'est la solution principale — le conflit est transitoire et se dissipe quand l'autre transaction se règle. Garde du jitter pour que les retries ne se resynchronisent pas en une nouvelle collision.
2. Garde des transactions petites et courtes — moins d'éléments par TransactWriteItems signifie des détentions plus courtes et moins de chevauchement.
3. Réduis la contention sur les éléments à forte activité — shard un compteur à forte activité sur plusieurs éléments et agrège, ou utilise un compteur atomique avec un simple UpdateItem (ADD) au lieu d'une transaction quand tu n'as pas besoin de la sémantique tout-ou-rien.
4. Ne mélange pas une transaction et une simple écriture sur le même élément de façon concurrente si tu peux l'éviter — fais passer les deux par le même chemin.
5. Surveille la métrique CloudWatch TransactionConflict pour voir si la contention augmente et où.

Quand l'écrivain concurrent, c'est toi — en train de modifier des éléments à la main pendant que ton app écrit dans la même table — la zone de staging de DynoTable regroupe tes modifications manuelles en une seule écriture transactionnelle que tu relis et commites d'un coup, au lieu d'un flot d'écritures mono-élément qui se chevauchent.

Inspecte dans DynoTable

Quand l'écrivain concurrent, c'est toi, regroupe tes modifications manuelles dans le staging (⌘S) — DynoTable les valide comme une seule écriture relue, au lieu d'un flot de mises à jour d'éléments qui se chevauchent. Ouvre les éléments disputés avec ⌘K et inspecte leur état en direct avant de réessayer.

Dimensionne le trafic transactionnel avec le calculateur de tarifs. Change de profil avec ⌘P ; Test Connection dans Settings → Profiles. Vois Se connecter à AWS et Installation.

Sources

• Amazon DynamoDB Transactions: How it works (vérifié le 2026-07-13)
• PutItem — Amazon DynamoDB API Reference (vérifié le 2026-07-13)

FAQ

Comment corriger TransactionConflictException dans DynamoDB ? Réessaie la requête avec un backoff exponentiel et du jitter — le conflit est une contention transitoire avec une autre transaction en cours sur le même élément. Garde aussi des transactions petites, shard les éléments à forte activité, et évite de faire tourner une transaction et une simple écriture sur le même élément de façon concurrente.

TransactionConflictException est-elle la même chose que TransactionCanceledException ? Non. TransactionConflictException signifie qu'une autre transaction opère actuellement sur l'élément. TransactionCanceledException signifie qu'une transaction entière a été annulée ; ses CancellationReasons expliquent pourquoi, et un conflit de transaction peut être l'un de ces motifs.

Erreurs liées

• TransactionCanceledException — une transaction entière annulée (conditions, capacité, ou un conflit).
• ConditionalCheckFailedException — la condition d'une seule écriture a échoué.
• Exemple de code : TransactWriteItems en Node.js — une transaction avec retry/backoff à adapter.
• En savoir plus : Transactions DynamoDB · Compteurs atomiques

Références

• 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

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.