LOCK

説明

LOCK TABLE は、トランザクション期間において、ある テーブルへの同時アクセスを制御します。 Postgres は可能である限り、常に最も制限 の弱いロックモードを使用します。より強い制限を持つロックを必要とす る場合のために LOCK TABLE が用意されています。

RDBMS におけるロックにて、以下の用語が使用され ます。

例えば、アプリケーションが隔離レベル READ COMMITTED でトランザクシ ョンを実行し、そのトランザクションの間テーブルにデータが存在するこ とを確実にする必要がある場合を考えてみます。 これを達成するために、問い合わせ実行前にテーブル全体に SHARE ロック モードを使用することができます。 これは同時変更からデータを保護するとともに、現在の実状態を維持したテーブル全体 に対して読みとり操作を引続き行えるようにします。 SHARE ロックモードは、書き込み側によって獲得されるあらゆる ROW EXCLUSIVE とコンフリクトし、実行した LOCK TABLE name IN SHARE MODE 文は同時書き込み操作のコミットまたはロールバックが終るまで待つからです。

上の要求事項に加え、トランザクションがテーブル内のデータを変更しよ うとするのであれば、SHARE ROW EXCLUSIVE ロックモードを獲得して、次の デッドロック状態を防止しなければなりません。 2 つの同時トランザクションがテーブルを SHARE モードでロックし、 そしてテーブル内のデータを変更しようとする場合、両者は (暗黙 的に) ROW EXCLUSIVE ロックモードを取得しようとしますが、このロック モードは現在獲得されている SHARE ロックとコンフリクトします。

上で取り上げたデッドロック (2 つのトランザクションがお互いに待ってい る状態)の問題に関してですが、デッドロック状態を防ぐために以下の 2 つの一般的なルールに従わなければなりません。

• トランザクションは同じオブジェクトに同じ順番でロックを獲得する必 要があります。

  例えば、あるアプリケーションが (同じトランザクションの中で) 行 R1 を更新し、そして行 R2 を更新する場合、別のアプリケーションは ( 1 つのトランザクションの中で)後で行 R1 を更新する予定がある ならば、行 R2 を更新してはいけません。その代わりに、最初のアプリ ケーションと同じ順番で行 R1 と行 R2 を更新しなければなりません。

• トランザクションは、2 つのロックモードの内の 1 つがそのモード自身 とコンフリクトする場合 (つまり同時に 1 つのトランザクションしかそ のロックを保持できない場合) にのみ、2 つのコンフリクトするロック モードを獲得しなければなりません。複数のロックモードが必要な場合 は、トランザクションは常に最も制限の強いモードをまず獲得しなけれ ばなりません。

  このルールの例は、既にSHARE モードよりも SHARE ROW EXCLUSIVE モ ードを使用すべきであるという部分で指摘済みです。

使用法

外部キーテーブルへの挿入を行なう際のプライマリキーテーブルへの SHARE ロックについて説明します。

BEGIN WORK;
LOCK TABLE films IN SHARE MODE;
SELECT id FROM films 
    WHERE name = 'Star Wars: Episode I - The Phantom Menace';
-- レコードが返されない場合は ROLLBACK を行なって下さい。
INSERT INTO films_user_comments VALUES 
    (_id_, 'GREAT! I was waiting for it for so long!');
COMMIT WORK;
   

削除操作を行なう際にプライマリキーテーブルの SHARE ROW EXCLUSIVE ロックを取得します。

BEGIN WORK;
LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE;
DELETE FROM films_user_comments WHERE id IN
    (SELECT id FROM films WHERE rating < 5);
DELETE FROM films WHERE rating < 5;
COMMIT WORK;
   

互換性