DynamoDB TransactionConflictException

TL;DR: ya hay otra transacción operando en el mismo artículo que su solicitud, por lo que DynamoDB rechazó la suya para preservar el aislamiento. Es una contención transitoria, no un error en sus datos: vuelva a intentarlo con un retroceso exponencial, mantenga las transacciones pequeñas y reduzca las escrituras simultáneas en el mismo elemento importante.

Qué significa

TransactionConflictException: Transaction is ongoing for the item

DynamoDB serializa las escrituras en conflicto frente a las transacciones en curso. Alcanzas esta excepción cuando un PutItem, UpdateItem o DeleteItem simple colisiona con un TransactWriteItems en curso que incluye el mismo Item. En lugar de bloquear, DynamoDB rechaza la escritura de un solo Item con TransactionConflictException (HTTP 400). Sí es reintentable — el conflicto se despeja en cuanto la otra transacción se confirma o aborta.

Fíjate en la distinción con TransactionCanceledException: cuando la petición perdedora es en sí misma un TransactWriteItems o TransactGetItems, DynamoDB cancela toda esa transacción en su lugar — obtienes una cancelación cuyos CancellationReasons llevan TransactionConflict como código de razón por Item, no esta excepción.

Por qué ocurre

  • Escrituras concurrentes al mismo Item — un PutItem/UpdateItem simple se solapa con un TransactWriteItems en curso que toca ese Item.
  • Dos transacciones compartiendo un Item — dos peticiones TransactWriteItems incluyen la misma clave al mismo tiempo; una gana, la otra se cancela con un código de razón TransactionConflict (mostrado como TransactionCanceledException).
  • Un Item caliente bajo fuertes actualizaciones concurrentes — p. ej. un contador compartido o una única fila de agregado que cada petición actualiza.
  • Transacciones largas o grandes que retienen los Items lo suficiente como para solaparse con otros escritores.
  • Una tormenta de reintentos — los reintentos sin backoff apilan más intentos concurrentes sobre el mismo Item en contención.

Cómo solucionarlo

  1. Reintenta con backoff exponencial + jitter. Esta es la solución principal — el conflicto es transitorio y se despeja cuando la otra transacción se asienta. Mantén el jitter para que los reintentos no se resincronicen en otra colisión.
  2. Mantén las transacciones pequeñas y cortas — menos Items por TransactWriteItems significa retenciones más cortas y menos solapamiento.
  3. Reduce la contención en los Items calientes — reparte un contador caliente entre varios Items y agrega, o usa un contador atómico con un UpdateItem simple (ADD) en lugar de una transacción cuando no necesites la semántica de todo o nada.
  4. No mezcles una transacción y una escritura simple sobre el mismo Item de forma concurrente si puedes evitarlo — enruta ambas por el mismo camino.
  5. Monitoriza la métrica de CloudWatch TransactionConflict para ver si la contención está aumentando y dónde.

Inspecciónalo en DynoTable

Cuando el escritor concurrente eres tú, agrupa tus ediciones manuales en el área de preparación (⌘S) — DynoTable las confirma como una sola escritura revisada en lugar de un flujo de actualizaciones de un solo Item que se solapan. Abre los Items en contención con ⌘K e inspecciona su estado en vivo antes de reintentar.

Dimensiona el tráfico transaccional con la calculadora de precios. Cambia de perfil con ⌘P; Test Connection en Ajustes → Perfiles. Consulta Conectar con AWS e Instalación.

Fuentes

FAQ

¿Cómo soluciono TransactionConflictException en DynamoDB? Reintenta la petición con backoff exponencial y jitter — el conflicto es contención transitoria con otra transacción en curso sobre el mismo Item. Además, mantén las transacciones pequeñas, reparte los Items calientes, y evita ejecutar una transacción y una escritura simple contra el mismo Item de forma concurrente.

¿Es TransactionConflictException lo mismo que TransactionCanceledException? No. TransactionConflictException significa que otra transacción está operando actualmente sobre el Item. TransactionCanceledException significa que toda una transacción se revirtió; sus CancellationReasons explican por qué, y un conflicto de transacción puede ser una de esas razones.

Errores relacionados

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.

Trabaja con DynamoDB sin la Consola

Un cliente de escritorio rápido para DynamoDB que ejecuta el SQL real que DynamoDB no puede — JOINs, GROUP BY, agregaciones — con edición visual y un agente de IA con tus propias claves de Bedrock.

Prueba gratuita de 30 días, sin tarjeta — después, el plan Free sin límite de tiempo.