[seasar-s2dao-dev:108] Re: VersionNo やTimestampの値がnullだった場合の仕様について

[kubo]

久保です。

> >   Entityに排他制御のAnnotationを付けたからには、
> >   VersionNo/Timestampの値を設定しない限り更新をできないようにする。
> >     →排他制御の強制
> > 
> 排他制御の強制と言うつもりはないです。
> SQLファイルで排他制御をする場合もあると思っているので。
> 現状だと、SYSDATEなどDBMSのファンクションをupdate句に
> 含めたいような場合です。

そうでしたか。ありがとうございます。


自分が気になったのは、

例えば夜間バッチ処理などで、排他制御が不要なProcessの場合に
一体どのように実装するのがS2Daoの作法になるのかを迷った次第です。

（SQLファイルを利用した場合を除いて）
現状VersionNoアノテーションを付けると、必ず排他制御が動作します。
なので、update()の引数のEntityには必ずVersionNoを付与しなければ
なりません。
(画面とBatchで別のEntityを生成するのは必ずしも×ではないですが、
 できれば再利用したいと考えます)


S2Dao-1.0.39までは、update()はUpdate文のSet句にEntityに定義されている
全てのColumnが指定されてしまうため、排他制御の有無に関わらず、
「一旦Selectして取得したEntityに更新値を反映させてUpdate」
をやるのが流儀だったと思います。

S2Dao-1.0.40では、updateModifiedOnly()がサポートされるため、
例えば「会員のステータスコードだけを更新する」というような
処理の場合に、以下のように書くことが可能です。

UserAccount entity = new UserAccount();
entity.setUserStatusCode("aaa");
dao.updateModifiedOnly(entity);

つまり、「一旦Select」をしなくても更新することが可能です。
(updateメソッドの戻り値をvoidにすることで0件更新のCheckは可能)

ですが、排他制御が不要なProcessの場合でも、UserAccountに
VersionNoアノテーションが付いていると、どうしてもVersionNoを
一旦Selectして、引数のEntityにSetしなければなりません。
すると、あんまり以前と変わらないことになります。
できれば、Batch処理などにおいてはPerformanceのためにも
不要なSelectは排除したいと考えます。

今までは、Update文のSet句問題のためにどのみち「一旦Select」は
必要だったのであまり気にしていませんでしたが、updateModifiedOnly()
がサポートされたことにより(updateUnlessNull()も同様ですね)、
「排他制御する・しない」をProcessが決定できる必要があるのでは
ないかと思いました。画面Processでも不要な場合があると思いますし...
(SQLファイルを使えばどうにでもなりますが、
「排他制御しない場合は外だしSQLでupdate書いてね」
 というPolicyもちょっと微妙だと考えました)

なので

提案です。


＜A＞
updateWithoutConcurency(Entity entity);
  → 排他制御無し
  (但しVersionNoのインクリメントはする。つまりWhere句付与をしない)
 

＜B＞
引数のEntityのVersionNoがnullだったら
  → 排他制御無し
  (但しVersionNoのインクリメントはする。つまりWhere句付与をしない)

＜C＞
@WithoutConcurency();
update(Entity entity);
  → 排他制御無し
  (但しVersionNoのインクリメントはする。つまりWhere句付与をしない)


「A」について
updateUnlessNullとかupdateModifiedOnlyとかに習って。
実現コストはそんなに高くないです。既に久保の頭の中で修正イメージは
あります。

「B」について
実現コストが一番低いですが、「排他制御の強制」が無くなってしまいます。
ただ、現状「一旦SelectしてUpdate」してると、
実質的に排他制御の強制って無いのに等しいです。
  →SelectしたてのDBの値を格納すれば99%等値になるので。

「C」について
「A」だとupdateModifiedOnlyWithoutConcurency()という
長いメソッドになってしまうので、アノテーションでどうかと。
但し、実現の手間からいうと「A」よりも重いかも。
（アノテーション追加なので）
しかも、それならUnlessNullとかModifiedOnlyとかもアノテーションで
よかったんじゃと思ってしまうかも...


個人的には「A」が一番現実的で軽めの対応で済むかと思っていますが、
どうでしょうか？


他のスレッドで話題に挙がっている機能とかに比べれば、
優先度はぜんぜん低いのですが、検討すべき項目であると考え
提案させて頂きます。


もし、よろしければ久保が修正担当します。



-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
kubo   <jazzflute ＠ mbn.nifty.com>
jflute <http://d.hatena.ne.jp/jflute>
株式会社ビルドシステム <http://www.buildsystem.co.jp>
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/