2 人が同時に書いて修正が消えた (同時実行制御)

事故 — 2 人が別々の行を修正しただけで、片方の修正が消えた

経理担当 A と担当 B は、共有ドライブに置かれた売上 Excel をそれぞれ自分の PC で開いていた。 A が行 45 の金額を ¥98,000 → ¥120,000 に修正して保存。ほぼ同時に B が別の行 88 の顧客名を修正して保存した。 B が上書き保存した時点で B の PC の版には A の修正が含まれておらず、B の保存が売上シート全体を「B の版」で上書きし、A の修正 (行 45) が消えた。

週次で月次売上を集計した時、A の修正が反映されておらず、報告値が実際と食い違って初めて発覚した。 これが Lost Update (更新消失)。

※ 冒頭の「壊れた Excel」に仕込んだ 同一 ORD-001 が 2 行できる違和感 も、同じ concurrency 系統の事故。 こちらは「A と B がほぼ同時に新規注文を起票し、それぞれ手元で『次の注文ID は ORD-001』と採番して衝突」という別メカニズムだが、 いずれも「他人の並行操作を DBMS が調停してくれない」ことが根本原因。

原因 — Excel には行 / セル単位のロック機構がない

Excel の共有ファイルは、各自が自分の PC でコピーを編集して戻す方式が多い。 このパターンでは、A と B が別々の行を修正しても、後で保存した版が全体を上書きし、先の修正が消える。 「別の行を触っただけなのに他人の変更まで消える」のは、Excel が 「あなたが変更した行だけをトランザクション単位でロックする」細粒度の制御を持たないため。

OneDrive の同時編集や Excel の共有ブックでは、同じセルへの同時編集はLast Write Wins (後勝ち) になる。方式を変えても 「変更したセル (or 行) だけを他人から守る」細粒度制御がない点は共通している。

解決策 — ロックと分離レベル

1. 悲観ロック — 「触ったら他人を待たせる」

書き換えたい行を最初に SELECT ... FOR UPDATE で明示的にロックする。 他のトランザクションはそのロックが解放されるまで待たされる。

BEGIN;
SELECT amount FROM sales WHERE id = 45 FOR UPDATE;
-- 他のトランザクションはここで待たされる
UPDATE sales SET amount = 120000 WHERE id = 45;
COMMIT;

2. 楽観ロック — 「保存直前にバージョンを確認」

行に version 列を持たせ、UPDATE の WHERE で読んだ時のバージョンを条件に含める。 他人が先に書き換えていたらバージョンが変わっているので UPDATE は 0 行にヒットして失敗、リトライする。

UPDATE sales
   SET amount = 120000, version = version + 1
 WHERE id = 45 AND version = 12;
-- 影響行が 0 なら他人が先に書き換えている → リトライ

3. 分離レベル (Isolation Level) — DBMS の既定挙動

SQL 標準で 4 段階 (READ UNCOMMITTED / READ COMMITTED / REPEATABLE READ / SERIALIZABLE) が定義されている。 PostgreSQL の既定は READ COMMITTED。厳密な整合性が必要な処理では SERIALIZABLE を局所的に使う。

4. MVCC (多版同時実行制御)

PostgreSQL や Oracle は行に「バージョン」を内部で持ち、書き込みが読み取りをブロックしない設計 (MVCC)。 読み取りは常に「トランザクション開始時点のスナップショット」を見るため待ち時間が減る。 ただし書き込み同士の競合と 書き込みスキュー は別途対処が必要。

境界事例

• 分離レベルは高いほど遅い: SERIALIZABLE は高コスト。競合予測に基づいて必要な範囲だけに絞る
• デッドロック: 2 つのトランザクションが互いの行をロックし合って進めなくなる状態。 DBMS は片方を検出して自動 ROLLBACK する
• MVCC でも起こる書き込みスキュー: 「両者ともスナップショットを見て別々に更新したら、直列実行では起こり得ない結果になる」異常。 SERIALIZABLE への昇格や述語ロックで防ぐ