基本情報 平成27年度 秋期 問29｜テクノロジ系に関する問題

答えは b「共有ロックされた資源には、共有ロックは取れるが専有ロックは取れない」です。

ロックは図書館の本に例えるとわかりやすい。

• 共有ロック（読むだけ）＝みんなで一緒に読書OK
• 専有ロック（書く）＝一人で独占して書き込み中、他の人は読めない

誰かが「読書中」のとき、別の人も読書（共有）に加われるけど、書く（専有）のはできません。

👉 覚え方：「読みは譲り合えるけど、書きは独占」。

ほかの選択肢：a 共有時に専有が取れる＝×／c 専有時に他が割り込める＝×／d 専有時に専有なら取れる＝×（専有ロック中はどちらも取れない）。

なぜこれが正解か

正解は b。ロックの両立性（Lock Compatibility）の原則は次の表で表される：

共有ロック（Shared Lock：読み取り用）同士は両立可能、専有ロック（Exclusive Lock：書き込み用）は他のいかなるロックも排除する。

各選択肢の解説

• a 誤り：共有ロック取得中に専有ロックは取れない（書き込み中は他の読み取りも止める必要があるため）。
• c 誤り：専有ロック中は共有ロックも取れない（読み取り一貫性確保のため）。
• d 誤り：専有ロック中は別の専有ロックも取れない。

覚え方・ひっかけ注意

「共有⇔共有：OK／その他全部：NG」とシンプルに記憶。共有ロックの目的は「読み取り中に変更されない保証」、専有ロックは「自分以外何もさせない」。デッドロック検出・回避（ウェイトダイ／ウンドダイ方式）と併せて出題されることが多い。

理論的背景

ロック粒度（テーブルロック・ページロック・行ロック）、ロック方式（悲観的ロック・楽観的ロック）、トランザクション分離レベル（READ UNCOMMITTED / READ COMMITTED / REPEATABLE READ / SERIALIZABLE）はACIDのI（Isolation）を実現する仕組み。2相ロッキングプロトコル（2PL：Two-Phase Locking）はロック取得フェーズと解放フェーズを分離することで直列化可能性を保証する。

実務での使われ方

商用DBMSの実装：

• Oracle：MVCC（Multi-Version Concurrency Control）でリードロック原則不要
• PostgreSQL：MVCC＋明示的ロック（SELECT FOR UPDATE / FOR SHARE）
• MySQL InnoDB：行ロック＋次キーロック（Next-Key Lock）でファントム読み防止

WebアプリではDB側ロックよりアプリ層の楽観的ロック（version列＋WHERE句チェック）が主流で、ロング待機回避とスケーラビリティを両立する。

試験での位置づけ

データベース分野で頻出。基本情報・応用情報・データベーススペシャリストで隔回出題。デッドロック検出・回避、分離レベルとアノマリ（ダーティリード／ファジーリード／ファントムリード）の対応は必須暗記。

選択肢の発展補足

• ロックエスカレーション：行ロック多数→ページロック→テーブルロックへ昇格（オーバーヘッド削減）。
• インテンションロック（IX/IS/SIX）：階層ロックで上位レベルへの予告。
• スナップショット分離（SI：Snapshot Isolation）：MVCC実装の中核。書き込みスキューに弱いがSerializable Snapshot Isolation（SSI：PostgreSQL）で対策。
• 分散DBでは2PC（2相コミット）・PaxosやRaftによる合意形成と組み合わせ、CAP定理／PACELC定理の文脈で出題される。