[Seasar-user:1782] Re: PostgreSQL セッションの分断

[加藤太朗]

中村さん、こんにちは。レスありがとうございます。
長文になりました。ご容赦ください。


> で、S2Dao の場合、基本的にトランザクション中でなければ
> 一回のアクセスごとに Statement オブジェクトを生成するので
> currvalは見えません。
やはりステートメントでしたか。


> 個人的には、トランザクション外で currval を見たいという状況が想像できて
> いないので現状で困っていないのですが、必要な状況なのでしょうか？

ううん、currvalが欲しいというより、
「今追加したレコードをそのまま使いたい」という機能上の要求ですね。
そこで引き当てる以外に取得する方法がありませんので。SERIALですから。

> insert時はPostgres側がアトミックにnextvalを呼ぶので問題にならないかと思います。
nextvalされるのは分かります。それで今、正に追加したそのレコードはどうやっ
て引き当てます？他にユニークなものがなければアウトですよね？

IDアノテーションなら、selectで持ってきたのと変わらない姿に
自動的に変身しているので、めちゃくちゃスマートでカッコイイと思いました。
   
   dao.insert(bean);

これだけでbeanに主キー返してくれるなんて素晴らしいです。

IDアノテーションを知る前は自前でSQLに含めていましたので、
「ダサいなぁ、もろSQLServerしか動かないよ…orz」
…というSQL書いてましたので（_mssqlや_pgsqlで分けろって声が聞こえそうで
すがスマン、メンドい。）
Dbmsごとに切り分けているs2daoのコード見た時は、感動しました。
親指上に立ててグーって言いましたよ。グーって。

insert であろうと update であろうと更新画面があって、
その実行後のページが同一の表示画面に遷移するというような
ケースで、エンティティビーンが既存レコードであることが
保障されるのはとても後処理がシンプルになって良いですよ。


いつもトランザクションが必要というのはどうかなと思います。
トランザクションが必要なケースとそうでないケースで分けることに
していますので。「このケースはロールバックが不要かそうでないか」
ということがdicon見てひと目で分かるように…というようなポリシーですが、
「理解していて使う人」にとっては全然困らないわけですから、
私も個人的には困っていませんよ。

でもそれが個人ではなくチームに、伝承しなければならないほどの
ことかなぁ…と。
今回の問題が残る限り私はチームメンバーに
「ここだけはやばいから気をつけろ！」とクチすっぱく徹底しなければ
ならないわけです。潜在バグを生むわけには行かないですからね。

そして「s2daoつかうコードはトランザクションインターセプトで括れ」
をやみくもに徹底することになると思います。謎なコーディング規約の
ノリで。

繰り返しになりますが、危険要素を残しておくというのは優れた
フレームワークだとは思えないです。

開発者にとって必要な前提知識を軽減できることが、易しさだと
思います。これがJVMの実装やsunのクローズドソースの中だったら
仕方ないと思いますが、同一プロジェクトの生産物である、
s2またはs2daoの実装がステートメント単位だからというのは、
IDアノテーションを頑強にできない理由にならないと思います。

以上が私の意見です。


--------------------------------------------------------->>
Gluegent,Inc. T.Kato
http://package.gluegent.com/~kato/signature.xml
---->> generate products and services with high added value