【らっかんてきろっく】
楽観的ロック とは？
最終更新:
💡 「たぶん衝突しないだろう」と楽観的に構えて、更新時に競合チェックする方式
編集の間に他の利用者がデータを変える可能性を認め、保存時に読み取った版との一致を確認する方式。バージョン番号などの照合と更新を一つの操作で行い、不一致なら古いデータによる上書きを拒否する。
📌 このページのポイント
- 編集の間は他の更新を排除せず、保存時に変更の有無を確認する
- 読み取ったバージョンを条件にして、データと版を一緒に更新する
- 競合が少ない場面に向くが、更新処理の待機がなくなるわけではない
- 競合時は最新データを読み直し、再編集や統合・通知の方針を決める
ひよこ 楽観的ロックって具体的にどうやるの？
ペンギン先生 version=3のデータを読んだら、保存時にその版を条件にするよ。SQLなら「UPDATE ... SET 内容=新しい内容, version=version+1 WHERE id=1 AND version=3」のように、確認と更新を同じ文で行う。対象行が存在しても版が4なら更新されないので、更新件数などで競合を確認するんだ。
ひよこ 先に版を調べて、その後に保存すればいい？
ペンギン先生 確認と更新を別々にすると、その間に誰かが更新する可能性があるよ。だから版が一致する場合だけ更新する操作にするんだ。更新する経路が版の確認や更新を省いてしまうと、この仕組みで変更を検出できないことがあるよ。
ひよこ 悲観的ロックとはどう違うの？
ペンギン先生 ひよこ ORMなら自動で使えるの？
ペンギン先生 対応するORMで設定すると利用できるよ。RailsのActive Recordなら、通常はlock_versionの整数列で版を管理し、競合時にStaleObjectErrorを出す。画面をまたぐ編集では読み取った版も保存要求に渡す必要があるので、列を足すだけでどんな操作も守れると考えないようにね。
ひよこ 競合したら同じ内容でリトライすればいい？
まとめ：ざっくりこれだけ覚えればOK！
「楽観的ロック」って出てきたら「保存時に版を確かめ、古い内容で上書きしない工夫」と思えばだいたいOK！
📖 おまけ：英語の意味
「Optimistic Locking」 ＝ 楽観的な（Optimistic）ロック（Locking）
💬 「衝突は起きないだろう」と楽観的に考え、実際に衝突したときだけ対処する方式