レコードロック

レコード ロックは、データベース内のデータへの同時アクセスを防ぎ、矛盾した結果を防ぐ 手法です。

典型的な例として、2 人の銀行員が2 つの異なる取引について同じ銀行口座を更新しようとしています。銀行員 1 と銀行員 2 は両方とも口座の記録を取得 (つまりコピー)します。銀行員 1 は取引を適用して保存します。銀行員 2 は保存したコピーに別の取引を適用し、元の記録と変更に基づいて結果を保存します。銀行員 1 が入力した取引は上書きされます。最初の取引は記録に反映されなくなり、まるでその取引がまったく行われなかったかのようになります。

これを防ぐ簡単な方法は、レコードがいずれかのユーザーによって変更されるたびにファイルをロックし、他のユーザーがデータを保存できないようにすることです。これにより、レコードが誤って上書きされることが防止されますが、一度に処理できるレコードは 1 つだけになり、同時にレコードを編集する必要がある他のユーザーはロックアウトされます。

複数のユーザーが同時にデータベース テーブルを編集できるようにし、無制限のアクセスによって生じる不整合を防ぐために、編集または更新のために取得されるときに 1 つのレコードをロックすることができます。ロックのため、同じレコードを取得して編集しようとするユーザーは書き込みアクセスを拒否されます (ただし、実装によっては、編集せずにレコードを表示できる場合があります)。レコードが保存されるか、編集がキャンセルされると、ロックは解除されます。レコードは他の変更を上書きするように保存されることはなく、データの整合性が維持されます。

データベース管理理論では、ロックは複数のデータベース ユーザー間の分離を実装するために使用されます。これがACID の頭字語の「I」です。

ロックに関する徹底的かつ権威ある説明はジム・グレイによって書かれた。^[1]

銀行員が (上の図に従って) 2 人の顧客にサービスを提供しているが、顧客の口座が 1 つの元帳に含まれている場合、各顧客が 1 つずつトランザクションを完了できるように、元帳全体、または 1 つ以上のデータベース テーブルを銀行員が編集できるようにする必要があります (ファイル ロック)。この方法は安全ですが、不要な待機が発生する可能性があります。

店員が現在の顧客の口座（および他のいくつかの口座）を含む元帳から 1 ページを削除できる場合、各顧客の口座が他の口座とは異なるページにある限り、複数の顧客に同時にサービス提供できます。2 人の顧客の口座が同じページにある場合、一度にサービス提供できるのは 1 人だけです。これは、データベースの ページ レベルのロックに似ています。

個々のアカウントを店員が処理できる場合、より細分化された管理が可能になります。これにより、別のアカウントにアクセスしている別の顧客を待たずに、どの顧客にもサービスが提供されます。これはレコード レベルのロックに類似しており、通常、データベース管理システムにおけるロックの細分化の最高レベルです。

SQLデータベースでは、レコードは通常「行」と呼ばれます。

細分化された (サブセット) ロックを導入すると、デッドロックと呼ばれる状況が発生する可能性があります。デッドロックは、増分ロック(1 つのエンティティをロックしてから、1 つ以上の追加エンティティをロックする) が使用されている場合に発生します。たとえば、2 人の銀行顧客が 2 人の行員に口座情報を取得して他の口座に資金を振り替えるように依頼した場合、2 つの口座は基本的にロックされます。次に、顧客が行員に、資金を互いの口座に振り替える予定であると伝えると、行員は他の口座を検索しますが、それらは「使用中」であるため、返却されるのを待ちます。知らないうちに、2 人の行員は互いを待っており、一方が諦めて口座を返却するまで、どちらも取引を完了できません。このような問題を回避するために、さまざまな手法が使用されます。

レコード ロックは、レコードを要求するエンティティ間で管理される必要があります。これにより、連続した許可によってどのエンティティにも過剰なサービスが提供されず、他のエンティティが事実上ロックアウトされなくなります。ロックを要求するエンティティは、個々のアプリケーション (プログラム) またはプロセッサ全体のいずれかになります。

アプリケーションまたはシステムは、ロックが保持される時間が可能な限り短くなるように設計する必要があります。編集機能のないデータの読み取りではロックは必要なく、ロックされたレコードの読み取りは通常許可されます。

要求できるロックには主に 2 つの種類があります。

排他ロックは、通常、レコードへの書き込みを目的として、単一のエンティティによって排他的に保持されます。ロック スキーマがリストで表されている場合、ホルダー リストには1 つのエントリのみが含まれます。この種類のロックは、処理でロックを必要とする他のすべてのエンティティを事実上ブロックするため、次の点に注意する必要があります。

• ロックが保持される時間が可能な限り短くなるようにします。
• エンティティがプロセッサ上で実行されなくなったシステム呼び出しまたは関数呼び出しにわたってロックを保持しないでください。これによりデッドロックが発生する可能性があります。
• 何らかの理由でエンティティが予期せず終了した場合に、ロックが解放されることを確認します。

ロックを保持していないユーザー (待機者) は、ラウンドロビン方式で処理されるリスト、またはFIFOキューに保持できます。これにより、待機者になる可能性のあるすべてのユーザーがロックを取得する機会が平等に与えられ、ロックアウトされなくなります。プロセスをさらに高速化するために、エンティティがロックを待機してスリープ状態になった場合、何らかのシステム タイムアウトによるウェイクアップでロックを検出するのではなく、エンティティにロックの付与が通知されると、パフォーマンスが向上します。

共有ロックは、ホルダー リストに複数のエントリを含めることができるという点で排他ロックとは異なります。共有ロックを使用すると、すべてのホルダーがレコードの内容を読み取ることができますが、すべてのホルダーによってロックが解除されるまでレコードを変更することはできません。レコードが別のエンティティによって既にロック (排他的または共有) されている場合は、排他ロックを取得できません。

同じエンティティに対するロック要求がキューに入れられている場合、共有ロックが許可されると、キューに入れられている共有ロックも許可される可能性があります。キューの次に排他ロックが見つかった場合は、すべての共有ロックが解放されるまで待機する必要があります。排他ロックと同様に、これらの共有ロックは可能な限り短時間保持する必要があります。

• リーダー・ライターロック