PoEAA ch16 Pessimistic Offline Lock
Pessimistic Offline Lock
Prevents conflicts between concurrent business transactions by allowing only one business transaction at a time to access data.
- ビジネストランザクションは複数のシステムトランザクションにわたる
- まずはOptimistic Offline Lockを検討せよ
- Optimisitic Offline Lockの問題点: 変更が衝突しうる
- 変更を捨てる「犠牲者」が出るということ
- 長いビジネストランザクションの最後に失敗して、作業が無駄になる
- ほどなくそのシステムは使われなくなる
- 上記が問題となる場合、Pessimistic Offline Lockを検討する
- 衝突を予防する
- ビジネストランザクションで必要なロックを、あらかじめすべて獲得する
- 「不渡り」になることがない
- 衝突を予防する
How It Works
- Pessimistic Offline Lockの実装は3段階
- ロックの種類を決める
- ロックマネージャを実装する
- ロックの利用の流れを定義する
- ロックの種類
- readerセッションが複数あるのはOK
- read lockを誰かが取得したら誰も変更できないため
- 並列度を上げるのに寄与
- ロックの種類の理解の重要性
- ロックマネージャの実装
- ロックの利用の流れの定義
- "protocol"
- 何をロックする
- いつロックする
- いつ解放する
- ロックを獲得できなかったときどうする
- "protocol"
- いつロックする
- 何をロックする
- PK
- いつ解放する
- 最も単純なのは、ビジネストランザクション完了時
- 基本的にはこれを守る
- パフォチューのためにやむなく早期解放したりもする
- 最も単純なのは、ビジネストランザクション完了時
- 獲得できなかったらどうする
- abort
- 「ロックと所有者との対応表」へのアクセスは直列でなければならない
- デッドロック
- タイムアウトの考慮
- ロックが解放されないままになるケース
- クライアントマシンのクラッシュ
- セッション放棄
- Webアプリケーションではよくあること
- アプリケーション側でタイムアウト制御を行うのではなく、アプリケーションサーバーで管理せよ
- HTTPセッションがinvalidになったらロックを解放する
- 別解: ロックにタイムスタンプを紐付けて、特定のageになったら解放する
- ロックが解放されないままになるケース
When to Use It
- 変更の衝突可能性が高いとき
- 変更の衝突可能性が低くても、衝突時のコストが甚大なとき
- Optimistic Offline Lockと相補的
- 基本的にはOptimistic Offline Lockを使う
- 本当に必要なときにのみPessimistic Offline Lockを使う
- 単一のシステムトランザクションでビジネストランザクションを包むという選択肢
- 決してよいものではない
- が、条件によっては、Pessimistic Offline Lockと同程度の並列性に収まることがある
- 実装はかなり簡単
- 短い単一のシステムトランザクションに収まるなら、そうせよ
- Offline Lock系パターンは使うな
- RDBのロックの種類を知るとPessimistic Offline Lockの実装のためになる
- 逆は成り立たない
英語
- bounced
- bounced check: 不渡り小切手
- at the onset of
- 〜のはじめに