Coffmanの循環待機条件 2025/11/03

お仕事で、書き込みの順序性を保つのにコードマスターにロックキーを用意して行ロック(select for update)で実現している方式に出会いました。
なぜにコードマスターで、思わないこともないのですが、そういうものなのです。
ロックキーは１テーブルごとへの書き込みを表現しているようで、複数のテーブルにまたがる場合には、どうするのですか。

A,B,C,Dというテーブルがあって、ある処理では、A,Bのみ、別の処理では、A,B,C,Dという具合。
直感で、やばい香りがするわけで、やばい匂いといってよいでしょう。
もともと、no waitをつけていない。よいこのみんなは真似してはいけないよ、のデッドロック(Dead Lock)。
こういう場合は、SQLを処理ごとにまかせるのではなく共通処理にして呼び出すというのは、多くの人が気がつくことなのでしょう。
それでロックする順序が大事なわけです。
1行ロックをとる場合は、よいのですが、複数行を１セッション(プロセスといっていいのか)でロックする場合は、ロック行の順序が大事だよ。

SELECT * FROM AAAA WHERE a IN('A','B','C','D') ORDER BY a FOR UPDATE

ORDER BY大事よ。
理論的な背景は僕にはないのですが、


以下、クロードさんに尋ねました。
Coffmanの4条件(デッドロック発生の必要十分条件)※必要十分条件

必要条件 (Necessary Condition)
十分条件 (Sufficient Condition)
必要十分条件 (Necessary and Sufficient Condition)

Mutual Exclusion (相互排除)
Hold and Wait (保持と待機)
No Preemption (非横取り/非プリエンプション)
Circular Wait (循環待機)


以下、クロードさんに考えてもらったブルグのタイトルと内容
Coffmanの4条件、実務で崩せるのは実質1つ説」
実務的には:

相互排除: 崩せない(ロックは必要)
保持と待機: 崩しにくい(トランザクション分割は難しい)
非横取り: 崩せない(DBMS仕様)
循環待機: ORDER BYで崩せる! ← ここがポイント