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

Koichi Kobayashi koichik
2005年 4月 14日 (木) 02:36:40 JST


小林 (koichik) です.

On Wed, 13 Apr 2005 12:08:58 +0900
加藤太朗 <[E-MAIL ADDRESS DELETED]> wrote:

> 私が脱線したところが起因しているのですが、まず話を戻させてください。

そんな,戻さなくても.(^^;
別々の話として,それぞれのスレッドを延ばしていけばよいかと思いますが?
もちろん,興味のある人がいれば,ですけどね.
そんなわけで (どんなわけで?),サブジェクト変えます.
# 最初から変えるべきでした.m(__)m

S2Dao の件に関しては,私は現状のままで構わないと思っていますが,
加藤さんの要望が受け入れられるのを阻止したいというわけでも
ないので,特にその議論に参加しようとは思っていません.
それについては加藤さんとひがさん他で議論して頂ければと思います.

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


> そういう意味では、Daoに依存しているわけではなく、S2Daoに
> 依存してしまっています。
> 「回避コード」としてトランザクションを採用することに
> なっているところに問題があることを言っています。

つまり,DAO として S2Dao を使うという「実装の詳細」に
強く依存するわけですよね?
それを加藤さんは S2Dao の問題と考えておられるようですが,
私はそうではなく,その程度の差異に簡単に影響を受けてしまう,
加藤さんの示したポリシーこそが問題なのだと考えます.

前のメールでは私の言いたかったことがうまく伝わらなかった
方もいらっしゃったので,私の主張を簡単に要約しておくと,

[前提]
・トランザクション境界はサービスのインタフェースを決定する
  時点で決まっている.
・明示的なトランザクションを使用する.
[結論]
・サービスの実装には最初からトランザクションインターセプタを
  適用する.

ということになります.DAO をどうするかには左右されません.
『「回避コード」としてトランザクションを採用』するなんて事態にも
なりません.最初から明示的にトランザクションインターセプタを
使うのですから.

> > > そして「s2daoつかうコードはトランザクションインターセプトで括れ」
> > > をやみくもに徹底することになると思います。謎なコーディング規約の
> > > ノリで。
> > 
> > S2Dao を使うかどうかは関係ありません.トランザクション境界の設定は
> > サービス層のインタフェースに対して決定すべきものです.謎はありません.
> 
> 焦点がずれています。サービス層のインタフェースに対して決定するのは
> 当然です。前述していますが、s2jdbcでは必要ないのに、s2daoを使うことで
> 「ステートメント単位の連携にトランザクションを使用する謎」のことなんです
> が。

私の主張は,S2Dao を使うかどうかにかかわらずトランザクション境界は
明示的にインターセプタで括れということであり,それには「サービスや
DAO の実装に依存しないため」という明確な理由があります.
明確な理由を示せるのですから「謎なコーディング規約のノリ」ではなく,
「謎はない」いうことです.

繰り返しになりますが,S2JDBC では必要ないものが S2Dao で必要に
なるという,見事なまでに実装に左右されまくりのポリシーが
dicon 時代を生きる我らにはふさわしくない,というのが
私の言いたいことなのです.

# S2JDBC と S2Dao の差異が妥当かそうでないかはここでは不問.
# 今問題になっている差異が妥当でなかったとしても,ある程度の
# 差異があるのは想定の範囲 (笑)

> 仕込むとしたら多分、S2DBCPレベルではなく、危険要素と類推される文が要求さ
> れた時点でカウントし、2つ目の文以降が要求されたら、例外を出す…というぐらい
> 木目細かであれば、本気で考えても良いと思います。

却下です.(^^; これはちょっとまずすぎでしょう.
この場合,些細な実装の変更によって,それまで動いていたものが
動かなくなってしまいます.それは「危険要素」そのものです.
そういう危険要素は残さない,つまり最初から動かない方が優れた
フレームワークだという話ではなかったのでしょうか?


以下は蛇足ですが.

> むしろ sequence を使っている現在のS2Daoの実装が危険なので
> (こちらは暗黙トランザクションの弊害)"identity"が効くように、
> dbms.PostgresqlにBeanMetaDataをインジェクトできる
> 別のインターフェースアダプタを実装する…というようなことを
> S2Daoに独自に手を加えています。
> #本当は標準で実装してほしいです。

余計なお世話だと思いますが,踏み出す方向が違うために不必要な
手間暇がかかってるように見えます.
# それが悪いとか間違っているとか言うつもりはありませんが,
# 正直「なんか遠回りしてるなぁ」という印象を拭えません.

# 当然ですが,私はこっちも S2Dao で対応して欲しいとは思いません.
# S2Dao での対応を阻止したいというほどでもありませんが.


-- 
<signature>
    <name>Koichi Kobayashi</name>
    <e-mail>[E-MAIL ADDRESS DELETED]</e-mail>
</signature>




Seasar-user メーリングリストの案内