令和4年度秋期 データベーススペシャリスト 午前Ⅱ 問13

並行バッチのロック設計視点

複数の処理が同じ資源を扱う場面では、処理間の待ち関係に注目し、資源の確保や解放がどのように組み合わさるかを整理して、停止し続ける可能性を設計上の観点から確認することが重要になる。

この問題で問われていること

この問題では、個々の処理速度や実行順の細部ではなく、複数処理が共有資源を順番に扱うとき、互いの待機関係が循環し得るかを見抜く観点に絞って設計を読み取る。

視点

デッドロックを検討するときは、処理同士がどの資源を待ち、保持したまま別の資源を待つ可能性があるかという関係に着目する。処理単体ではなく、並行実行時の依存関係を図式化して考えると整理しやすい。

確認ポイント

• 共有資源の利用関係を整理する
• 処理間の待機関係を確認する
• 待ち関係が循環する可能性を検討する

正解

エ

解説

複数のバッチ処理が同じ複数レコードを更新する場合、ロック取得の順序を全処理で統一すると、互いに相手のロックを待つ循環待ちを防ぎやすくなる。

理由

デッドロックは、処理Aがレコード1をロックしてレコード2を待ち、処理Bがレコード2をロックしてレコード1を待つような循環待ちで発生する。全バッチが同じ順序でロックを取得すれば、この循環を作りにくくできる。

比較

参照だけのレコードに専有ロックを掛けると競合を増やし、大量データを一つのトランザクションにまとめるとロック保持時間が長くなる。また、必要なレコードを一括ロックして待ち続ける方法も、競合や待機を減らす基本方針とはいえない。

選択肢ア

これは不正解だよ。参照するだけのレコードに専有ロックを掛けると、更新の必要がない処理まで他の処理と競合しやすくなる。ロック対象が増えることで待機時間が延び、デッドロック回避の設計方針とは反対に、競合を発生させる可能性が高まる。

選択肢イ

これは不正解だよ。大量データへの処理を一つのトランザクションにまとめると、処理完了までロックを保持する時間が長くなりやすい。その間に他のバッチ処理が待たされ、ロック競合が増えるため、デッドロックをできるだけ避ける設計として適切ではない。

選択肢ウ

これは不正解だよ。必要なレコードを開始直後に全て専有ロックする方法は、競合範囲を広げる。さらに、ロックに失敗した処理が待って再試行すると、他の処理との待機関係が複雑になり、デッドロックの発生を十分に防ぐ方法とはいえない。

選択肢エ（正解）

これは正解だよ。複数レコードを更新する処理で、各バッチが異なる順序でロックを取得すると、互いに相手のロック解放を待つ循環待ちが起こり得る。全バッチでロック取得順序を統一すれば、待ち関係の循環を防ぎ、デッドロックを回避しやすくなる。

学習のポイント

デッドロックの原因と、ロック順序を統一する設計上の効果を理解する。