これは誤解を招く書き方かな

http://d.hatena.ne.jp/bufferings/20091124/1258983997

トランザクションのところにある楽観的ロックという項目。

ここで例に出ているのはバージョン管理によるアプリケーション制御であって、データベースのトランザクション管理における楽観的ロックのお話ではない。

したがって同様の画面制御をする場合悲観的ロックを利用していてもバージョン番号を振る必要が出る。Webアプリかそうでないかということも関係ない。

データベースのトランザクションの楽観的ロックということならば上書きにするかどうかというアプリケーションレベルの話ではなくて、実際にトランザクションを開始する直前にバージョン番号を取得して開始するというもの。

したがってここはデータベースのトランザクションの話をしていないのに、そうだと勘違いしてしまう人も出てくると思う。

データベースで難しいのが、バージョンカラムを利用したアプリケーション制御（つまりこの話は悲観的とっくも楽観的ロックも同じ）でそれがバージョンが違っていた場合、本当にユーザーの対話を求める画面であるか、それとも日報のように上書き（というか追加系）の処理でよいのか、それによってバージョン番号を使って判断するときとしないときがあること。つまり、DAO等を用意するとき上書きでよいのかユーザーに対話を求めるのか使用するトランザクションが2種類必要ということ（もしくは引数に書いて中で判断させる必要あり）。

また、バージョン番号が異なっていたのでユーザーに対話を求めるアプリケーションであっても、他人が入力したのでこの今までがんばって入力した項目が消えてしまうのか、それとも差分表示させるのか、上書きでいいのかなどの判断がさらに難しい。今まで入力していたのが消えてしまうというのはキーボード操作が不得意な人にとって非常に厳しい可能性がある。

詳細表示であっても入力画面と参照専用画面をわけて権限を設定する等によってそれなりに改善されるのだが、分けないシステムも意外と多いようだ。分けたからといって完全に防げるわけではないしね。

このへんはAPIレベルのお話ではなくて設計の問題なのでセンスが問われる部分だと思うが、意外と適当になっている場合も多い。ユーザー数が少ないうちは問題にならなくて、ユーザーが増えてからあとであわてるということがあったりなかったり。

Webアプリの厄介な点としてユーザーがいつの間にか増えていた、増えることに無頓着になりやすいというところだと思う。クライアントサーバーだと専用にセットアップ等が必要でわりと把握しやすかったのだが、Webアプリではそうはいかないことも。