今日、ちらっと排他の話が出てきた。
未だに疑問なので、前のblogで書いた記事をそのまま引用してみる。
3月26日
楽観排他を使うかは業務要件じゃね？
今日、隣の席で排他制御の話をしてたんで書いてみる。
色々呼び方はあると思うけど、ここでは「楽観排他」と「悲観排他」とする。
排他制御の掛け方は、業務によって異なると思う。
楽観排他、悲観排他が何かは、調べたら分かるし面倒なので書かない。
使い分ける例でよく出てきそうなのが、航空券の予約処理。
これは、悲観排他でないと相当使い勝手が悪いだろう。
（てかクレームが沢山きそうだ。。）
あれ「楽観排他を使うかは業務要件じゃね？」ってタイトルにしたけど、
楽観排他が望ましい業務要件ってどんな時だろう…。
思いつかないなぁ〜。
設計・実装・不具合発生度（コストや品質）の観点からなら、
楽観排他の方を選択するメリットがあるんだろうけど、業務要件的にメリットあるのかな？
・悲観排他でロックを掛けたまま異常終了した際に、ロックを解除するまで更新出来ないとか？
※異常終了時のロックの解除もキチンと設計・実装されているとしても若干はタイムラグが発生すると思う。
なんかあるのかなぁ〜。
少し調べてみると、
http://www.atmarkit.co.jp/fdotnet/entwebapp/entwebapp11/entwebapp11_03.html に楽観同時実行制御について載ってた。
これは、.NETエンタープライズWebアプリケーション開発技術大全〈Vol.5〉トランザクション設計編 (マイクロソフトコンサルティングサービステクニカルリファレンスシリーズ―Microsoft.net) の一部を紹介している記事なんだけど、
トランザクション量が多い業務の場合には業務排他制御機能が必要だが、重要マスタデータのメンテナンス業務のように、
といった特徴を持つ業務の場合には、次に述べる楽観同時実行制御（Optimistic Concurrency Control）を行うとよい。
「業務排他制御のような「完全な排他的制御」は不要。」っていうのは、完全な排他的制御でもいいんじゃないのかな？
なんで不要なんだろう？やっぱり実装コストや、異常終了時の問題なのかな？
ユーザー側からしたら、編集画面を開いた段階で更新出来ない事が通知された方が利便性は良いと思うんだけど。
※こんな事を書いてますが、悲観排他じゃなきゃ絶対ダメって思ってるわけじゃないです。ただ疑問に感じたから書いてるだけです。
実際、「全て悲観排他で作れ」って言われたら、
「運用でカバー出来ませんか」とか「コスト掛かりますよ」とか言って逃げようとすると思います。
