レコードロックについて

Question

DBアクセスで更新系の処理を行う際に、別トランザクションとの競合を防ぐため、レコードロックなどの排他制御を行いますが、レコードロックする対象テーブルについて質問です。
子テーブルの項目を更新する際でも、親テーブルの更新日時などの項目を更新するため、レコードロックするのは親テーブルのキーのみで問題ないと感じるのですが、更新対象のテーブルは全て紐づくレコードをロックすべきなのでしょうか。
レコードロックするテーブルの順序は統一するため、全ての更新対象のテーブルに対してレコードロックしなくてもよいと考えています。
また、ロックする分パフォーマンスにどう影響するのか、上記の方法でデッドロックするケースがあるか、など知りたいです。

Answer 1

細かくロックしていくと、処理の順序が守り切れずにデッドロックが発生する可能性はありますね。
まあ、人災の類ですが。

やり方は色々あるとは思いますが、一度もデッドロックは経験していない手法を紹介しておきます。

一連のトランザクション処理に名前を付けて、その名前をユニークキーとした発番テーブルを準備します。
トランザクション開始時にそのテーブルをfor update付きでselectします。
レコードの解放はCOMMITやROLLBACKにより行われます。
これで、一連処理のテーブルの更新順序を気にする必要は無くなります。
但し、処理が長時間になりタイムアウトが発生するような場合には、タイムアウト値の調整などの考慮が必要です。
※発番テーブルを利用しているのは、トランザクション内で大量に発番するような場合も都合がいいので。

上記は解放されるまで後続が待たされるわけですが、アセンブラでのXCHG命令のような手法で、待機しない方法もあります。
ロック用のフラグ項目(1:ロック,0:アンロック)に対して、update XXX set flg=1 where flg=0という更新を行います。
更新されればロックの獲得、更新されなければロックを獲得できなかった、という状態を判定でき待機せずに済みます。
※上記のXCHG云々は所謂、楽観的排他でした。

Comments

[退会済みユーザー]

ご回答ありがとうございます。
質問ですが、
一連のトランザクションに名前をつけて〜
の箇所ですが、別機能のトランザクションから更新処理が行われる場合も制御できるのでしょうか。
別のトランザクション名で管理すると思いますのでその場合は制御できないのではと考えています。

[sazi]

一連の塊に名前を付けて管理するので、その管理内に入れるかどうかは設計次第です。
通常別なトランザクションであれば後続は待たされます。
どのような排他を考えられているのでしょうか？

[sazi]

提示している方法は、あなたの仰っている親さえロックすればいいという考えと同じものですよ？