楽観的ロック

database

時刻印アルゴリズム - サイエンスかリアルか
エロくないけど勝手に回答してみる。
JoJo好きだと、第5部のvsボス戦でのポルナレフ戦法に似ているというと判りやすいかも？w

  1. SELECTする。
  2. SELECTしたデータを編集する。
  3. 再度SELECTする。
  4. 1と3とでバージョンID or タイムスタンプが異なっていたら、更新内容を破棄。

3と4はUPDATE時に一括で行う。0行更新ならエラーにするとかで。
(e.g. UPDATE foo set ... , foo_version = foo_version + 1 WHERE foo_id = ? AND foo_version = ?)

タイムスタンプは、分散環境などで被らないとも限らないので、バージョンIDを使うほうがより良いようです。

また、バージョンの不一致が発生するとそれまでの作業が全て無駄になるので、更新が多いテーブルには悲観的ロック（通常のロック）を使用するのが一般的です。

詳しくは"エンタープライズ アプリケーションアーキテクチャパターン(ISBN:9784798105536)"の軽オフラインロックを参照。

しかし、S2DaoやRailsみたいに自動バージョン管理してくれるフレームワークが増えると、この辺も目立たない技術になって行きそうですね。