4.1トランザクションとACID特性

銀行の振込処理やECサイトの注文確定処理を設計するアプリケーション開発者にとって、「どこからどこまでを1つのトランザクションにまとめるか」というトランザクション境界の設計は、業務データの整合性を左右する重要な判断です。境界が狭すぎれば一部の更新だけが反映される不整合が生じ、広すぎればロック保持時間が延びて他の処理を待たせます。この節では、ACID特性という設計原理を踏まえてトランザクション境界をどう引くべきかを判断する視点を養います。

4.1.1ACID特性の4要素

• 原子性（Atomicity）＝トランザクション内の一連の更新が「全て実行される」か「全く実行されない」かのいずれかになる性質。COMMITで確定し、途中で異常が起きればROLLBACKで全ての変更を取り消す。振込処理で「出金は成功したが入金は失敗した」という中途半端な状態を防ぐのが原子性の役割。
• 一貫性（Consistency）＝トランザクションの実行前後でデータベースが定義された整合性制約（主キー・外部キー・検査制約等）を満たし続ける性質。隔離性（Isolation）＝同時実行する複数のトランザクションが互いの中間状態を見えないようにし、あたかも1つずつ順番に実行されたかのような結果を保証する性質（次節・次々節で詳述）。耐久性（Durability）＝COMMIT完了後の変更は、その直後に障害が発生してもディスク等の不揮発性記憶に確実に残り続ける性質。

4.1.2トランザクション境界とCOMMIT/ROLLBACK

• トランザクション境界＝BEGIN（トランザクション開始）からCOMMITまたはROLLBACKまでの一続きの処理範囲。境界内の更新は原子性により一体として扱われるため、業務上「意味のある1単位の処理」を境界にするのが基本原則——例えば振込処理なら「出金＋入金」の両方を1つのトランザクションに含めなければ、一方だけが反映される不整合を防げない。
• 境界を必要以上に広く取ると、その間ロックが保持され続け（次節で詳述）他のトランザクションを待たせる時間が延びるため、「整合性を守るために必要な最小の範囲」に境界を絞ることが性能とのバランスを取る鍵になる。逆に境界を分割しすぎると、分割した複数のトランザクションの間で一貫性が保証されなくなり、業務要件を満たせなくなる。

あるECサイトの開発者が、注文確定処理を設計しているとします。この処理は「注文レコードの作成」「在庫数の減算」「ポイント残高の加算」という3つの更新から成ります。もし各更新を別々のトランザクションとしてCOMMITしてしまうと、注文レコードは作成されたのに在庫減算だけが何らかの理由で失敗し、在庫数が実態と合わなくなる不整合が生じかねません。そこで開発者は、この3つの更新をまとめて1つのトランザクション境界に含め、途中でエラーが起きればROLLBACKで3つとも取り消すように設計します。これにより原子性が担保され、注文が「完全に成立している」か「全く成立していない」かのどちらかになります。ここで陥りやすい誤りは、「トランザクションを長く保つほど安全だから、注文確定後のメール送信や外部決済サービスへの問い合わせなど、時間のかかる外部I/Oも同じトランザクションに含めるべきだ」という判断です——外部サービスへの問い合わせは失敗率やレイテンシが読みにくく、トランザクション境界に含めるとロック保持時間が不必要に延びて他の注文処理を待たせるため、外部I/Oはトランザクションの外に出し、内部データの整合性が必要な更新だけを境界に含めるのが適切な設計判断です。

4.1.3この節のまとめ

• ACID特性＝原子性（全実行or全く実行しない）・一貫性（整合性制約維持）・隔離性（中間状態非可視）・耐久性（COMMIT後は残る）
• トランザクション境界は業務上意味のある最小単位に絞り、外部I/Oは境界の外に出す
• 境界を広げすぎるとロック保持時間が延び他処理を待たせる——性能とのバランスが設計判断の核