DynamoDB TransactionConflictException

TL;DR — 另一個事務已經在操作與你請求相同的項目，因此 DynamoDB 為保持隔離性拒絕了你的。它是瞬時的爭用，而不是你資料中的 bug——用指數退避重試、讓事務保持小巧，並減少對同一個熱點項目的並行寫入。

這是什麼意思

TransactionConflictException: Transaction is ongoing for the item

DynamoDB 會把與進行中事務衝突的寫入序列化。當一個普通的 PutItem、UpdateItem 或 DeleteItem 與一個包含同一個項目的進行中 TransactWriteItems 碰撞時，你就會遇到這個異常。DynamoDB 不阻塞，而是用 TransactionConflictException（HTTP 400）拒絕這個單項目寫入。它可重試——一旦另一個事務提交或中止，衝突就消除。

注意與 TransactionCanceledException 的區別：當輸掉的請求本身是一個 TransactWriteItems 或 TransactGetItems 時，DynamoDB 會轉而取消那整個事務——你得到的是一個_取消_，其 CancellationReasons 攜帶 TransactionConflict 作為逐項目的原因程式碼，而不是這個異常。

為什麼會發生

對同一個項目的並行寫入——一個普通的 PutItem/UpdateItem 與一個觸及該項目的進行中 TransactWriteItems 重疊。
兩個共享一個項目的事務——兩個 TransactWriteItems 請求同時包含同一個鍵；一個勝出，另一個以 TransactionConflict 原因程式碼被取消（表現為 TransactionCanceledException）。
一個在大量並行更新下的熱點項目——例如一個共享計數器或一個每個請求都更新的單一聚合行。
長或大的事務持有項目足夠久以致與其他寫入者重疊。
一場重試風暴——沒有退避的重試把更多並行嘗試堆到同一個被爭用的項目上。

如何修正

用指數退避 + 抖動重試。 這是主要的修復方法——衝突是瞬時的，在另一個事務穩定後消除。保留抖動，讓重試不會重新同步成又一次碰撞。
讓事務保持小巧和簡短——每個 TransactWriteItems 更少的項目意味著更短的持有和更少的重疊。
減少熱點項目上的爭用——把一個熱點計數器分片到多個項目上並聚合，或者當你不需要全有或全無語義時，用一個帶普通 UpdateItem（ADD）的原子計數器代替事務。
如果可以避免，就不要對同一個項目並行地混用一個事務和一個普通寫入——把兩者都透過同一條路徑路由。
監控 TransactionConflict CloudWatch 指標，看爭用是否在上升以及在哪裡。

當並行寫入者就是你自己——你的應用在寫同一張表的同時你在手工編輯項目——DynoTable 的暫存區會把你的手工編輯批次成一次由你一次性審閱並提交的事務性寫入，而不是一連串相互重疊的單項目寫入。

在 DynoTable 中檢查

當並行編寫者是你時，透過暫存 (⌘S) 進行批次手動編輯 - DynoTable 將它們作為一次審閱的寫入提交，而不是重疊的單項更新流。使用 ⌘K 開啟競爭項目並在重試之前檢查實時狀態。使用 pricing calculator 調整交易流量。使用 ⌘P 切換設定檔案； 在“設定”→“設定檔案”上測試連線。參見連線 AWS和安裝。

來源

Amazon DynamoDB Transactions: How it works（2026-07-13 驗證）
PutItem — Amazon DynamoDB API Reference（2026-07-13 驗證）

常見問題

如何修復 DynamoDB 中的 TransactionConflictException？ 使用指數退避和抖動重試請求 - 衝突是與同一項目上的另一個正在進行的事務的短暫爭用。還要保持事務較小，對熱門項進行分片，並避免同時對同一項執行事務和純寫入。

TransactionConflictException 與 TransactionCanceledException 相同嗎？ 否。TransactionConflictException 表示當前正在對該項目進行另一個事務操作。 TransactionCanceledException 表示整個事務被回滾；它的 CancellationReasons 解釋了原因，交易衝突可能是這些原因之一。

參考資料

最後核實於 2026-07-13，依據上方連結的 AWS 官方文件。