SaveChanges って嫌い
ってか、ChangeSet を元にする更新が嫌い。DataSetとかLINQ to SQLやEntity Framework とかとか
なんでかって言えば更新処理ってトランザクション処理の主作用だよね、何と何と何を更新して、なんか挿入してなんかを削除するってのは明示的にしたい。どこでどんな更新がかかったのか解らん物のChangeSet抽出して書き戻すとか信じらんないという自分。
昨今のフレームワークの殆どがChangeSet抽出からの書き戻しなんだけど、なんででしょ。自分は絶滅危惧種？
ChangeSet抽出から書き戻しの途中でエラーになったらどうするの？DBへの更新をロールバックするのは当然としてメモリ上にあるデータは書き戻せないからポイ以上の扱いってできないよね。
売れたから在庫減らす なら 「Update 在庫 set 在庫数=在庫数-販売数 where id=売れた物 and 在庫数>=販売数 」で更新行数が 1 ならOK、ChangeSet抽出なんてもんをベースにするから 「select 在庫数,タイムスタンプ from 在庫 where id=売れた物 」で取った物をメモリ上で色々なんか解らん操作されて求まった在庫数を 「update 在庫 set 在庫数=新在庫数 where id=売れた物 and タイムスタンプ=旧タイムスタンプ」なんて隙がありすぎるオペレーションになり、結果としてロック競合しました！残念でしたって結果になる。
楽観的同時実行制御は何が楽観かといえば競合はめったに起こらないって前提なわけで、それに基づいた処理ばっかりのフレームワークって、競合起こる前提の場合ってスコープ外だよね。eコマースサイトの99%の商品が前提としてそんなに売れないよでも、売上の主役となる商品が一個あってその一個の売り上げが命運を握ってるなら楽観的ロックなんて使っちゃだめなんだよね。
昨今の楽観的ロックまんせーなフレームワークオンパレードな状況に悲観的な今日この頃であります。
投稿日時 : 2009年11月27日 10:44
Tweet
コメントを追加