データベーススペシャリスト 2013年午前2 問10

問題文

t_{1}

~~$t_{10}$ の時刻でスケジュールされたトランザクション $T_{1}$~~

T_{4}

がある。時刻

t_{10}

で

T_{1}

がcommitを発行する直前の、トランザクションの待ちグラフを作成した。aに当てはまるトランザクションはどれか。ここで、select(

X

)は共有ロックを掛けて資源

X

を参照することを表し、update(

X

)は専有ロックを掛けて資源

X

を更新することを表す。これらのロックは、commitされるまでアンロックされないものとする。また、トランザクションの待ちグラフの矢印は、

T_{i}

→

T_{j}

としたとき、

T_{j}

がロックしている資源のアンロックを、

T_{i}

が待つことを表す。

🖊️ 解答を隠して解いてみる

選択肢

ア：

T_{1}

イ：

T_{2}

（正解）

ウ：

T_{3}

エ：

T_{4}

🔒 解説は解答すると表示されます

待ちグラフのノード割当【午前2解説】

正解の理由

待ちグラフのノードaは、待ち辺a → dが示す「aがdの保持するロックの解放を待っている」ことに対応します。スケジュールを時刻順に見ると、T₂ は時刻t7にselect(C)（共有ロック）を取り、t8のupdate(C)（排他ロック取得を試みる）で排他化のために共有ロックを保持しているT₁ の解放を待つ挙動をします。すなわちaが待っている相手dはT₁、したがってaはT₂ に対応します。よってaに該当するトランザクションはイ（T₂）です。

解法ステップ

待ちグラフの矢印の意味を確認する。矢印T_i → T_jは「T_iがT_jのロック解放を待っている」ことを表す。
スケジュールのロック取得・更新の時刻を順に確認する。特に排他ロック（update）を試みたときに既存のロックによって待ちが発生する箇所を探す。
各有向辺とスケジュールの対応を照合する。
- グラフのc → d：cがdを待つ。スケジュールでT₃ はt3にselect(A)、t9にupdate(A) を試みる。T₁ はt1にselect(A) を取り、t10のcommitまで保持するため、T₃（update(A)）はT₁ を待つ。よってc = T₃、d = T₁。
- グラフのb → a：bがaを待つ。スケジュールでT₄ はt4にselect(B)、t5にupdate(B) を試みる。T₂ はt2にselect(B) を取りt2以降保持しているため、T₄ のupdate(B) はT₂ を待つ。よってb = T₄、a = T₂。
- グラフのa → d：aがdを待つ。上でa = T₂、d = T₁ となる挙動は、T₂ がt7にselect(C)（共有）を取りt8にupdate(C) を試みるが、T₁ がt6にselect(C) を取りt10まで保持しているため、T₂ がT₁ を待つことと一致する。
以上よりノード割当はa=T₂, b=T₄, c=T₃, d=T₁ となる。

選択肢別の誤答解説

ア: T₁
T₁ はt1, t6にselectを取得し、t10にcommitするまでロックを保持している側であり、他を待つ（矢印の開始点になる）挙動はスケジュール上ほとんど見られない。グラフでaは誰かを待っている（a → d）のでT₁ をaに当てると一致しない。
イ: T₂
先述の通り、T₂ はCのupdateを試みる際にT₁ の共有ロックを待つ（a → d）ほか、Bでは他に共有ロックを与えており、グラフの構造と完全に整合するため正しい。
ウ: T₃
T₃ はAのupdate(t9)でT₁ の共有ロックを待つ挙動（c → d）を示すためcに対応する。a（待つ側でB/Cに関与）には合致しない。
エ: T₄
T₄ はBのupdate(t5)でT₂ の共有ロックを待つ挙動（b → a）を示すためbに対応する。したがってaにはならない。

よくある誤解

矢印の向きを逆に解釈する：矢印を「ロックを持っている側が待たれている」と読み違えるとノード割当を逆にしてしまう。矢印は「待っている側 → 待たれている側」。
共有ロック同士も待つと考える：共有ロック（select）は基本的に互いに競合しないため、共有取得同士では待たない。待ちが生じるのは通常排他（update）を取得しようとしたとき。
コミットでしかアンロックされない点を忘れる：合致する待ちが生じるのは、ロックを保持している側がまだcommitしていない場合に限られる。

補足コラム

待ちグラフ（wait-for graph）はデッドロック検出に有効です。グラフ上にサイクルが存在すればデッドロックが発生している可能性が高く、いずれかのトランザクションを中止（rollback）してサイクルを解消する対処が必要になります。本問題では有向辺はb→a, a→d, c→dとサイクルを作っておらず、デッドロックには至っていません。スケジュール解析では「いつどのロックを取得／解放するか」を正確に追うことが鍵です。

FAQ

Q. 共有ロックを取った後にupdateをする場合、なぜ待ちが発生するのですか？
A. 共有ロックから排他ロックへ「アップグレード」する際、排他ロックは他の共有ロックを排除する必要があるため、他のトランザクションが同じ資源の共有ロックを保持していると待ちが発生します。

Q. なぜT₃ のupdate(A) はT₁ を待つのですか？
A. T₁ がt1にselect(A) を取り、t10まで保持しているため（commitで解放する仕様）、T₃ のt9 update(A) は排他取得のためにT₁ の共有ロック解放を待つ必要があるからです。

関連キーワード: ロック, 待ちグラフ, 共有ロック, 排他ロック, デッドロック, スケジュール解析

← 前の問題へこの年度をクイズで解く次の問題へ →

\ せっかくなら /

データベーススペシャリストを
クイズ形式で学習しませんか？

クイズ画面へ遷移する→

すぐに利用可能！