ロックのいろいろ
最終更新：
yutoritaro 2009年11月25日(水) 10:50:16
この項目ではDBMSやアプリケーション開発における排他実装としてのロックについて記述しています。
ロックンロール・ミュージック、及び、その他さまざまなロックについてはウィキペのロック(曖昧さ回避)を参照のこと
以下は実装上の都合で発生する論理的な意味はないロック
ロックンロール・ミュージック、及び、その他さまざまなロックについてはウィキペのロック(曖昧さ回避)を参照のこと
アプリ側(に限らず広く一般？)
共有ロック
- 参照モードのロックのこと(?)、共有ロック同士は共存できる。
排他ロック
- いわゆる更新ロックのこと、排他ロック同士は共存できない。
- 排他ロック時に参照のみのデータへのアクセスができるかはDBMS(やオプション設定)による。
- （参考）マルチバージョニング：他トランザクションによって排他ロックがかけられたレコードへの参照時には、更新前情報を返し同時実行性を維持する手法(ゆとり世代には当然のことでも現実にはそうでもない)
デッドロック
以下はウィキペからのコピペ
デッドロック(Dead lock)とは排他制御の欠陥で、2つ以上のスレッドあるいはプロセスなどの処理単位が互いの処理終了を待ち、結果としてプログラムが停止してしまうことを言う。 英語では行き詰まりの意味がある（日本語でDead lockをDead rockと間違え、「暗礁に乗り上げる」ことを「デッドロックに乗り上げる」ということがあるが、これは誤用）。
デッドロック(Dead lock)とは排他制御の欠陥で、2つ以上のスレッドあるいはプロセスなどの処理単位が互いの処理終了を待ち、結果としてプログラムが停止してしまうことを言う。 英語では行き詰まりの意味がある（日本語でDead lockをDead rockと間違え、「暗礁に乗り上げる」ことを「デッドロックに乗り上げる」ということがあるが、これは誤用）。
楽観ロックと悲観ロック
- 更新アプリケーションでの排他処理の実装手法
- 悲観ロック： 更新処理の開始時点から更新予定のデータに排他制御を掛け、排他が成功した場合に更新準備〜実際の更新を行う手法。シンプルではあるが、過剰防衛的な措置となり同時実行性に悪影響がでるリスクとのトレードオフがある。
- 楽観ロック： 更新処理の開始時には排他ロックを取得せず、更新準備ができて実際のデータ更新時に対象データのタイムスタンプやバージョンNoを取得し、開始時点との比較により競合の有無を判断する手法(Non-repeatable readsの発生を検出)。競合が発生した場合には更新準備が無駄になるが、そもそもあまり競合は起きないだろう楽観的見通しが可能な場合に有効(むしろ主流かも[要出典])。とはいえ、複数のデータを整合性をもって更新したい場合には、実際の更新処理の直前には排他ロックは必要なので、よくいわれる[要出典]「排他ロックをしない」は厳密ではなく、排他ロック時間の極小化というべき。
DBMS側の事情
SQL標準なロック
行ロック
- 行(レコード)単位でのロック、意味的な最小単位
表ロック
- 表(テーブル単位)のロック。バッチ処理でファントムに敏感なとき等限られた状況でしかアプリケーションで用いることはない。
- 但し実は行ロックを取得すると、更新を保障する都合上、表定義の変更を阻止する為に暗黙の共有ロックを取得している。
以下は実装上の都合で発生する論理的な意味はないロック
ページロック
- 一般にDBMSでは、データをあるまとまったかたまり(以下「ページ」と表記、Oracleならブロック)ごとに物理的に管理している。通常、このページには複数レコードが格納される(１レコードのサイズが大きい場合は複数ページにまたがる等実際にはいろいろあり得る)。物理実装を簡素にする為にこのページ単位でロック処理を行うことをページロックという。
- DBMSから物理データへのアクセスの都合からくるものであり、ページに論理的な意味はない。
- かつてはページロックに頼らず完全行レベルロックの実装はDBMSでの売り文句だったが、今では主だったDBMSではそれが当たり前でページロックは過去の遺物となっている(主なDBMSの実態参照、M$Accessでは健在？[要出典])
- この影響を嫌ってレコード長をページサイズの整数倍になるように調整する物理DB設計をした時代もあるとか[要出典]
ロックエスカレーション
- 大量行のロックが発生した場合に表ロック(or中間的にページロックになる場合もあるらしい)に移行することで、ロックを管理する為のDBMSの負担を軽くする措置が実装されていることがある。これをロックエスカレーションと呼ぶ。
- DBMSの実装上の都合によるもので、思わぬロック待機時間の増加やデッドロックの原因ともなる(ゆとり世代には怖いシロモノです)。
- ロックエスカレーションの発生閾値はDBインスタンスのパラメーターとして調整できる(場合もある)。
索引(Index)の巻き添えロック
- 普通の索引は木構造をとり、最終的には実レコードに対応する物理単位を括り出すことができる
- 実はページロックの実装が索引巻き添え型もあるらしい[要出典]
- しかし、検索性能の為に特殊な索引を使用した場合、その性質上索引キーへの更新が発生した場合に巻き添えのロックが発生する
- 例: ビットマップ索引(筆者註：他の例は知りません、悪しからず)
最新コメント