[seasar-dotnet:893] Re: VERSION_NOの扱いについて

kubo [E-MAIL ADDRESS DELETED]
2008年 7月 22日 (火) 22:36:27 JST


久保(jflute)です。

五十嵐さん、こんにちは

> 現状ではVERSION_NOをメモリ中でインクリメントし、UPDATE文を発行している
> と思いますが、VERSION_NOのインクリメントをUPDATE文の中で、
> 「VERSION_NO = VERSION_NO + 1」のように行えなえば回避可能です。

なるほど、上書き確認後に更新するという仕様なのですね。

VERSION_NOの「メモリ上インクリメント」と
「SQL上インクリメント」はちょうど悩んでいるところではありました。
(S2Daoは「メモリ上インクリメント」となります)

「SQL上インクリメント」の方が論理的にも頑丈なのですが、
やはり業務要件的にもこの方が良さそうですね。
http://dbflute.sandbox.seasar.org/download/dbflute/dbflute-0.7.7.zip
にて修正してみました。ご確認下さい。
(DBFluteの全てupdateが「VERSION_NO + 1」になります)

2008/7/22 五十嵐 大士 <[E-MAIL ADDRESS DELETED]>:
>
> お世話になります。五十嵐と申します。
>
> DBFlute-V0.7.6を利用して開発しております。
>
> レコードの排他制御をVERSION_NOで行おうとしております。
>
> UPDATE処理でVERSION_NO違いがあれば、
> 「他の端末からも変更がありました。上書きしますか?」
> のようなメッセージを出力し、YESであれば上書き処理を行う予定です。
> ※上書き処理はBehaviorのUpdateNonstrict()を利用
>
> AユーザとBユーザが同じタイミングで同じ画面を開くとき
> 1)Aユーザが更新するときにVERSION_NOは1から2に登録される。
> 2)Bユーザが更新するときに上書き確認のメッセージが表示され、
> OKしたときにVERSION_NOは2で登録される。
> 3)Aユーザが再度更新するときにVERSION_NOは2から3に登録するため、
> 上書き確認のメッセージが表示されない。
>
> と言う現象が起こります。
>
> 現状ではVERSION_NOをメモリ中でインクリメントし、UPDATE文を発行している
> と思いますが、VERSION_NOのインクリメントをUPDATE文の中で、
> 「VERSION_NO = VERSION_NO + 1」のように行えなえば回避可能です。
>
> ご検討よろしくお願いいたします。
>
> 以上です。
>
> --
> 株式会社ビルドシステム
> 五十嵐大士 <[E-MAIL ADDRESS DELETED]>
>
> _______________________________________________
> seasar-dotnet mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>


seasar-dotnet メーリングリストの案内