同時更新：最後の在庫を、二人が買おうとしたら

残り1個の在庫を題材に、読み取り後の更新が競合する理由、条件付きUPDATE、行ロック、COMMITとROLLBACKを追う。

二人が、同じ残り1個を見る

最後の一冊をAとBが同時に購入しようとしています。二つのトランザクションがそれぞれ SELECT stock を実行し、どちらも1を得ました。

ここではPostgreSQLの既定の分離レベルであるRead Committedを前提にします。通常のSELECTは、その文が始まった時点のスナップショットを読みます。他の取引がまだ確定していなければ、同じ残数が返ることはあります。

「画面で在庫1と見えた」ことだけでは、後の購入時にも残っている約束にはなりません。PostgreSQL 17：Read Committed

アプリ側でそれぞれ 1 - 1 を計算し、条件なしで stock=0 を保存したらどうなるでしょう。Aが0にして予約を作り、その後Bも0にして別の予約を作れてしまいます。

更新が行ロックで順番に実行されても、Bの更新値が「以前読んだ1から計算した0」のままなら、この設計の問題は消えません。最後の在庫表示は0でも、予約は二つです。

BEGINとCOMMITで囲むことは必要な道具ですが、取引の中の確認方法と分離レベルも重要です。トランザクションという名前だけで、競合が自動的に意図どおり解消されるわけではありません。

在庫が正の行だけ、その場で1減らします。購入処理は、この文が行を返した場合だけ予約追加へ進めます。

sql

UPDATE inventory
SET stock = stock - 1
WHERE sku = 'BOOK' AND stock > 0
RETURNING stock;

図の前提としてskuは一意に一つの在庫行を指します。0行だった場合は、在庫不足などとして扱い、予約を作りません。更新成功と予約追加を同じトランザクションに入れることも、この方法の一部です。

これは説明用SQLです。実際の購入APIには、所有者や権限、重複した購入依頼などの別の確認も必要です。

Aの条件付きUPDATEが先に対象行を更新したとします。Aの取引内では在庫が0になりましたが、まだCOMMITしていません。図の0はAが更新中の値であり、他の通常のSELECTへ未確定値が見えるという意味ではありません。

Bも同じ行をUPDATEしようとすると、先に更新したAの完了を待ちます。その間にAは、同じトランザクション内で予約を追加します。

図は、一行を競合して更新する単純な場面です。複数行を別の順序でロックする処理などでは、デッドロックや再試行も考慮します。PostgreSQL 17：同時更新

AがCOMMITしました。待っていたBは、更新された行に対してWHERE条件を確かめ直します。残数0なので stock > 0 は成立せず、この例では更新結果が0行になります。

アプリはその結果を見て、Bの予約を追加しません。AがROLLBACKしたなら、Bが処理を続けられる結果も変わります。

この説明はPostgreSQLのRead Committedにおける動作です。他の分離レベルではエラーや再試行が必要になる場合があります。特定のDBと分離レベルの振る舞いを確認して設計することが大切です。

Aが在庫を減らした後、予約の追加に失敗した別の経路を考えます。両方を同じトランザクションに入れていれば、ROLLBACKで在庫の変更も取り消せます。在庫だけ減った状態を確定させずに済みます。

トランザクションは、DB内の変更をまとめて確定するか、取り消すかを選ぶための境界です。既に送ったメールや、別サービスに確定させた決済まで、DBのROLLBACKで取り消せるわけではありません。

外部処理を含む場合は、冪等性やアウトボックスなどを別に検討します。PostgreSQL 17：トランザクション

答えはいいえです。確認から更新までの間に、別の取引が状態を変えられます。この作品では、条件付きUPDATE、更新結果の確認、在庫と予約をまとめるトランザクションで対処しました。

複雑な条件には SELECT FOR UPDATE でのロックや、Serializableと再試行など、別の設計が合うこともあります。一行の在庫減算の方法が、複数行にまたがるすべての整合性を守るわけではありません。

考える順序は、いつ条件を確かめるか、何を一緒に確定するか、競合した結果をどう扱うか。この三点を図にすると、同時更新の抜け道を見つけやすくなります。