基本情報 平成26年度 春期 問30：テクノロジ系に関する問題

答えは a です。

ロックの基本ルール（前出と同じ問題のおさらい）:

• 共有ロック（読むだけ）：複数人が同時に読むのはOK
• 専有ロック（書く）：1人だけが独占、他は読むことも書くこともダメ

だから「共有ロック中に別の共有ロック」が成立するのは a だけ。

👉 覚え方：「読み読みOK、それ以外NG」。

ほかの選択肢：b/c/d は「書く」が絡んで必ず競合します。

なぜこれが正解か

正解は a。共有ロック（Sロック）は読取専用で複数同時取得可、専有ロック（Xロック）は書込み用で他のいかなるロックとも両立しない。両立性マトリクス:

| 既存＼新規 | S | X |

|---|---|---|

| S | ○ | × |

| X | × | × |

aは「共有→共有」で唯一の○、他は×。

各選択肢の解説

• a 共有→共有：同時複数読みOK（正解）。
• b 共有→専有：読取中の書込みは整合性破綻のためNG。
• c 専有→共有：書込み中（コミット前）の読取はDirty Readを引き起こすためNG。
• d 専有→専有：書込み競合のためNG。

覚え方・ひっかけ注意

「読み読みOK、それ以外NG」でほぼ全ての併用問題が解ける。本問は前問77d87edcとほぼ同問題で、FE頻出パターン。`SELECT ... FOR UPDATE` はSロックではなくXロックを取る点に注意。トランザクション分離レベル（READ UNCOMMITTED〜SERIALIZABLE）によりロック取得タイミングが変わる。MVCC（多版同時実行制御）採用DBMSでは古いスナップショットを参照することでロック取得を回避する設計が採用される。

理論的背景

ロック方式は2相ロッキングプロトコル（2PL）の枠組みで議論される。基本則は「拡張相（lock取得）と縮小相（lock解放）が明確に分離されれば直列化可能性が保証される」というもの。Strict 2PLではcommit/rollback時まで全ロックを保持しカスケードアボートを防止。Conservative 2PLでは開始時に必要な全ロックを取得、デッドロックを完全回避するが並行性が低い。

ロックの粒度: データベース・表・ページ・行・属性（列）と階層化される。粒度が小さいほど並行性は高いがロック管理オーバヘッドが増大する。粒度間の効率的な調整はインテンションロック（IS, IX, SIX）が担う。テーブルにISを取った上で行Sを取り、別TXがテーブルXを取ろうとした際の判定を高速化。

実務での使われ方

MVCC（Multi-Version Concurrency Control）は近代RDBMSの主流並行性制御。各行に複数の版を保持し、読み手は古い版（自分のトランザクション開始時点のスナップショット）を参照、書き手は新しい版を作成。読み書きが互いをブロックしないため並行性が劇的に向上。Oracle/PostgreSQLは完全MVCC、MySQL InnoDBは行ロック+MVCC、SQL Serverは選択的MVCC（READ_COMMITTED_SNAPSHOT_ISOLATION）。

MVCCの欠点: ①バキューム/ガベージコレクションが必要（PostgreSQLのVACUUM、Oracleのundo領域）、②書込み時の領域膨張、③Phantom Readは別途SERIALIZABLE分離レベル（PostgreSQLはSerializable Snapshot Isolation、SSI採用）が必要。

デッドロック検出: Wait-For Graphで循環待ちを検出→犠牲者選択（コストが最小の犠牲者を選ぶ）→ロールバック。アプリ側ではロック取得順序を統一しデッドロック発生を予防。

試験での位置づけ

FE/AP/DBスペシャリスト/SCで超頻出。①ロック両立性マトリクス、②2PL、③デッドロック、④分離レベル（4種類）と現象（Dirty Read/Non-repeatable Read/Phantom Read/Lost Update）、⑤MVCC、が主要論点。本問は基本問題で確実に得点。

選択肢の発展補足

分離レベルの4段階とMVCC観点での実装:

• READ UNCOMMITTED（Dirty Read許可）：MVCC無効、ロックも最小限
• READ COMMITTED（Dirty Readなし）：MVCCで最新コミット済み行を参照
• REPEATABLE READ（Non-repeatable Readなし）：MVCCでTX開始時スナップショット参照
• SERIALIZABLE（Phantom Readもなし）：SSI（Serializable Snapshot Isolation）またはS/Xロック+述語ロック

楽観的並行制御（Optimistic Concurrency Control, OCC）はバージョン番号によるCASで衝突検出、競合が少ない環境で高効率。Webアプリ・マイクロサービスではOCCが主流（HTTPのETag、JPAの@Version）。NoSQL分散DBではCAP定理の制約下で最終的整合性、補償トランザクション（Saga）、分散トランザクション（2PC/3PC）等の代替アプローチが採用される。