楽観的ロックとは

今時は、Webの求人広告もWeb上の管理画面で原稿の確認・修正が

できるようになっています。

だいぶ前の話なのですが、
複数のメンバーで求人広告の確認作業と修正を行ったことがあります。
そのとき、修正した内容が元に戻る現象が発生しました。

おそらくは、こんな操作だったと思います。

　1) Ａさんがページを開く

　2) Ｂさんがページを開く

　3) Ａさんがある個所（たとえば電話番号）を修正して保存。

　4) Ｂさんが別の個所（たとえばファックス番号）を修正して保存

　　　すると、この地点でＢさんが保存したデータの電話番号は、
　　　Ａさんが修正を行う前の状態なので、
　　　Ａさんの電話番号の修正が元に戻ってしまう。

いわゆる"後勝ち"の方式ですね。
絶対的におかしいとまでは言いませんが、使いにくいですよね。

では、システムとしてはどうすればよいか。。。

答えは簡単。

保存するときに、ページを開いたときから更新されているか
チェックすればよいのです。

まず保存するデータ構造に更新日時か更新番号を用意して、
ページを開くときにこれを読み込みます。

そして、ユーザーが書き込み操作を行ったら、
もう一度このデータを読み込んで更新されていないか
（つまり他の誰かが更新していないか）をチェックします。

並行して処理が実行されないように、この読み込み処理は
明示的なロックを伴って実装します。
(SQLを書くときにSELECT FOR UPDATEを使います。)
そして、最後にデータを更新してロックを解除すればOKです。

実はこの方式は楽観的ロックと呼び、一般的な手法です。
書き込む直前まで他の誰も書き込まないことを期待する手法なので
"楽観的"と呼ぶのです。

ちなみに同じデータを２人の人が更新しないように、
ページを開く段階からロックすることを悲観的ロックと呼びます。

この２種類のロック、システムの実態に応じて使い分けるべきものですが、
通常、Webシステムではクライアントがブラウザを閉じたことをサーバーが
察知できないので、楽観的ロックで問題が発生しないように画面構成を

設計することが一般的です。

上記のとおり、実装は比較的簡単です。

実装されていないケースをよく見かけるのは少々残念。

やっぱり、細かいところまで気の利いたシステムがいいですよね。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -