Java Spring Framewor ..
577:デフォルトの名無しさん
05/11/13 13:39:20
なにこれ？
あほですか？
ただ、指定のクラスを生成して、ついでにプロパティも入れるというだけ？
くだらん。
ただのFactoryじゃん。
messageを生成時に注入してHello World!かよ。
おめでてーな。
まあ、記事が馬鹿だということを予想して付属のSampleためしてくるよ。
578:デフォルトの名無しさん
05/11/13 13:43:19
>> Spring Frameworkで理解するDI（1）
(2)は、まだー？
579:デフォルトの名無しさん
05/11/13 13:53:10
>>578
もちろん1,2,3を読んでの感想ね。
いま、ExampleのCountryを読んでるんだけど、
いきなりソースを読んでも意味わからんわ。
それぞれのクラスが他に依存しないってことは
Utilを読むみたいに、いきなり読めるってことかと思ってしまった。
今から/samples/countries/*.txtを読んでデプロイして実行してみる。
580:デフォルトの名無しさん
05/11/13 14:08:34
日本用のpropertiesがないからぬるぽい。
適当になぶる
581:デフォルトの名無しさん
05/11/13 14:59:14
解説しよう
なぶる ＝ 触る
582:デフォルトの名無しさん
05/11/13 16:09:48
解説ありがとう
今から外出しないといけなくなった
とりあえずどんな実装をしていくかという
癖みたいなものはわかった。
出たついでに本屋にでも寄って理論を立ち読みしてくるわ
583:デフォルトの名無しさん
05/11/13 18:13:33
ぬるぽ
584:デフォルトの名無しさん
05/11/13 22:40:28
帰ってきたよ
理論読んでくるの忘れたから、検索するわ
あとで
585:デフォルトの名無しさん
05/11/17 20:48:05
1.2.6記念
586:デフォルトの名無しさん
05/11/28 11:55:56
閑古鳥だな
587:デフォルトの名無しさん
05/11/28 12:00:14
DIは結局流行り物だってこった。
DIスレもSeasarスレも活気ないしな。
588:デフォルトの名無しさん
05/11/28 12:06:55
需要は大いにあるけど、
言語レベルでの制約によるメリットが一部損なうことや、
リファクタリングがかなりし難くなるところがやはり気に食わないな。
589:デフォルトの名無しさん
05/11/28 12:33:48
DIコンテナがなくても
SetterInjectionとFactoryでいいけどさ。
AOPと親和力が高いのが魅力的だよね。
抜け出せない。
遅いのに。
590:デフォルトの名無しさん
05/11/28 13:15:50
つか、もうEJB3でおけ
591:デフォルトの名無しさん
05/11/28 13:18:05
でも「EJB？ﾊｧ？これからはSpringだろ」
てのを受けて試しにSpring触って第一印象が>>577ってパターンが結構多い気がするな。
592:デフォルトの名無しさん
05/11/28 20:17:43
フロントしか弄ってない俺には、Strutsの焼き直し。
593:デフォルトの名無しさん
05/11/28 21:17:10
今って分散環境だとビジネスロジックには
何が一番使われてんの？
594:デフォルトの名無しさん
05/11/28 21:21:10
あ、これじゃいみわかんねえや
モデルだった
595:デフォルトの名無しさん
05/11/28 22:32:06
>>592
Strutsとは全くかぶってないので、StrutsをどうやきなおしてもSpringにならない・・・
596:デフォルトの名無しさん
05/11/28 22:33:25
>>595
フロントコントローラ、まんまStrutsなんだが。
597:デフォルトの名無しさん
05/11/29 00:09:53
これってどこがいいの？
XMLからクラスが生成できるだけ？
598:デフォルトの名無しさん
05/11/29 00:22:41
>>595
次の次ぐらいのStrutsはWebWorkになるそうだぞ。
599:デフォルトの名無しさん
05/11/29 00:25:00
ん？IDEと統合するのを目標に作られたJSFがあるからそれはないべ？
600:デフォルトの名無しさん
05/11/29 00:34:16
>>599
ほれ。
URLﾘﾝｸ(www.mail-archive.com)
601:デフォルトの名無しさん
05/11/29 00:37:30
もうひとつ。
URLﾘﾝｸ(blogs.opensymphony.com)
スレ違い。失礼。
602:デフォルトの名無しさん
05/11/29 00:42:46
>>600-601
えーーーー。
なんかすっげー違和感・・・。
603:デフォルトの名無しさん
05/11/29 12:19:40
>リファクタリングがかなりし難くなる
なるか？
設定ファイル書き直しの手間が云々って意味？
604:デフォルトの名無しさん
05/12/01 20:40:22
SpringFrameworkのDefaultIntroductionAdvisorと
DelegatingIntroductionInterceptor の使い方がやっと分かった。
AOPヽ(´ー｀)ノﾏﾝｾｰ
605:デフォルトの名無しさん
05/12/06 10:25:25
使う場所を見つけるまでがAOPです
606:デフォルトの名無しさん
05/12/08 08:03:22
AOPとDIと、どっちが偉いの？
607:デフォルトの名無しさん
05/12/08 08:41:40
別々の話だから、比べてもしかたない。
608:デフォルトの名無しさん
05/12/08 09:35:46
どっちも偉くはないですが
609:デフォルトの名無しさん
05/12/10 23:50:35
URLﾘﾝｸ(muimi.com)
SpringのHello Worldでどのサイトをみても
これ以上のことがどこも書いていないのですが
どういった点が優れているのでしょうか？
いまいちこのフレームワークが他よりも優れいているというメリットが見えないのですが
また具体的に何が得意とかあるのでしょうか？
610:デフォルトの名無しさん
05/12/11 01:16:39
他ってなんのことを言ってるの？
611:デフォルトの名無しさん
05/12/11 15:13:00
みなさん実際に実務だとどんなところにSpring使ってます？
全面的に使ってたりする？
612:デフォルトの名無しさん
05/12/11 15:47:19
Springは使うなら全面的だろ。
613:デフォルトの名無しさん
05/12/11 15:49:33
>>612
大根としてつかうだけならどこか１部だけでもOKでは。
614:デフォルトの名無しさん
05/12/11 16:10:46
>>613
たとえばStruts使う場合だと、すべてのActionをSpringに委譲するし。
615:デフォルトの名無しさん
05/12/11 16:14:12
>>614
具象オブジェクトの生成部分を切り出す単位って、そこしかないわけか
オイ？ﾓｯﾄどこにでもあるでしょうがよ。
616:デフォルトの名無しさん
05/12/11 16:20:57
？？？
617:伝説新人タクシ
05/12/11 16:23:20
>>609
疎結合であるとかそれによって単体テストがしやすいとかいうこと？
618:デフォルトの名無しさん
05/12/11 17:11:40
Springわかんなかったんなら、EJB3を待ってたほうがいいかもね。
619:デフォルトの名無しさん
05/12/11 17:54:34
予習でやるならともかく、今の流れだと、これから本格的にSpring使うってのはなしなきがするな。
だから、逆に絶対やっといても損はない気がするけどさ。
620:デフォルトの名無しさん
05/12/12 10:29:59
そんな難しいものじゃないし、画期的な機能に満ち溢れているわけでもないよ。
ただ単に便利なツールでいいのだと思うけど。
便利なBeanFactory、それで充分だよ。
おまけで付いてくる付属品はけっこういいよ。
AOPもそうだし、ORMやらmailやらが楽チンに扱えるのも嬉しい。
S2でもSpringでもどっちでもいいけど、これがない世界には戻りたくないね。
EJB3があれば不要という話もあるね、GabinKingが主張しているように。
でもSpringを通してEJB3を使った方がより簡単、そういう機能が出てくるって予想してる。
621:デフォルトの名無しさん
05/12/12 10:36:16
というか、普通のTomcatで動かせて面倒なパッケージング不要なEJB3、みたいな感じになると思う。
622:デフォルトの名無しさん
05/12/12 10:36:44
追伸：煽るワケじゃないが、Springごときを理解できない方が
EJB3を使いこなせるとは思えない。Annotationの裏で
起こっている出来事を多少は理解している必要はある、って
認識の元の考えだけど。
623:デフォルトの名無しさん
05/12/12 10:58:46
Springってかなり裏方的な働きだから、単体ではよさがわかりにくいんだと思う。
EJB3でも、単にORマッピングだという認識で、なんだか裏側で勝手に結びつけてくれるという感じになるんじゃないかな。
624:デフォルトの名無しさん
05/12/12 16:27:03
EJB3 って来ると思う？
Java ソースにアノテーション埋め込むのと
設定ファイルに外出しされてるのと
どっちが疎結合か考えたら
EJB3 は退化してるとしか思えない。
625:デフォルトの名無しさん
05/12/12 18:56:40
アノテーションで疎結合じゃないという話は、すでに時代遅れだし、EJB3が来ないと思うなら、別の部分で批判しないといけない。
626:デフォルトの名無しさん
05/12/12 19:05:38
簡単に理由をいえば
「疎結合のためにアノテーションを排除して、なんの意味がある？」
627:デフォルトの名無しさん
05/12/12 20:42:36
ﾌﾟｹﾞﾗ
おまいらどうせ来年にはAnnotationに文句垂れてると思うよ、飽きっぽいから。
628:デフォルトの名無しさん
05/12/12 21:45:25
>>627
いや、それはそれで良いんじゃねぇの？
不満がなければ技術革新なんてねぇさ。
629:デフォルトの名無しさん
05/12/12 21:58:43
Annotationの仕様には不満があるけど、Annotation自体はとても気に入ってるよ。
630:デフォルトの名無しさん
05/12/12 22:25:06
Springで簡単なWebアプリを作るサンプルがあるサイトしらない？
WebApplicationContextを使って云々みたいな。。。
631:デフォルトの名無しさん
05/12/12 22:28:53
Struts使った方が楽だからねぇ・・・
632:デフォルトの名無しさん
05/12/12 22:53:59
AnnotationとEnumの組み合わせが好きだな
XDocletとは違って定数を指定できるし、引数の型チェックも出来る
633:デフォルトの名無しさん
05/12/13 02:02:54
StrutsよりもJSFをもう少し簡単にした物を使いたい
634:デフォルトの名無しさん
05/12/13 09:39:22
>>630
ほらよ
URLﾘﾝｸ(www-06.ibm.com)
URLﾘﾝｸ(www5f.biglobe.ne.jp)
URLﾘﾝｸ(appfuse.dev.java.net)
URLﾘﾝｸ(equinox.dev.java.net)
勧められるのは、ビジネスロジックレイヤ内にサービスレイヤを
作ってるヤツ。（Facadeかけてるやつ）
とりあえずIBMのヤツを熟読しろ。
635:教えてください
05/12/13 21:35:54
左クリックを使用できないようにjavaScriptを組んだつもりでしたが、機能しません。
どこが間違ってるのかご指南ください。
問題のＨＰ URLﾘﾝｸ(urei.ojaru.jp)
フレームを使用してますが
Ｉｍａｇｅｓ→***のリンク→左使用不可ページ となってます。
*** のページ 左使用不可ページ直リン防止script
左使用不可ページ 左使用不可script
このようにしたのですが･･･････ﾏｲﾘﾏｼﾀ
もうどうしていいのか分りません
636:デフォルトの名無しさん
05/12/13 22:01:21
>>635 はスレ(板？)違いの上に、マルチ
637:デフォルトの名無しさん
05/12/14 10:05:47
板違いというより、基地外
638:デフォルトの名無しさん
05/12/16 02:08:32
Spring.NETの方はどうですか？
同じ？
639:デフォルトの名無しさん
05/12/16 13:48:47
>>638
Spring.NETは基本的なDI・AOPの機能は既に実装済み。
DB、トランザクション、WEB等の機能はまだ開発中みたいだな。
だけど、正直.NETでDIは使う気にならないな。
640:デフォルトの名無しさん
05/12/17 13:07:47
>>639
何故？
641:デフォルトの名無しさん
05/12/24 12:10:09
ActionSupportを使ってStrutsとSpring連携させてるんだけど
このクラスのテストケースをstrutstestcaseを使って書こうとした時に
Actionから呼び出すBeanを変えてテストケース書きたい場合
Bean定義のXMLを変えるしか方法がない？
テストケース側からビジネスロジックの注入を書けると楽なんだけど、、、
642:デフォルトの名無しさん
05/12/25 01:54:24
自分で注入しちゃったら？
643:デフォルトの名無しさん
05/12/26 01:34:51
Struts + Sringでエ○画像掲示板つくってみました。
Spring入れたほうが動作は安定して早くなりました。
644:デフォルトの名無しさん
05/12/26 11:56:02
>>642
その方法がわからないんだよう
ポインタなぞあったら教えてぎぶみー
645:デフォルトの名無しさん
05/12/28 07:47:52
Spring2.0って機能面ではどう変わったんですか？
646:デフォルトの名無しさん
05/12/28 07:55:33
>>644
セッターインジェクションの場合
setXxx(value);
フィールドインジェクションの場合
xxx = value;
で注入できますｗ
647:デフォルトの名無しさん
05/12/28 14:12:36
>>645
設定ファイルがXML Schemaベースになってる。
648:デフォルトの名無しさん
05/12/29 12:31:25
Important new features include:
* Simplified, extensible XML configuration
* Powerful new Spring AOP features and AspectJ 5 integration
* Asynchronous JMS facilities enabling message-driven POJOs
* Spring Portlet MVC, a MVC framework for JSR-168 Portlets
* ... and much, much more
これって設定ファイルが結構変わるのかな？
個人的には三番目がようやくと言った感じ。
JmsTemplate はいろいろ思うように行かなくて
(非同期受信なし、リソースを開放するタイミングが制御できないなど)
結局新たに作成したものを使った。
JndiTemplate があればどうにかなった。
649:デフォルトの名無しさん
06/01/08 02:38:17
フレームワークの議論ばかりしていて実際にハイレベルな
パフォーマンス＆拡張性が要求される現場では役に立たない
方々乙かれさまです。
650:デフォルトの名無しさん
06/01/08 03:19:20
どこでも役に立たない>>649よりはマシだけどな。
651:デフォルトの名無しさん
06/01/08 03:40:27
>>635>>637>>649
652:デフォルトの名無しさん
06/01/10 15:18:00
普通なら釣りなんだろうが現場見てると
本気でそう考えてるｵｻｰﾝがたくさん居て死にそうになる。
さすがに起動時だけは遅いが、一度起動してしまえば
速度が気になったことはないな。
拡張性については具体的な例を挙げて欲しいな。
どういう要求が出た時にどういう対応をしたのかを。
653:デフォルトの名無しさん
06/01/11 03:07:47
HibernateDaoSupportを使う場合にQuery#setFirstResults(int)やsetMaxResults(int)を
使うにはどうすればいいかご存じの方はいませんか?
getHibernateTemplate().find* ではQueryオブジェクトを渡せないし。。。
getSession()して自分で処理するしかないかな。
Spring 1.2.6 です。
654:デフォルトの名無しさん
06/01/11 11:24:00
>>653
HibernateCallback
655:653
06/01/11 22:34:55
>>654
return getHibernateTemplate().execute(new HibernateCallback() {
public Object doInHibernate(Session session) {
// クエリ投げて結果を返す
}
}
って感じですね。マニュアルにも載ってました。ポイントありがとう。
656:デフォルトの名無しさん
06/01/21 20:54:23
URLﾘﾝｸ(pcweb.mycom.co.jp)
> Drools 2.5 BETA 2において提供されている拡張モジュールはdrools-decisiontables、
> drools-dotnet、drools-examples、drools-groovy、drools-ide、drools-io、drools-java、
> drools-jsr94、drools-python、drools-smf、drools-smftest、drools-spring、
> drools-spring-examples、drools-spring-jdk5。ベースとなる藻ジュースはdrools-base、
> drools-core、drools-core-3.0。
Springにも対応しているらしいルールエンジンだが、なんだかベースが不味そうだ。
657:デフォルトの名無しさん
06/01/21 21:14:58
>>656
「藻ジュース」(・∀・)ｲｲ
658:デフォルトの名無しさん
06/01/22 10:27:33
いや飲みたくはない……
659:デフォルトの名無しさん
06/01/23 21:26:19
今、新しいｱﾌﾟﾘ作るんで、まあ流行のSpringと扱い慣れているStrutsでと思っています。
まずはｱｰｷﾃｸﾁｬを決めるために、いろいろサンプルを作ってみてるんですが、質問です。
Struts&Springの連携で、代表的なのは
1) ActionSupport
2) DelegatingActionProxy
3) DelegatingRequestProcessor
の3つだと思うのですが、2) or 3) で決めかねています。
1)はせっかくなんでつまらないのでﾎﾞﾂ。
残るはDelegatingActionProxyとDelegatingRequestProcessorですが、
機能的にどちらが良いのか分かりません。
どちらかと言えばActionを継承させてBaseActionを使っていたことが多いのですが、
RequestProcessorの方が上位ですよね。
アプリケーションは到って小規模なんでどちらでも同じだと思いもするのですが、
考慮すべき点や拡張性の点等、ご助言･苦言を頂けないでしょうか。
非常に基本的な質問で恐縮ですが、
660:デフォルトの名無しさん
06/01/23 23:34:09
たいくつでつまらない技術が一番強い。
661:659
06/01/24 11:18:42
>>660
確かに、ごもっともだと思います。
実はこれまでの開発ではSpringを使う機会もあったのですが、
見易さ、改修性の高さ、開発規模から
ServiceはInterfaceを使わずに実装しました。
(さすがにDAOはiBatis使って分けましたが)
それに比べ、今回は10年前にCで作った参照のみのアプリの更新で
時間的な余裕もあるので遊びたいと思ってます。
APIも読んでみたのですが、XDOCLETを使うか、また宣言で問題があったら、
といった使い分けの程度しか理解できませんでした。
みなさん、どのような使い方されているのでしょうか、教えて頂けるとありがたいっす。
662:デフォルトの名無しさん
06/01/24 13:57:58
>659
(1) と (3) は Struts に変更があったら、思い切り引きずられそう。
TilesRequestProcessor が出ようが新規に Action が発明されようが
涼しい顔して DelegatingActionProxy でラップするのみの (2) が好きですね。
(ていうか (2) しか使ったことないですけど。)
その分設定ファイルは煩雑になるわけですが。
自分の分かりやすいと思える方法でやるのが一番かと。
小規模でそれほど寿命も長くないのであれば、(1) も手っ取り早くていいと思いますよ。
XDOCLET は思ったほど便利じゃないと言うか、
開発の間に試行錯誤してると、結局手で書いたほうが速かったでした。
↑これは設計がまずかっただけかも知れません。
663:デフォルトの名無しさん
06/01/24 23:17:11
>>662
Actionベースはやはり分かり易いですよね。
人数が多いそれなりの規模なら、間違いなくActionProxyでいくと思います。
いくつかサンプル作ってみたのですが、3種類の感想は
ActionSupport
-確かに楽だけど、Springの楽しさは十分に味わえない気が。
でも実装はまんまActionなんで、いたって簡単。
しかもプログラマの質がそれなりなら、自分入れて3人位いれば
中規模まで行ける気がする。
ActionProxy
-実質これがStruts&Springの標準でしょう。
至って堅牢なシステムが訳分からん害虫と一緒でもテストファーストで
スムーズに作れそう。
しかもこれまでのStrutsの資産も十分に生かせるんじゃないでしょうか。
RequestProcessor
-Controler以前の処理をガチガチにやるのであれば、やはりRequestProcessorだと
思います。
が、幾分硬すぎる気が。大人数のRUPには向いているかな。
自分ごときが作るシステムはそれほどクリティカルじゃないし、ユルイと思うのですが、
まあ当たり前、と言った感想でしょうか。
今回はActionProxyからやってみようと思います。
時間もある分、新しい人も多いんで。
また進展したら報告します。 いらんか。
664:デフォルトの名無しさん
06/01/25 12:22:51
＞また進展したら報告します。 いらんか。
最近スレが過疎ってるからチラシの裏でも問題ないかと。
＞訳分からん害虫
でかいところが素敵なフレームワーク作ってるかと言うと
そんな仕事にありつけたことが一度もないのは運が悪いんだろうか。
665:659
06/01/25 22:18:20
>>664
なかなか難しく厳しい問題です、拡張性･メンテナンス性を含めた機能美で言えば。
確かに誰がやったん?ってひどいのもありますが、現状では仕方ないかとも思っています。
1つはレガシーのためです。
やはり遺物であっても今から見ればあほあほなRDB設計であっても
どうしても引きずらないではいられません。
例えばホストシステムの特定部分をWebに置き換える際、レガシーのデータやインターフェースは
その他のホストのためにつないでやらないといけません。
おかげでせっかくのDAOも、結局は???になってしまいがちです。
これまで私も挑んだのですが砕け散りました。
もう一つは、企業にとってみればシステムが構築されれば後は減価償却の対象でしかありません。
本来3ヶ月かけて作るべきものであっても即興で1.5ヶ月でつくれば評価されてしまいます、
掛けたくないのは人件費な訳ですから。
もちろんこんなシステムの維持のコストは高いです。が、トップの方々には見えてきません。
ユーザーからの機能追加要望があった、といえば、それなりのコストであれば通ってしまいます。
海外拠点との情報連携なんてつけてやれば大喜びです。
(フェーズ毎に見積もりきちんととって開発も難しいのが現状ですから・・・)
と、過疎板でうだつのあがらん社内SEが独り言ってみました。
666:デフォルトの名無しさん
06/01/25 22:53:35
664ですがマ板向きな話題になりそうなのでこの件はクローズ。
脱線させてごめんなさい。
667:デフォルトの名無しさん
06/01/29 00:03:48
すいません、Spring.NETの話題もここで良かったりします？
668:デフォルトの名無しさん
06/01/29 09:45:51
わかんない。
けど、とりあえず書いてみれ
669:デフォルトの名無しさん
06/01/31 10:23:30
>>659
＞うだつのあがらん社内SE
お前様はオレですかｗ
疑問に思ったことを二つ。
＞見易さ、改修性の高さ、開発規模から
＞ServiceはInterfaceを使わずに実装しました。
何故だよ？ facadeした方がP層から見たときに理解しやすいし、
実装ロジックを意識しないで済むと思うのだけど。あと例えば
君がAPI定義して、君の手下が実装する、なんて作業も
スムースになると思うのだけど。
あと、その場所にSpringのTransaction制御は適用してるの？
それとも君達でゴリゴリ書いているの？
そこがSpringの一番美味しい所だと思うのだが。
670:デフォルトの名無しさん
06/01/31 10:24:23
＜連投＞
＞流行のSpringと扱い慣れているStrutsでと思っています。
扱い慣れているとはいえ、何故に死滅が確定している
現verのStruts？ 同じ社内SEの立場として言うが、
それって将来に禍根を残すんじゃないの？
特に、struts-taglibを使うのは忌むべきことじゃないのか？
高度にクリティカルじゃなくてもいいなら、素直にJSFを
採用すりゃいいじゃん。もし、strutsじゃなきゃ人材を
確保できねぇと言うなら、せめて
org.springframework.ui.velocityパッケージの研究を
してから決定した方がいいんじゃないの？
671:デフォルトの名無しさん
06/01/31 12:13:28
死滅とかはNG Wordに入れてる人も居るから避けたほうが吉。
JSF はもう少し枯れてからの方が良くない？
今のところ、Velocity でやっちゃうのが一番直感的に思う。
672:デフォルトの名無しさん
06/01/31 12:24:21
うちで使ってるアプリケーションサーバーはJSPしか動かねぇ
Servletすら使えない
673:デフォルトの名無しさん
06/01/31 15:42:57
釣りには屈しない
674:デフォルトの名無しさん
06/02/01 09:47:13
おぉ、まだ居る方が。
>>669
ServiceのInterfaceについては、いかに害虫がｵﾌﾞｼﾞｪｸﾄ指向を知らなくても
ｵﾌﾞｼﾞｪｸﾄ指向らしいJavaになるか考えてこうなりました。
まずあの方達はｸﾗｽを上手く切り出せないんです、最初は。
で、下手にInterfaceやって使いまわしなんて考えると開発中の手入れが
恐ろしいことになり、ある意味好き勝手にやってもらいました。
で、DAOについてはﾒｿｯﾄﾞが明確なんでInterface切ってやってもらってます。
iBatisを使ってるんですが、こいつだとDAOの中のみでTransaction制御できるんで
助かります。
これだと統合ﾃｽﾄ中にこっちでｸﾘﾃｨｶﾙな部分がすぐいぢれるんで楽なんですよ。
675:659
06/02/01 10:14:07
書き忘れですが、674 = 659です。
Strutsについては、JSFでの置換えも検討しましたが、
今回、自分以外はJavaでWebやるの初めてなんですよね。
やはりﾌﾞﾗｳｻﾞからRequestをServletで受けて、というのを実感
し易いのはStrutsかなぁ、と思います。
JSF、VBちっくにﾄﾞﾗｯｸﾞ＆ﾄﾞﾛｯﾌﾟでできてしまうんで、最初からこれだと
裏の理解が薄く後々に生きない気がします。
それと社内SE的にはもう少し枯れてからで良いかなと、正直思います。
Taglibについては、個人的にこれ以上覚えられるかー、ということで
beanとlogicにのみ制限しています。
まあ多少beanを拡張はしていますが。。。
個人的には、Struts → JSFで行きたいなと、Viewについては。
676:669
06/02/01 10:53:44
>>659
＞DAOの中のみでTransaction制御
これって複雑なことをやろうとすると破綻しないかい？
複数のテーブルを更新するのもDaoのメソッド単位になる、
従って肥大したDaoImplを書かざるを得なくなる、という原因で。
オレのやり方だとこんな感じだ。
<ServiceLayer>
public void deposit(Account account, Money increasedMoney){
accountDao.update(account);
revenueDetailDao.insert(account, increasedMoney);
}
で、トランザクションはあくまでserviceLayerに置く。つまり上の
depositメソッドに対してPROPAGATION_REQUIREDを設定する。
オレはさらに、dao層、上の例ではaccountDao.updateと
revenueDetailDao.insertに対しては
PROPAGATION_MANDATORYをかけている。
これによりserviceLayerを通さずにDaoに触ったら即座にアポーン。
君の「DAOの中のみでTransaction制御」だと、上の二つの
メソッドを一つにまとめないと原始性を維持できないのでは？
勘違いだったらｽﾏｿ。
677:659
06/02/01 12:13:46
>>669
DAO単位で考えれば原始性を維持できない可能性は仰る通り存在します。
でも、実際の使用で考えれば、多少複雑なﾃﾞｰﾀはﾕｰｻﾞに紐付いているわけで、
2重ログインを防げば、問題無しという訳です。
美しくないことは、確かですが。
Springでのﾄﾗﾝｻﾞｸｼｮﾝ管理は、まだ読んだだけですけど、実装も含めｽﾏｰﾄですね。
ﾄﾗﾝｻﾞｸｼｮﾝ属性なんか、いかにも楽できそうで。
DAOは何を使われてるんですか?
今回はHibernateが親和性も高く、情報も多いんで使おうかと思ってます。
678:669
06/02/01 13:12:05
う〜ん、オレにはそれはチョト怖く感じる。
更新が途中で落ちる可能性なんてゴロゴロしてるワケだし。。。
（オレには納得いかんが）落ちる可能性を完全無視するとしても、
その場合は最低でもペシミスティックロックで組まんとイカンと
思うのだけど。。。
頼む、トランザクション管理層をserviceLayerに持ち上げとくれ。
Spring使えばチョチョイのチョイだ。
iBATISは好きだぉ。
679:デフォルトの名無しさん
06/02/01 16:24:19
>>669
仰ってることが分かってきました。
自分が話しをごっちゃにした予感です、害虫さんと自分の立場を。
害虫さんのﾄﾗﾝｻﾞｸｼｮﾝ管理は、はっきり言って、信用してません。
で、問題があった際にDAOとServiceを引っ張って考えるのはしんどいんで
DAOについてはiBatisのAutoCommitにして、自分はServiceに集中できるように
している、という話です。
読み返してみると、確かに訳分からん話してますね、自分。
そういえば、SpringとベストマッチなDAOって何でしょ?
iBatisもいけるようだとﾈｯﾄに載ってた気がしますが、やはりHibernateですかね?
他に面白いのないでしょうか。
680:デフォルトの名無しさん
06/02/01 20:56:14
HibernateはDBを一から設計するっていうならおすすめ
既存のDBがからむならiBatisの方が無難だとおもう
害虫さんがいてiBatis学習コストが気になるっていうなら
Spring JDBCでもいいんじゃない？
681:デフォルトの名無しさん
06/02/02 01:17:25
>>675
＞Taglibについては、個人的にこれ以上覚えられるかー、ということで
＞beanとlogicにのみ制限しています。
Strutsでやるんなら最低限必要なStrutsタグはhtmlタグのみで、後はJSTLで置き換えるのがお勧め
JSTLはJava EE5に含まれることが決定しているし、JSFも1.2からはJSTLと連携出来るようになる
682:デフォルトの名無しさん
06/02/02 01:36:23
お勧めとかではなく、beanとかlogicを使うべきではない、という感じだな。
683:659
06/02/02 10:15:36
>>680
既存DB、IMSもRDBもわんさかあるんで、これまではiBatisだったんですよね。
ｵﾌﾞｼﾞｪｸﾄﾍﾞｰｽでのDB考えるなら、Hibernateというｲﾒｰｼﾞは確かに強いですよね。
そんな幸せな開発はやったことありませんが。
>>681、682
z/OS中心の製造業社内SE的には、Webのプレゼンテーション層については過渡期に
感じるので、枯れ果てた技術で十分かなと思います。
新しい技術を入れても今後ﾒﾝﾃする人が大変なだけですよ、うちのような環境では。
JDKにしても既存のものは1.4.Xが限度で、5にすることなんてありえません。
ぶっちゃけ、手間の割にﾒﾘｯﾄがあんまり考えられません。
それよりも新しいWASには5を導入する方向で考えると思います。
個人的にはJSFの熟成を期待しつつ、ちょっと複雑になりそうだったらﾘｯﾁで、
と行ければ良いなぁ。
・・・今はこんなこと考えている自分が、ちょっと嫌。
Javaを始めて勉強してた頃はｵﾌﾞｼﾞｪｸﾄ指向に感動し、新技術ﾏﾝｾｰだったのに。
他に居ないのかな、こんな方。
684:デフォルトの名無しさん
06/02/02 11:17:28
>682
beanを使うべきじゃないとは言っても、
messageはなかなか避けられないような。
685:669
06/02/02 11:31:58
おいおい、そんな後ろ向きになるなよ。
新技術に対する感動を忘れたらオレらの仕事はつまらなく
なるばかりだぜ。つーか、今でもspring・iBATIS・hibernateって
やってるんだろーが。何でviewだけそんなに野望を失うのさ？
struts-taglibは、数年後には非推奨API（あるいはそれに準じた
無体な扱いを受ける立場）になるんだぜ？ 君は後進に
非推奨APIのメンテをさせる気かい？
JSF怖くないってｗ つーかあれ便利だぞ。少なくてもstrutsに
比べりゃね。なんつったて同じ作者の二番煎じなんだから。
JSF自体がDI持ってるからSpringとの組み合わせもし易いしね。
練れてなくて意味無い所で苦労を強いられるのは認めるけど。
な〜んて書きながら、オレ自身もJSFマンセーには
なりきれないのだけどね。初期の頃に宣伝されたリッチ
クライアント対応とか全然進んでねぇし。（JDNCは実質
ポシャったみたいね） 早いとこJSPの呪縛から抜け出して
欲しいと思っているのに、なんか全然別の方向に逝こうと
しているみたいだし。。。
愚痴ｽﾏｿ
686:デフォルトの名無しさん
06/02/02 11:44:00
JSFも悪くないと思うけどね、まだ出来たてのせいか
ちょっとこなれてない感じ。 EL式とかアレだし。
sunのより高機能なんでmyfaces使っても、バグが結構あって
DataTableとか微妙な挙動をする場合がある。
1.2待ちかな
687:デフォルトの名無しさん
06/02/02 13:02:24
>>684
messageは使うね。
>>686
2年もたってるのに、出来立てはないとおもう
688:659
06/02/03 12:37:57
>>669
Viewも野望だけはあるんですけどね。
ただWebだと、JSFにしても色々あり過ぎて、決め手に欠けます。
それにお偉方の説得材料が足りません。
もう暫くおとなしく待って、淘汰されてから選んで良いかな。
Viewはお偉方にも分かってしまうんで、ここ以外は、好き勝手やれるんだけどねぇ。
689:デフォルトの名無しさん
06/02/03 13:49:52
正直jsp2.0で十分な気が
690:デフォルトの名無しさん
06/02/15 15:03:14
Hibernate3初心者ですが、ちょっと教えて下さい。
many-to-one のﾏｯﾌﾟで、もし該当ﾃﾞｰﾀが存在しなくても怒られない方法、
知りませんか?
例えば
<class name="item">
<id name="id"/>
<many-to-one name="bid"/>
</class>
<class name="bid">
<id name="id"/>
<pro name="amount"/>
</class>
これで
from Item item left join fetch item.bid をやって、
取得したリストを表示させると、bidを取得できなかったitemの
item.bid.amountをgetすると、
LazyInitializ E org.hibernate.LazyInitializationException TRAS0014I: 次の例外がログに記録されました。 org.hibernate.LazyInitializationException: could not initialize proxy - the owning Session was closed
と、ｱﾎﾞﾝです。
session閉じて分離ｵﾌﾞｼﾞｪｸﾄになってんだから、良いじゃん、
と思うんだけど、教えて下され。
691:デフォルトの名無しさん
06/02/15 15:11:12
>>690
スレ違い
ｽﾚﾘﾝｸ(tech板)
692:690
06/02/15 15:56:38
>691
ｽﾏｿ
693:デフォルトの名無しさん
06/03/07 11:35:44
保守、というか1.2.7記念。
694:デフォルトの名無しさん
06/03/07 12:03:36
EJB3.0 のどこが DI なのかと思い始める今日この頃。
695:デフォルトの名無しさん
06/03/07 12:49:55
つまり、勉強不足？
696:デフォルトの名無しさん
06/03/07 23:10:38
@EJBアノテーションによるフィールドインジェクションだが？
697:デフォルトの名無しさん
06/03/07 23:40:25
まぁ勉強不足なのは確かだが。
結局クライアントコードに依存性を書いてる辺りが、
確かに従来のJavaの文法じゃないけど
アノテーションと言う名前のただの lookup じゃん、とか。
(DIとは関係ないが)@Statefulも
アノテーションと言う名前の implicit な interface になっただけで
同じことをするのに書法のバリエーションが増えただけで
Perl のガラクタ折衷主義を思い出したり。
698:デフォルトの名無しさん
06/03/08 22:01:48
"アノテーション使ってるからDIじゃない"っていいたいの？
interfaceがメソッドに付けれますか、と。
"ただのlookup"ではないしな。
結局アノテーションどうこうとゴネてるやつって、変化を受け入れれないだけなんだよな。
699:デフォルトの名無しさん
06/03/09 01:38:51
クライアント側でリソース名を明示的に書いているから
DIとはいいがたいと思ってます。
＞"ただのlookup"ではないしな。
どんな嬉しさがあるか、教えていただけないでしょうか。
煩雑な記述が減る程度しか思いつきません。
＞interfaceがメソッドに付けれますか、と。
@Stateful はメソッドに付かないと思うけど。
700:デフォルトの名無しさん
06/03/09 03:37:13
>>699
> クライアント側でリソース名を明示的に書いているからDIとはいいがたいと思ってます。
つまり、DIをわかってないと。
701:デフォルトの名無しさん
06/03/09 13:01:15
そっか。DIの定義が変わったのか。
702:デフォルトの名無しさん
06/03/09 22:20:05
>>701
変ってないだろ。
君が勘違いしてるだけ。
703:デフォルトの名無しさん
06/03/11 15:16:19
2.0になってどう？
近い将来でseasar使うか2.0使うか迷ってるんだが、
Spring側の利点が見つからない・・・
両方つかってみたけど、seasarだとXMLをかなり省けるから
楽なんだが・・・
誰か意見ください。
704:デフォルトの名無しさん
06/03/13 13:14:45
>702
DIって、クライアント側で明示的にリソース指定した部分が
コンテナが注入するようになって素敵だよって流れだと思ってたんですが。
で、勘違いのない本当の定義とは？
>703
利点が見つからないならSeaser2使えば良いかと。
とりあえずXMLが省けることは多分大した利点にならんよ。
705:デフォルトの名無しさん
06/03/13 21:56:40
横槍ｽﾏｿ
>>704
そもそもEJB3のDIは「明示的にリソース指定」はしないぞ
＞とりあえずXMLが省けることは多分大した利点にならんよ。
その根拠は？
書かなくて済むのであれば書かないに越したことは無いし
XMLのメンテナンスだって馬鹿にならない
706:デフォルトの名無しさん
06/03/13 23:15:36
>>704
DIの最低限の定義は、自分でインスタンスをとって来ないで、よそから注入してもらうこと。
@EJBアノテーションつけたとしても、それなりのコンテナ使わない限りなにも影響はない。
そのままSpringやSeasar使えばそれなりに注入される。
707:デフォルトの名無しさん
06/03/14 10:32:53
DIに関して705氏と706氏の意見で納得。
確かに自分でインスタンスとってきてるわけではないね。
俺はとってくる情報が書かれてることそのものが嫌いなんですが
これはDIとは関係ないってことですね。
>その根拠は？
autowire 使えばそれなりに記述量は減るけれども
曖昧さが増えてかえって混乱を招くだけだった、との経験から。
Seasar2だと違うのかも知れない。
適当なこと言ってごめんなさい。
それにしても盛り上がらないスレですね。なんでだろ。
708:デフォルトの名無しさん
06/03/14 18:46:23
一部雑誌や新しいもの好きが飛びついてるだけで
現場ではほとんど使われてないから。
709:デフォルトの名無しさん
06/03/14 19:36:29
はい、飛びつきました
710:デフォルトの名無しさん
06/03/14 22:14:33
うちでは全部SpringかSeasar使ってるが、世間ではそうなのか？
トランザクションに関してはとても楽だが
711:デフォルトの名無しさん
06/03/15 17:34:47
>>707
いったん使い出せば、通常の範囲では質問もなにもないし、特に話題がないからかもね。
712:デフォルトの名無しさん
06/03/15 17:52:50
ｲｲﾅｰ
うちで使ってるｽｹﾞｰ高いアプリケーションサーバーは
jspしか使えない
713:デフォルトの名無しさん
06/03/15 21:47:24
そりゃないんじゃね〜の？
714:デフォルトの名無しさん
06/03/15 22:14:35
>>712
BroadVision One-To-One
以前はC++しか使えなかった。マジで。
715:デフォルトの名無しさん
06/03/15 22:14:55
713宛てだった
716:デフォルトの名無しさん
06/03/15 22:30:54
「Portal,Commerceの価格は1CPUで810万円からとなっております。」
ΣΣ（ﾟдﾟlll）
717:デフォルトの名無しさん
06/03/16 00:03:31
そういやあ、WebObjectsも昔は７５０万とかしたよなあ。。。。
718:デフォルトの名無しさん
06/03/16 00:05:24
製品カタログ見ても何をするものなのかが分からん。
719:デフォルトの名無しさん
06/03/16 02:13:23
JSPしか動かないTomcatみたいなの
ショボいDBのラッパーとかユーザー管理とかビジネスルールのライブラリとかがいっぱい付いてる
あと やたら高い
720:デフォルトの名無しさん
06/03/16 03:57:55
うちの会社で出してるゴミコンポーネントも945万円するお。
1年で1個売れれば万々歳だって。
721:デフォルトの名無しさん
06/03/17 16:09:08
そりゃむしろ、945万もするから売れるんだろう。
金を出す人間は、無料でしっかりしたモノを嫌がって
バカ高くてヘボいモノを好む傾向にあるから。
で、現場は地獄を見る、と。
722:デフォルトの名無しさん
06/03/17 17:20:41
無料だとちょっと問題が出るとすぐ捨てるけど、
金かけてると捨てるわけにはいかないからなあ
723:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 20:26:19
TextSS のWindowsXP(Professional)64bit化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
724:デフォルトの名無しさん
06/03/25 12:11:47
なあ、参照しかしないクエリーでもトランザクション切ってる
なんて事ないよな？
サービスのインスタンス化時にトランザクション切るのをデフォルト
にしてるのを見たことあるぞ。。。
同時アクセス数増えたとき、大変な事になるのがわからんのじゃろうか。
725:デフォルトの名無しさん
06/03/27 10:58:31
AOPでトランザクション管理するなら、
READだけの処理では普通は開かんようにするはず。
726:デフォルトの名無しさん
06/03/27 14:11:08
>AOPでトランザクション管理するなら
してなかったりして
727:デフォルトの名無しさん
06/03/27 16:22:43
貼っとく
【BEA】Using the Java Persistence API with Spring 2.0
URLﾘﾝｸ(dev2dev.bea.com)
728:デフォルトの名無しさん
06/03/27 19:02:56
>>724
どうして大変な事になるの？
729:デフォルトの名無しさん
06/03/28 09:58:12
複数のテーブルを参照してひとつのデータを作るような場合は、
読み込みでもトランザクションきらないとまずいんじゃないの？
730:デフォルトの名無しさん
06/03/28 10:11:35
>>729
> 複数のテーブルを参照してひとつのデータを作るような場合は、
JOINではなくて、複数のSELECT発行って事？
731:デフォルトの名無しさん
06/03/28 11:05:09
>>730
ISOLATION_LEVELのデフォルトって普通はREAD_COMMITTEDじゃないの？
複数のSELECTまで考えるとISOLATION_LEVELをREPEATABLE_READに変更しないと駄目じゃない？
732:デフォルトの名無しさん
06/03/28 11:33:17
>>731
InnoDBのデフォルトはREPEATABLE_READみたいだなあ
733:730
06/03/28 11:45:37
>>731
>>732
DBベンダによってデフォルトが異なる。んで、大抵はREPEATABLE_READ(らしい)。
結論としては、複数のSELECTを発行するサービスのメソッドは
トランザクション制御しなきゃならんって事か。
734:731
06/03/28 11:59:04
>>732
Oracleのデフォルトは文レベルの読み取り一貫性(READ_COMMITTED)だったような...
>>733
>結論としては、複数のSELECTを発行するサービスのメソッドは
>トランザクション制御しなきゃならんって事か。
加えて以下の様に明示的にISOLATIONレベルを指定しないといけないのかな？
<property name="transactionAttributes">
<props>
<prop key="get*">PROPAGATION_REQUIRED, ISOLATION_REPEATABLE_READ, readOnly</prop>
</props>
</property>
735:733(=730)
06/03/28 12:24:32
>>734
いささか古いが、
URLﾘﾝｸ(www.tomlauren.com)
によると、OracleのデフォルトはREAD_COMMITTEDみたいだ。
でも、REPEATABLE_READがNotSupportって事になると、
SERIALIZABLEしかないな。
最新の公式資料キボン。
736:731
06/03/28 14:16:43
>>735
Oracleで以下の操作をやると
conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);
java.sql.SQLException:
READ_COMMITTEDおよびSERIALIZABLEのみが有効なトランザクション・レベルです。
...
ってエラーが出るよ。
Oracleだと更新処理を伴うトランザクションでトランザクションレベルの読み取り一貫性を
保証したいのであればSERIALIZABLEを指定するしかないのでは？
※更新処理を伴わないのであればreadOnlyだけで大丈夫みたい
でも実際にSERIALIZABLEがどうしても必要になる局面があんまり無いような気も...
で、元の話は
>>724
> なあ、参照しかしないクエリーでもトランザクション切ってる
> なんて事ないよな？
ってことだけどこれって
読み取り一貫性を保証しなくて良い参照のみのトランザクションでAOPで管理せず、AutoCommitも無効にしている場合、
明示的にトランザクションを開始する必要があるのか？
という意味なのかな？
737:デフォルトの名無しさん
06/03/28 16:19:46
Strutsを使った場合の、AOPによる宣言的トランザクション管理について意見を聞かせてください。
(前提)
・サービスクラスの各メソッドはAOPによって宣言的トランザクション管理されている。
(処理)
・リクエスト->更新Action->表示Action->JSPとディスパッチする。
・更新Actionと表示ActionはサービスクラスのupdateHoge()やfindHoge()を呼び出す。
これだと、1回のリクエスト中に2つのActionが2回ビジネスロジックを実行するから、
トランザクションも2回発生してしまいますよね？(1操作=2トランザクション)
何となく腑に落ちませんが、これが当たり前なんでしょうか？
それとも、Facadeサービスから更新も検索もまとめて呼ぶべきでしょうか？
更新と検索の引数リストが全く異なる場合はFacadeしたくないんですが…
738:デフォルトの名無しさん
06/03/28 20:03:23
好きにしろとしか……
個人的には、更新作業の頻度次第で決める
739:デフォルトの名無しさん
06/03/29 11:26:28
本家よりコピペ
Spring 2.0 Release Party in Stuttgart (organized by JUGS)
Submitted by Juergen Hoeller on Fri, 2006-02-24 18:31. Event
Start: 2006-03-30 14:00
End: 2006-03-30 23:00
Timezone: -14400
いよいよ2.0が間もなく到来だぬ。
ところで2.0の目玉って何なのさ？（恥）
740:デフォルトの名無しさん
06/03/29 16:35:27
>>738
んじゃ、Action2つにする。
とりあえず、HibernateでOpenSessionInViewしておけばAction2つでも
1トランザクションになるよね？
741:デフォルトの名無しさん
06/03/31 23:11:17
>>740
トランザクションとHibernateのセッションの区別はついてますか？
742:デフォルトの名無しさん
06/03/32 00:26:43
これ、掻い摘んでいうと何？
743:デフォルトの名無しさん
06/03/32 01:38:39
軽量コンテナ
744:デフォルトの名無しさん
06/03/32 05:59:35
>>742
「Java2EEなんかクソくらえ」
745:デフォルトの名無しさん
06/03/32 06:03:37
今日は32日だ。うそをついていい日ではない。
746:デフォルトの名無しさん
06/03/32 10:39:20
URLﾘﾝｸ(www.2ch.net)
＊エイプリルフール中止のお知らせ＊
本年度、ITバブル崩壊の余波、またライブドア事件の混迷、楽天ゴールデンイーグルスぶっちぎり最下位など、
悪条件の重なりによる株価低迷が２ちゃんねる運営費にも多大なる影響を与え、
火の車である今の財務状況を鑑みるに、エイプリルフールの全面中止もやむなしという判断にあいなりました。
ご期待されていた皆様には大変申し訳ありませんが、どうぞよろしくご理解いただければ幸いです。
また、妄言民族と呼ばれ、近隣アジア諸国に多大なる苦痛を与えている日本国民としてこれを良い機会と考え、
例えエイプリルフールだとしても嘘を無くし、世界平和に貢献できる公明正大な言論の場を標榜すべく襟を正しつつ、
２ちゃんねるはエイプリルフールの根絶に今後とも邁進していく所存でございます。
747:724
06/04/02 12:30:05
>読み取り一貫性を保証しなくて良い参照のみのトランザクションでAOPで管理せず、
>AutoCommitも無効にしている場合、明示的にトランザクションを開始する必要があるのか？
そうじゃ。RDBにもよるが、読み取り一貫性を実現するために、大体がテンポラリ領域に
データをコピーしている（OracleとSQL Serverは少なくともそう）。
この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。
（同時アクセスが多いと、Tempがクリアされる前に次が来ちゃうからじゃ）
このエラーを受けてDB屋にTemp領域増やせっていうのはナンセンス。
もちろん、ビジネスロジック上大きなTempが必要な場合もあるからそれは、
ちゃんと見積もりをDB屋に伝えればいい。大きくするのに否定的な訳じゃなく
PGの手抜きに対して文句を言ってるんじゃ。
また、上記の事だけじゃないが、上記だけからでも結構コスト（負荷）
が掛かることは言うまでもないよな。
748:デフォルトの名無しさん
06/04/02 13:10:03
>>747
> そうじゃ。RDBにもよるが、読み取り一貫性を実現するために、大体がテンポラリ領域に
> データをコピーしている（OracleとSQL Serverは少なくともそう）。
オラクルは違うだろ。
データがコピーされるのは読み取り時じゃなくて更新時。
コピー先はテンポラリじゃなくてUNDO表領域。
> この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。
頻繁に閲覧されてもそれだけじゃエラーにならない。
頻繁に更新されている時にのんびり読んでるとORA-01555
本当に理解して書いてるか？
749:デフォルトの名無しさん
06/04/02 15:04:58
> > この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。
>
> 頻繁に閲覧されてもそれだけじゃエラーにならない。
> 頻繁に更新されている時にのんびり読んでるとORA-01555
> 本当に理解して書いてるか？
激しく同意。
付け加えるなら、Oracleではトランザクションの有無にかかわらず
文レベルの一貫性は常に保証しようとするから、
> 頻繁に更新されている時にのんびり読んでるとORA-01555
という状況はトランザクションの有無にかかわらず起こりうる。
だから、>747の主張は少なくともOracleには当てはまらない。
750:740
06/04/02 18:58:45
>>741
スマソ＆サンクス
考えてみれば、サービス層でAOPトランザクション管理していると、
複数Actionが複数サービス呼び出す時点で複数トランザクションになる…
んでOpenSesseionInViewしてもHibernateのSessionが1つに保たれるだけですな。
結論すると、2Actionだと2トランザクションでいくしかないのか。
751:731
06/04/03 14:34:04
あんまりSpringと関係が無くなって来たような気が...
>>747
>>748
>>749
読み取り一貫性に関しての詳細は置いておいて元の話だとOracleでは
以下になるんじゃないかな？
必要な読み取り一貫性が文をまたがるのであれば読み取り専用の
トランザクションを明示的に開始する必要がある。
必要な読み取り一貫性が文レベルでよいのであれば明示的にトランザクションを
開始しなくても良い(コネクションを生成した際のトランザクションがずっと使われている)
但し、更新処理の前にはCommitを発行して明示的にトランザクションを開始する必要がある
どちらにしてもOracleで更新やロックを伴わないトランザクションでCommitを行っても
無視される(v$sesstatのuser_commitは増えない)のでパフォーマンスには大した影響を与えない
結局のところ空コミット(参照のみトランザクションでのコミット)のコストの話なのかな？
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4912日前に更新/243 KB
担当:undef