勉強日記

チラ裏

PoEAA ch16 Implicit Lock

PoEAA 勉強メモ デザインパターン

martinfowler.com

Implicit Lock

Allows framework or layer supertype code to acquire offline locks.

  • Offline Lockは、1行忘れただけで全部台無しになる
    • read lockの取得が漏れると、最新のセッションデータを取得できている保証はない
    • バージョンを適切に使わないと、他人の変更を上書いてしまう
    • どこでもロックされうるものは、全ての場所でロックしなければならない
    • アプリケーションのロック戦略に従わないとデータ整合性を失う
    • ロックを解放し忘れると、レコードデータが駄目になることはないが、アプリケーションはやがて止まってしまう
      • 【補】そのうちロックを獲得できなくなる
  • 開発者が明示的に書くと見落としが発生する
    • しかもテストが難しい
  • そこで、アプリケーション側で暗黙裡に行うようにする

How It Works

  • ロック機構を、絶対にスキップされないようにする
  • ここにおいて「フレームワーク」とは
  • コード生成という別の道も
  • 実装する上では、まずビジネストランザクションで必要なタスクをリストアップする
    • Optimistic Offline Lock
      • 各レコードでバージョンカウントする
      • 更新SQLにバージョンチェック・インクリメントを含める
    • Pessimistic Offline Lock
      • RDBMSのロックの獲得・解放
        • exclusive read lock、read/write lockのread portion
  • exclusive write lock、read/write lockのwrite portionを暗黙裡に獲得するのは困難
    • いつ獲得すべきか、フレームワークは判断できない
      • ビジネストランザクション開始後すぐに獲得を試みて、獲得できなければabortするのが適しているかもしれない
      • そうでないかもしれない
    • この種のロックはシステムの並列性を著しく損なう
      • Pessimistic Offline Lockを避けるという選択肢
        • 単に技術的な問題ではなく、ドメインに跳ねる話になる
          • 【補】衝突可能性はどれくらいか？
          • 【補】衝突時はabortするのかmerge/retryするのか？
  • 変更をcommitする前に確実にwrite lockを獲得すること
    • フレームワークで、assertion failureもしくは例外送出で保証
      • 本番環境では無効化する
        • 開発の誤りを見つけるためのものであって、本番環境でエラーを出したいわけではないため
  • Implicit Lockは万能ではない
    • 開発者は、ロックの獲得・解放を意識する必要はなくなる
    • が、ロックの獲得の結果 -- デッドロックの可能性等は意識しなければならない
    • 開発者がロックのことを気にしなくなった結果、ビジネストランザクションが思いもよらぬ形で失敗したりする

When to Use It

  • フレームワークを使っていないシンプルなアプリケーションでもない限り使うべき
    • ロック周りは「忘れる」リスクが甚大

英語

  • ground-breaking
    • 画期的な