インテントロックとは？

神谷 雅紀
Escalation Engineer

あるフォーラムでインテントロックが取り立たされているのを見かけたので、今回はインテントロックを話題にしたいと思います。

インテントロック (Intent Lock) とは、ロックモードのひとつで、より粒度の低いロックリソースにロックを保持していることを示すためのロックです。

以下の種類があります。

ロックは、SQL Server 内部コンポーネントのひとつであるロックマネージャ (Lock Manager) によって一元管理されています。ロックマネージャは、獲得済みロックの情報を保持し、また、ひとつのロックリソースに対して獲得されるロックを制御します。

例えば、ロックリソース「テーブル A 」にロックモード S のロックが既に獲得されている状態で、同じ「テーブル A」にロックモード X を獲得しようとすると、互換性がないため、ロックマネージャはロックモード X の獲得は許可しません。一方、ロックリソース「テーブル A 」にロックモード S のロックが獲得されている状態で、テーブル A に属する「行 B」に ロックモード X を獲得しようとしても、ロックマネージャはそれを許可します (これは、インテントロックというものが存在しない場合の仮の話です。実際にはインテントロックがあるため許可されません。)。その理由は、ロックリソースが「テーブル A」「行 B」と異なるロックリソースからです。ロックマネージャは、行 B がテーブル A に属していることを知りません。ロックマネージャは、単にひとつのロックリソースに対して獲得されるロックを制御するだけで、ロックの粒度は管理してません。

これでは、テーブル A をロックして読み取っているにも関わらず、テーブル A に属する行 B が更新されてしまう恐れがあります。

では、テーブル A に S ロックが獲得されている時に、テーブル A に属する行 B に X ロックを獲得させないようにするためにはどうすればいいでしょうか？

それを実現するためには、行 B がテーブル A に属していることを知っているロックの要求元が、行 B に X ロックを要求する前に、テーブル A にロックを獲得して、テーブル A に対して他のロックが獲得されないようにすることが必要です。

これを実現するために必要になるのが、インテントロックというロックモードです。

インテントロック同士はすべて互換性があるため、あるトランザクションが行 B に X ロック、テーブル A に IX ロックを獲得している状態であっても、別のトランザクションは行 C に S ロック、テーブル A に IS ロックを獲得することができます。さらに、IX は S, U, X とは互換性がないため、行 B に X を保持している間にテーブルに S, U, X を獲得されるということもなくなります。

インテントロックは、SQL Server を使用する上では、基本的に、ほとんど意識する必要のないロックです。