なので、いくらか調べた。まずはBerkeley DBのロック階層から。
The actual conflict matrix used by Berkeley DB to support the underlying access methods is more complicated, but this matrix shows the lock mode relationships available to applications using the Berkeley DB Locking subsystem interfaces directly.
In a conflict matrix, the rows indicate the lock that is held, and the columns indicate the lock that is requested. A 1 represents a conflict (that is, do not grant the lock if the indicated lock is held), and a 0 indicates that it is OK to grant the lock.
Notheld Read Write IWrite IRead IRW Notheld 0 0 0 0 0 0 Read* 0 0 1 1 0 1 Write** 0 1 1 1 1 1 Intent Write 0 1 1 0 0 0 Intent Read 0 0 1 0 0 0 Intent RW 0 1 1 0 0 0
Intentロック同士は一切競合しないところがポイントっぽい。
SQL Serverの場合も調べることができた。うーむ。まだよくわからない。
ロック階層を設定するのに使用します。インテント ロックには、インテント共有 (IS)、インテント排他 (IX)、およびインテント排他付き共有 (SIX) があります。
例えばの使い方としては、行ロックをする際に、テーブルに対してIntent Writeロックを獲得しておいて、目的の行をロックしておく。そうすると、目的の行のロック後の操作を害するテーブル構造の変更（列の削除）などを防ぎつつ、その他の行のロックを許可するということが可能になる。
