バッチ並行処理におけるデッドロック回避設計

デッドロック(Deadlock)は、複数のトランザクションが互いに相手の保持しているロックの解放を待ち合って永久に処理が進まなくなる現象です。 デッドロックの発生条件(相互排除、保持と待機、非横領、循環待機)のうち、「循環待機(Circular Wait)」を排除することが最も確実な予防策となります。 複数の資源(レコードやテーブル)を更新する際に、すべてのトランザクションであらかじめ定められた一意の順序(例: 主キー番号昇順)に従ってロックを獲得するように設計すれば、資源の獲得待ちループが絶対に生じないためデッドロックを完全に回避できます。 したがって、エ が適切なガイドラインです。 参照レコードに不要な専有ロック(排他ロック)を掛けるとロック競合の頻度が高まり、デッドロックの可能性を増大させます。参照には共有ロックまたは非ロック参照(MVCC等)を用います。 大量データを1つの巨大トランザクションにまとめるとロック保持時間が長期化し、他トランザクションとのデッドロックやタイムアウトを誘発します。適切にコミット分割すべきです。 ロック獲得失敗時に再試行(リトライ)するだけではデッドロックの根本的な防止にはならず、待機が繰り返される可能性があります。

複数のバッチ処理を並行して動かすとき, デッドロックの発生をできるだけ回避したい。バッチ処理の設計ガイドラインのうち, 適切なものはどれか。

出典2022r04a_db_am2_問13
ア
参照するレコードにも, 専有ロックを掛けるように設計する。
イ
大量データに同じ処理を行うバッチ処理は, まとめて一つのトランザクションとして処理するように設計する。
ウ
トランザクション開始直後に, 必要なレコード全てに専有ロックを掛ける。ロックに失敗したレコードには, しばらく待って再度ロックを掛けるように設計する。
エ
複数レコードを更新するときにロックを掛ける順番を決めておき, 全てのバッチ処理がこれに従って処理するように設計する。