07/12/11 11:33:13
うーん、でもな、オブジェクト（EO）のデッドロックだったら、ちょっと前のEOFなんかだと結構簡単に出てたよ.
リリースノートにそんな感じのことが書いてあった希ガス.今は改善されてるんかもしれない.
WOFもそうだけどやはりコンテクストというWebアプリでは制御が難しいカラクリをベースにしてると
複雑度が増してしまうんだろうな～とｵﾓﾀ.へんなSQLが飛ぶからDB側でのデッドロックも起きやすいヨとDB屋からも指摘されたことがある.
参照系はEOじゃなくてCollection系で、CRUD系処理のごく短いトランザクション処理でEOを使うようにしてる.
機能はとても良くできてるだろうけど、安全に使いこなせるようになるのに時間がかかるという感じかな
382:デフォルトの名無しさん
07/12/11 22:57:15
>>381
デフォルトecと、参照専用のshared ec だけ使っていれば、滅多に競合なんてしない。
■参照系こそEOを使うべき。リレーション張らずに何のためのEOか？
ネステッドEC使えば、たいていの処理はデフォルトecだけで済む。
ロックに関するマニアックな資料
URLﾘﾝｸ(www.spice-of-life.net)
383:デフォルトの名無しさん
07/12/12 10:00:10
どっかでEOFとSeasar2のベンチ比較やってるのをみた希ガス
すごい遅かったような
384:デフォルトの名無しさん
07/12/12 23:08:15
>>383
EOFは実行時もインタプリタだもの。（EOの定義はテキストファイル）
「速度が気になるような用途はストアドプロシジャ使え」ってのがセオリー。
※ Seasar2のO/R Mapperって、ＳＱＬ文をそのまま書いてるような奴だろ？
コード補完機能付のエディタがないと使い物にならない、気持ちの悪い書き方するアレ。
385:デフォルトの名無しさん
07/12/12 23:59:48
select * from テーブル where ...... のような単純なSQLをはき出す処理でもEOFはだいぶ遅い方じゃないかな
EOの生成コストがだいぶ大きい印象。ストアドも全体性能からするとあまり性能に寄与する場面ってそう多くないな
Seasar2のO/RMapperは仕事でS2daoというのを使ったけど
EOFほど高機能じゃないがエンジニアの受けは良くて、何しろ軽くトラブルレスだったのが良かったな
386:デフォルトの名無しさん
07/12/13 01:54:24
>>384
>>EOFは実行時もインタプリタだもの。（EOの定義はテキストファイル）
これはどういうこと？eoを生成するたびにモデルファイルを読み込むということなら、いくらなんでもそれはないと思うが。
プロファイルを計測したことはないが、SQL文の組み立てに時間がかかってそうな気はするなあ。
387:デフォルトの名無しさん
07/12/13 10:54:11
>>386
>>eoを生成するたびにモデルファイルを読み込むということなら、いくらなんでもそれはないと思うが。
確かにない。WOFの場合は起動時にモデルファイルを読み込んでEOModelオブジェクトとして保持する。
誰かEOFのベンチたのむｗ
388:デフォルトの名無しさん
08/01/15 22:05:59
保守上げ
389:デフォルトの名無しさん
08/01/20 18:30:38
S2dao より sql2java の方がいいだろ どう考えても