Berkeley DBの続き
ファイル→ページ→レコードという階層構造が存在する
- Mpoolと同様、ロックマネージャーも汎用コンポーネントとして作られた
- Mpoolの場合と同様、他のアプリケーションからもまったく違う方法でロックマネージャーを使えるという点が重要
ロックマネージャを理解する上で重要な概念
- ロッカー(誰がロックを獲得したのか)
- ロックオブジェクト(ロックされている項目)
- 衝突マトリクス(ちょっと何言ってるかわからないけど後述)
ロッカー
- ロッカーは32ビット符号なし整数
- Lockers are 32-bit unsigned integers. Berkeley DB divides this 32-bit name space into transactional and non-transactional lockers (although that distinction is transparent to the lock manager).
- この32ビットの名前空間(に)トランザクショナルなロッカーと非トランザクショナルなロッカーの二つに分割する
- オレオレルール
- 非トランザクショナル 長期間の読み込みロックの確保
ロックオブジェクト
- 任意な長さの不透明(opaque)なバイト文字列(何を隠しているのかよくわからない)
二つの異なるロッカーが特定のオブジェクトをロックしようとしたときは、どちらも同じバイト文字列でそのオブジェクトを表す。つまり、オブジェクトを不透明なバイト文字列で表すときの規約についてはアプリケーション側で決めておく必要がある
- ID ページ番号 型の構造体
ほとんどの場合、Berkeley DBで表す必要があるのはロックしたい特定のファイルやページだけ
opaque
インターフェース上で未定義のデータ型をopaque data type(不透明型)と呼び、そのような型を指すポインタをOpaqueポインタと呼びます Opaqueポインタについて - white wheelsのメモ
相互参照の問題を回避するために、Opaque型を利用する。中身がなんだかわからないけど定義されているもの
C言語とかC++とかでアレされているやつ
設計講座9
ページレベルのロックはアプリケーションの同時実行性を制限してしまう。ある制御スレッドがデータベースのレコードを変更すると、他のスレッドからは同じページにあるそれ以外のレコードを変更できなくなる。一方レコードレベルのロックなら、全く同じレコードを変更しようとしない限りはそんな制限を受けない。ページレベルのロックをすれば安定性が向上する
小規模な組み込みを想定している
衝突マトリクス
システム内に存在するさまざまな型のロックとその相互作用について定義 ロックを保持するエンティティを「ホルダー」、ロックを要求するエンティティを「リクエスター」
わかりづらいけど✓はNGを意味する
| リクエスター/ホルダー | No-Lock | Read | Write | Wait | iWrite | iRead | iRW | uRead | wasWrite |
|---|---|---|---|---|---|---|---|---|---|
| No-Lock | |||||||||
| Read | ✓ | ✓ | ✓ | ✓ | |||||
| Write | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| Wait | |||||||||
| iWrite | ✓ | ✓ | ✓ | ✓ | |||||
| iRead | ✓ | ✓ | |||||||
| iRW | ✓ | ✓ | ✓ | ✓ | |||||
| uRead | ✓ | ✓ | ✓ | ||||||
| iwasWrite | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
階層化ロックのサポート
階層化ロックとは、さまざまな項目を階層を保ったままロックすること
ページをロックしたらファイルもまるごとロックする
あるページをロックするということは、ファイルをロックするということでもあるからだ。あるページが変更されているとき、そのページを含むファイルを同時に変更することはできない
って書いてあるけど、ページをロックしたら自動的にファイルもロックするのか(インテンションロックも含んでいるのか)
iはインテンションの意
あるロッカーがコンテナに対するインテンションロックを獲得すると、そのコンテナの中身に対してもロックする意図があるということを表す iRead、iWrite、そしてiWRはすべてインテンションロックであり、それぞれ読み込み、書き込み、その両方に対する意図を指す
エンティティは要素、モノの意
ロックを結合するときには、ひとつのロックを保持するのは次のロックを獲得するまでの間となる。つまり、内部のBtreeページをロックするのは、次のレベルのページを選んでロックするための情報を読み込むまでの間である
設計講座10
汎用性重視の設計にしておいたことが、並列データ格納機能を追加するときに役立った
#
File←iwrite データ←write
より荒い粒度に対する要求なので許される
