楽観的ロック とは？

テーブルに「version」カラムを追加する。データを読むときにversionも取得して、更新時に「UPDATE ... SET version = version + 1 WHERE id = 1 AND version = 3」のようにWHERE句にversionを入れる。誰かが先に更新してversionが4になっていたら、WHERE条件にマッチせず更新件数が0件になる。これで衝突を検出するんだ。

楽観的ロックは「衝突はめったに起きない」場面向け。例えばブログ記事の編集やユーザープロフィールの更新。悲観的ロックは「衝突が頻繁に起きる」場面向けで、在庫の減算やチケットの予約に使う。楽観的ロックは待ち時間がないぶん高スループットだけど、衝突が多い場面ではリトライだらけになって逆に遅くなる。

多くのORMがサポートしている。Railsなら「lock_version」カラムを追加するだけで自動的に楽観的ロックが有効になる。JPAなら@Versionアノテーションを付ける。衝突時はStaleObjectError的な例外が投げられるから、それをcatchしてリトライや「他の人が更新しました」というメッセージを出す処理を書く。

ABA問題というのがある。値がA→B→Aと変わった場合、バージョンチェックだけだと「変わっていない」と判断してしまう可能性がある。バージョン番号をインクリメントする方式なら避けられるけど、タイムスタンプ方式だと同一ミリ秒内の更新で問題が起きることがある。あと、楽観的ロックはあくまで「1つのテーブルの1行」の競合しか検出できないから、複数テーブルにまたがる整合性は別途トランザクションで担保する必要がある。この組み合わせの設計が結構ややこしいんだよね。