2008-02-01
サイオステクノロジーはグルージェントの未来技術に期待し子会社化 サイオースラボみたいな感じかしら。どこかで聞いたような語感ですね。(笑) Seasar2 と Teeda を利用した Web アプリケーションを WebSphere Application Server にデプロイする developerWorksにTeedaをWASにデプロイするための記事が出てます。今後は、定期的にdeveloperWorksに記事を掲載していく予定です。こんなのを書いてほしいとか要望があれば、遠慮なくどうぞ。書くのは私じゃないかもしれないけど(笑)。 「抽象クラスを継承してエンティティ特有のビジネスロジックを実装する」ってことは、そのエンティティは貧血でないドメインオブジェクトってことでしょうか。 SAStrutsの機能リファレンスでは「複数のアクションから共通に使われるような機能は、サービスクラスで実装
S2JDBC & Hibernateベンチマークの感想 - ひがやすを技術ブログ
Hibernateは永続コンテキストを管理することがかかるので、大体S2JDBCの2倍前後処理時間がかかりますね。 永続コンテキストの一番の目的は、透過的な更新ですが、これが本当に有効かどうかは疑問です。一見便利に見えるんだけど、裏で勝手に更新されるので、それに振り回されちゃうケースが多いのではないでしょうか。特に関連とCASCADEが絡むとさらに事情を難しくします。 永続コンテキストとエンティティの状態は表裏一体ですが、エンティティの状態遷移に悩まされた人も多いはず。 結局、永続コンテキストは、ちょっと楽をしようとして、多くの複雑性とパフォーマンスの低下をもたらしていると思います。 S2JDBCは、「トラブリにくくする」というテーマがあるので、永続コンテキストは仕様に含めていません。思わぬSQL文が発行されることはなく、開発者が呼び出したクエリしか実行しません。 永続コンテキストのオーバ
S2JDBC & Hibernateベンチマーク その3 - ひがやすを技術ブログ
ManyToOneのfetch joinでは、HibernateがS2JDBCの1.6倍、OneToManyのfetch joinは、HibernateがS2JDBCの1.8倍ほど時間がかかっています。これは大体予想通り。 次は、10000件のうち最後の100件をページングで取得する場合です。HibernateがS2JDBCの2倍ほど時間がかかっています。これも大体予想通り。 次は、10000件の挿入。Hibernateはバッチ更新をするようになっているので、S2JDBCもそれにあわせます。結果は、Hibernateがだいたい2.3倍くらい時間がかかっています。まぁ、予想通り。 次は、10000件の更新。Hibernateが12倍くらい時間がかかっています。Hibernateの時間がかかっているのは、永続コンテキストに格納されているエンティティが更新されているのかをチェックしているためです
S2JDBC & Hibernateベンチマーク その2 - ひがやすを技術ブログ
今度は、Addressを10000件取得してみます。Addressは、EmployeeとOneToOneの関連があり、外部キーを持たない非所有者側のエンティティです。 S2JDBC(0.453489233) 0.454608859 0.451351731 0.454507110 Hibernate(26.278606800) 26.353926022 26.258951969 26.222942410 Hibernateは、S2JDBCより約58倍時間がかかっています。HibernateはOneToOneの非所有者側のエンティティを取得するのは苦手です。10001回のSQLを発行してしまうのです。 下記のSQLは最初に1回発行されます。 select address0_.ADDRESS_ID as ADDRESS1_1_, address0_.STREET as STREET1_, add
2007-10-29 - ひがやすを blog - ERモデルとドメインモデル
エンティティのマッピングで、S2JDBCがJPAと違っているところは、外部キーのプロパティを必要とすることです。 これは、S2JDBCとJPAの根本的なモデリングに対する考えの違いからきています。 S2JDBCは、ERモデルをエンティティに忠実に反映させるという考えです。だから、テーブルのカラムは、エンティティと一対一に対応させます。 それに対しJPAは、ドメインモデルとERモデルを別途作成し、それをO/R Mappingしていきます。重要なのは、ドメインモデルなので、ドメインモデル上必要のない、外部キーに対するプロパティはいらないのです。 どっちがいいのかは、好みの問題ですが、個人的には、ドメインモデルとERモデルという、似てそうで、分析手法が違う2つのモデルを作成するより、ERモデル1つの設計で済ませるほうが楽なので好みです。 データの入れ物にRDBMSを使っているんだから、RDBMS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
