トピック入口と開始文へ戻る。以下の数値例・図は概念説明で、本人の実測ではありません。
https://github.com/MFQWKMR4/tech2026 のCHATGPT.md、AGENTS.mdと次を読んでください。- src/content/docs/database/transactions.mdx- reviews/database-transactions.yaml- sessions/2026-09-17-database-transactions-01.yaml- public/diagrams/database-transactions/isolation.svg- public/diagrams/database-transactions/write-skew.svg- src/content/docs/practice/reflections/2026-09-17-database-transactions-01.mddatabase-transactions のlearnとして、気になる節を一つ確認してから、説明→疑問→具体例→理解確認を一つずつ進めてください。指定がなければneeds_revisitから始め、独力の回答とヒント・解説後を区別してください。参照できたファイルとrevisionを示し、読めないものや未確認の事実を補完しないでください。図の内容を読むことと描画の確認、教材検証と私の実績を区別してください。開始時刻を確認できれば記録し、40分付近で区切りを提案してください。終了時は既存テンプレートのYAML＋Session narrativeで[Session Sync]をMFQWKMR4/tech2026へ作成し、URLを返してください。作成できなければ未作成と明示してコピー可能な本文を返してください。最終レビュー：2026-09-17 · 説明した（Explained）。ヒント後の理解と自力の説明を区別して記録しています。
2026-09-17 00:21 EDT開始。途中で睡眠・日をまたぐ中断を挟み、2026-09-19と2026-09-21に再開して終了。残り1個の在庫購入を題材に、transaction境界、Atomicity、行ロック、SELECT FOR UPDATE、NOWAIT/SKIP LOCKED、条件付きUPDATE、optimistic/pessimistic locking、READ COMMITTED/REPEATABLE READ/SERIALIZABLE、write skew、高競合時のtrade-offまで確認した。外部決済APIはtransaction境界の確認として一部扱ったが、本人からDB transaction/lockを深めたい旨がありDBへ戻した。説明前に示せた内容と、説明・誘導後に理解した内容を区別する。
初案は在庫更新と購入記録を同じtransactionへ。競合制御は解法説明へ移行。Atomicity、writer待機・通常SELECT、RCの再読を説明し、分離レベル・手段のtrade-offは再確認が必要。
9/17開始・9/21終了の面接振り返りに初案・支援の順序・役割別の評価をまとめています。途中に解法説明を含むセッションで、独力テストだけの結果ではありません。ここは仕組みを読む教材です。対象はPostgreSQL 18。挙動を他DBへそのまま当てはめないでください。
演習条件はstock=1、同じ商品をA/Bが購入、購入レコードは一購入一行。在庫減算と購入記録を一つのtransactionにすることで、途中失敗時に両方を取り消せる。これがAtomicityの役割。一方、通常SELECTで双方が1を読み、それぞれアプリ内で0を計算して書くだけでは、READ COMMITTEDで両方が購入を記録し得る。transaction境界だけで、アプリが古い値に基づいて判断する問題は消えない。
単純な一商品の減算なら、同じtransaction内で次の条件付きUPDATEを使い、RETURNINGが1行返ったときだけ購入を記録する。0行はこの例では売り切れまたは商品不存在なので、購入INSERTへ進まない。購入INSERTが失敗すればtransactionをrollbackする。実装では商品不存在と売り切れをどう返すかも決める。
BEGIN;UPDATE inventory SET stock = stock - 1WHERE product_id = 42 AND stock > 0RETURNING product_id, stock;-- アプリで結果を確認。1行のときだけ購入INSERT、0行なら購入せず終了。-- INSERT失敗時はROLLBACK。両方成功時だけCOMMIT。これは説明用SQLで、今回のDB実測ではない。stockのCHECK制約は負数防止を補助するが、購入記録との対応や外部決済まで自動保証しない。外部APIはDBのrollback対象外なので、冪等性と決済状態を別途設計する。
次の図は、Bが最初にstock=1を読んだ後、Aが1→0を更新してまだcommitしていない時点を比較する。全体の処理時間や待機時間を表す尺度ではない。
| Bの分離レベル | Aが未commitの間の通常SELECT | Aのcommit後の通常SELECT | Bの条件付きUPDATE |
|---|---|---|---|
| READ COMMITTED（既定） | commit済みの1 | 次のstatementでは0 | Aの更新中なら待つ。commit後、更新された行でstock条件を再評価し0行 |
| REPEATABLE READ | Bのsnapshotの1 | 同じsnapshotの1 | snapshot後にAが同じ行を更新commitしたためserialization failure。全transactionを再試行 |
| SERIALIZABLE | この例ではRRと同じ | この例ではRRと同じ | 同じ行の競合に加えて、別行にまたがるread/write依存も監視する |
RRのsnapshotは単にBEGINした時点ではなく、最初のtransaction制御以外のstatementを基準にする。自分のtransactionの更新は自分で見える。Aがrollbackした場合は上表のcommit後とは結果が変わる。通常SELECTは行ロックと競合しないが、tableのACCESS SHAREは取るためDDL等との待機まで否定しない。PostgreSQL 18：分離レベル・ロック
| 方法 | 向く判断 | 支払うコスト・例外 |
|---|---|---|
| 条件付きUPDATE | stockが正なら減らす等、条件を更新へ埋め込める | UPDATEも行ロックを取り競合時は待つ。短い文でもcommitまで保持し得る |
| SELECT FOR UPDATE | 読んだ行を基に複数処理を判断し、その行の変更を排他したい | 通常は待機。往復と保持時間が増え、pool接続を占有。外部API待ちを含めない |
| NOWAIT | 待てないときは失敗として呼出し元に返せる | 行ロック取得不可なら即エラー。無制限retryは負荷を増やす |
| SKIP LOCKED | 複数候補のjobを複数workerが分担する | ロック中の候補が結果から欠ける。在庫1個では「売り切れ」と同義でなく、一般的な整合性確認に不向き |
| versionによる楽観ロック | 読んでから考える時間が長く、衝突が少ない | version不一致で0行なら再読・再判断。UPDATE自体はロック待機し得る |
| SERIALIZABLE + retry | 複数行・検索条件にまたがる不変条件 | 読取り依存の監視とabort/retry。すべての関連書込みが同じ整合性方針に従う必要 |
「楽観だからロックを取らず待たない」は誤り。例えばAがversion=5を6へ未commit更新中なら、Bのversion=5付きUPDATEはRCではAを待ち、Aのcommit後に条件を再確認して0行になり得る。既にcommit済みの不一致を見て0行になる場合と区別する。これはIssue #24の説明を同期時に補足した点で、本人が既に再確認できたとは扱わない。
高競合では悲観ロック一択とも、楽観ロック一択とも言えない。保持時間・再試行可能性・許容latency・競合区間を短縮できるかを並べる。低競合のversion検査は無駄な排他を減らせるが、高競合で全員が計算をやり直すなら損が増える。SELECTのlocking句
演習条件はA/Bの2人がON、「最低1人ON」を守る。各transactionが相手のONを読んで、自分だけOFFへ更新する。
RRでは更新対象が別行なので、双方commitして0人になり得る。一人ずつ直列なら後から実行した側は相手のOFFを読んで退勤を取りやめるはずで、同じ結果を説明する直列順序がない。Serializableの依存監視は、このような異常につながる実行をabortさせる。どちらが、どのstatementで失敗するかは固定しない。predicate lockは「全読取りを排他してwriterを待たせる」ロックではない。Serializable
| 代案 | 不変条件の守り方 | 代償 |
|---|---|---|
| テーブルの排他的な書込み制御 | 読取り判断の前に、他の更新と競合する適切なtable lockを取得 | 無関係な当直グループまで直列化しやすい。単に「table lock」という名称だけではモード不足 |
| 当直グループごとの共有カウンタ行 | 同じtransactionで人数が1より多いときだけ減らし、当人をOFFにする | 集約行がhot row。個人状態と人数の二重管理を常に整合させる |
| 全対象行を共通順序でロック | ルールに関係する全行を読み、共通手順で判断・更新 | 対象の漏れや新規行の追加も考える。自分の行だけでは不十分 |
| 各医師行 + SERIALIZABLE | 読取り条件と更新の依存から異常を防ぐ | abortしたtransaction全体の再試行が必要。関連する処理全体の方針をそろえる |
演習でpoolが50なら、1000リクエスト全部が同時にDB接続を保持するわけではない。最大50接続の中で行ロック待ちが増え、残りはpoolや入口で待つ。他APIとpoolを共用すれば影響が波及する。短いtransaction・入口の同時実行制限・待機期限を組み合わせ、売り切れ後に同じ仕事を続けない設計も検討する。
serialization failure（SQLSTATE 40001）は、最後のUPDATEだけでなく読取りと判断を含むtransaction全体をrollbackして再実行する。上限・backoff・jitter・リクエスト期限を設け、retryで外部副作用を重複させない。deadlockも全体の再実行やロック順序見直しが必要だが、今回の本人への問いは未出題だった。再試行の扱い
まずaffected rows=0の業務結果、SQLSTATE、pool取得待ち、DB内のlock wait、transaction時間を分ける。pg_stat_activityのwait_event_type/wait_event、pg_blocking_pids(pid)とpg_locksで誰が何を保持しているか確認する。CPUが低いだけで正常とはしない。強制終了を最初の手段にせず、長時間transactionや接続解放漏れを確かめる。
補強元：2026-09-17-database-transactions-01 / Issue #24の4依頼。対象PostgreSQL 18、一次資料確認2026-09-21。図とSQLは概念説明、二接続による再実験・本人の独力再テストは未実施。