poeaa ch5 2/4
Optimistic and Pessimistic Concurrency Control
- 並列制御
- 楽観ロック
- ロックしてねえじゃねえかってやつ
- 言葉として便利だし、広まってしまったからしゃーない
- ロックしてねえじゃねえかってやつ
- 悲観ロック
- ロックには2種類
- 共有ロック
- R
- 他の誰にも専有ロックさせない
- 専有ロック
- R/W
- 他の誰にも共有/専有ロックさせない
- 共有ロック
- ロックには2種類
- 楽観ロック
| Optimistic | Pessimistic | |
|---|---|---|
| liveness | o | x |
| conflictを... | 検出 | 予防 |
- コンフリクトがあまり起きず、起きたとしても重大にならないなら楽観ロックがよい
- liveness稼げる
- 実装らく
- コンフリクトが起きたが最後、マージが困難なら悲観ロック
- ビジネスロジックのデータとか
- いずれの解決策を選んでも、問題から真に開放されるわけではない
- 並列性の問題そのものと同じくらいの新たな問題
Preventing Inconsistent Reads
- 複数人で変更を加えて、それぞれはテストが通るが、合体すると壊れるやつ
- 1人がクラスA,もう1人が依存先クラスBをいじるようなケース
- 本質的にはinconsistent read
- 依存先クラスBの変更がチェックインされた時点で、クラスAをいじっている人から、変更後のクラスBが見えていない
- Pessimistic Lock
- read(shared) lock
- write(exclusive) lock
- 誰かがread lockをかけていると、誰もwrite lockできない
- 誰かがwrite lockをかけていると、誰もいかなる種類のlockもできない
- コンフリクトを未然に防ぐ
- Optimistic Lock
- データにバージョンマーカーを含める
- タイムスタンプ
- 連番
- コンフリクトを検出し、lost updateを防ぐ
- データにバージョンマーカーを含める
- inconsistent readをなくすには
- Optimistic Lockと同じことする
- データの全ビットにマーカーをつける
- 単に「読んでるだけ」で「使ってはいない」ファイルの仕分けが困難
- Temporal Reads
- タイムスタンプやimmutableなラベルをつけてデータを読み出す
- その時点でのデータを取得できる
- データソースは全バージョンを持たないといけない
- CVSなどでは良い
- DBではいささか高コスト
- Optimistic Lockと同じことする
