[Seasar-user:1806] Re: 暗黙的なトランザクション？ (was Re: PostgreSQL セッションの分断)

[加藤太朗]

小林さん、こんにちは。加藤です。

まず、日本語めちゃくちゃな乱文ですみませんでした。

> 私が興味を持ったのは，暗黙的なトランザクションと明示的な
> トランザクションを使い分けるというポリシーの方なので，
> そっちの話をさせてもらっています．
> # ついでに言うと，その使い分けの基準が「ロールバックする必要の有無」
> # というあたりは「をいをい」という感じなのですが，使い分けをしなければ
> # 基準の話は不要なので，ここは割愛．

私が示したポリシーなんてものはゴミなんで忘れてください。
変な話ふって済みませんでした。トランザクションを明示的に付ける設計は、
ぜんぜんその通りだと思ってます（というか元々そうしている）。

大胆なブラフ入ってましたが、seasar使う人全員が設計哲学まで持っているとは
限らないので、「私たちはdicon時代に生きている」と思っている人も少数でしょ
うし、別にseasarは設計思想団体ではないんでしょうから、多様な使われ方される
ことは想定範囲じゃないかなと。こんなケースでどう？という振りなんで、設計
論の議論ネタにするつもりはなかったんですが、やっぱ反応されちゃいますかね。
これじゃ。



私は設計の話ではなく、まだサービス層なんて分かれていない
s2daoの機能の試し彫りの時点で、出てきた問題が起点となっているので、
実はどっちでもよいんです。

暗黙的なトランザクションを無くすのは、その通りだと思いますし、
s2でいつでも差し込める、元の実装に左右されない世界の恩恵は
ものすごく感じています。

> つまり，DAO として S2Dao を使うという「実装の詳細」に
  :
(中略 m(_ _)m
  :
> 明確な理由を示せるのですから「謎なコーディング規約のノリ」ではなく，
> 「謎はない」いうことです．
立つ場所が変われば理由も変わりますから、理解しています。

> 繰り返しになりますが，S2JDBC では必要ないものが S2Dao で必要に
> なるという，見事なまでに実装に左右されまくりのポリシーが
> dicon 時代を生きる我らにはふさわしくない，というのが
> 私の言いたいことなのです．
えーと、どんな思想（く〜すでしたっけ？）をお持ちになられても、
自由だと思いますが「我ら」と私まで括るのはやめて。別に
「俺はdicon時代を生きている」なんて思ってもいないし。
返答しづらいのですが、小林さんのおっしゃっていることは分かります。

立つ場所変われば見方が変わる、スレッドが変わればスタンスは変わる、です。



余談ですが、私の感覚では、S2Daoって実装であって実装じゃないんですよ。
横断的関心の一部であり、存在を知らされていなくてよい裏方さんであり、
インフラ、空気みたいなものだと捉えています。
空気に異臭がまじっているのに、外(dicon)から脱臭剤を置くのが
DICON時代を生きる我らにふさわしいと聞こえてしまいます。
異臭の元を絶ったほうが、誤って脱臭剤を置き忘れても問題が起きません。
ましてや、異臭どころか気づきにくい一酸化炭素なので、置き忘れたら
死んでしまうことに問題があると言っています。
「置かなかった方が悪い」「仕様をすべて理解していなかったのが悪い」
「トランザクションを入れ忘れたのが悪い」というのはその通りでしょう。
で、ミスの防衛策は？それを「後の祭り」にすることで、誰が得して
誰が幸せになるのでしょうか？誰も幸せにならないと思います。


> 却下です．(^^; これはちょっとまずすぎでしょう．
> この場合，些細な実装の変更によって，それまで動いていたものが
> 動かなくなってしまいます．それは「危険要素」そのものです．
> そういう危険要素は残さない，つまり最初から動かない方が優れた
> フレームワークだという話ではなかったのでしょうか？
いえ、「危険要素と類推される文」はわざわざ定義して差し込んでおく
前提の、ただのフィルタ設定ですから動かなくなりませんよ。
なにも定義がなければ何も起きないので今まで通りという感じです。


> > むしろ sequence を使っている現在のS2Daoの実装が危険なので
> > （こちらは暗黙トランザクションの弊害）"identity"が効くように、
> > dbms.PostgresqlにBeanMetaDataをインジェクトできる
> > 別のインターフェースアダプタを実装する…というようなことを
> > S2Daoに独自に手を加えています。
> > ＃本当は標準で実装してほしいです。
> 
> 余計なお世話だと思いますが，踏み出す方向が違うために不必要な
> 手間暇がかかってるように見えます．
> # それが悪いとか間違っているとか言うつもりはありませんが，
> # 正直「なんか遠回りしてるなぁ」という印象を拭えません．
不必要ですか…。"identity"が効くDbmsなのに、Dbmsに依存する
シーケンス名を使わなければならないのは、どうだろうと思いません？
エンティティ全部変えなきゃならないんですが。
理想は、sqlファイルの末尾をDbmsごとに分ける以外は共通化できる
ことじゃなかったでしたっけ？

で、ちょっと試したらなぜか動かない…というのが発端だったんで。
この「ちょっと試す」の時点で、サービス層の分離なんてやってい
なかったために、こんな話題に発展しちゃったんですね。


話し変わりますが、JavaWorldの特集にもなって、これから益々
S2利用者が増えそうですね。すごいです。
まあ、くーすーの思想ちゃんと理解して賛同できないうちに、
使うとハマる前提な気がしますので、利用者が増えた方が良いのか
増えない方が良いのか微妙なところですが。

緻密に精度を高めなければならないポイント、割り切るポイントという
のはありますが、どう割り切っているか、どういう使い方をしなければ
ならないかが伝えられないと、利用者はハードル高く感じると思いますよ。
みんながみんな比嘉さんや小林さんのように賢いわけではないですし、
提供する側とされる側の溝は大きいですから。
…と言いながらも、伝えるということは必然的に伝える内容が増え、
ドキュメントが増え、習得期間も長くなる…ということになりそうですので、
やっぱり想定できる範囲で親切に問題を回避してあげるポイントを増やすのが
親切な姿かなと。

例えばあるライブラリを使ってNullPointerExceptionになる原因が、どっか別の
ところにある分厚いドキュメントの端に一文程度の説明があって、しかもそれが
関連づいているとは予想できない事柄だったりして、利用側の責任だと言われて
も全く嬉しくないのと同じです。"この機能は、コレとコレをこうしておく必要
があります"というポイントが指ししめされる例外が出れば効率がものすごく良
いですよね。
なので、みんな新しいフレームワークが出るごとに辟易しているんでしょう。
そのフレームワーク特有の新しい問題には何度となくはまって、習得することが
楽しいとは思えないからという理由もあるでしょう。
世の中のJavaプログラマみんながみんな新しいもの好きで研究好きなわけでは
ないですから。

ぜんぜん手軽に使えない、研究好きな人しか使わない、従来のフレームワーク
に対抗（とりあえずSpring？）するために、易しいものを…というスタンスに
とても同感しています。とても同感しているからこそ、仕事メチャクチャ
いそがしいのに、MLにかまけている（と社内メンバーにとられてもしょうがない）
ので。今よりもっと、より良く、誰が使うのも手軽で、ほぼハマルことが無い
ぐらいの優れたものになって欲しいと応援しているつもりです。

じゃなきゃS2関連のコードなんて、読まないし、改良しようとも思いせん。
というよりMLにフィードバックなんてしません。黙って勝手に改良したものを
使うだけです。
でも、そんな作業は小林さんから見れば「無駄」な手間なんでしょうけど。

言われてみれば無駄な手間隙ですね。個人的にはS2DAOが良くなる事に何の
メリットもありませんから。コミッタとは違うスタンスで応援したかったのですが、
MLへの発言の持っていき方に、どうも私は難がありますね。
今後、見直さなければならないと素直に思いました。
今まで申し訳なかったです。


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