[jpa:6] Re: Hibernate EntityManagerの使用感想

[Koichi Kobayashi]

小林 (koichik) です．

Date:    Wed, 18 Apr 2007 02:27:08 +0900
From:    Hidenoshin Yoshida <[E-MAIL ADDRESS DELETED]>
To:       [E-MAIL ADDRESS DELETED]
Subject: [jpa:4] Re: Hibernate EntityManagerの使用感想

> 仕事でHibernate EntityManagerを使っていますので、
> まずはそのお話をしてみようかなと思います。

ありがとうございます！！

> 最初に大きく悩んだのは、Hibernateの双方向１対１の挙動の問題でした。
> 小林さんが書かれたJava ExpertのJPA特集の中でも詳しく書かれてありましたが
> 単純に１対１の定義をしたらLAZYロードが無効になってしまい
> 一覧取得等で凄まじい量のQueryが発行されてしまってかなり困りました。

これはビックリしますよね．
当方では再帰的な関連のあるテーブルでこれに該当
してしまい，途方もない量の SQL が延々と
発行されるという状況になりました．．．

これは Hibernate の遅延ロードが

1．対 1 関連を「関連先」エンティティの
   Proxy として表す．
2．Proxy はインスタンス生成時に主キーが必要．

ということと，Hibernate 自身がイベントドリブンな
実装になっていることから来ているもので，抜本的な
対応は難しそうだなぁと感じています．

この辺りは「関連元」のクラスをエンハンスして，
関連にアクセスされた際にフェッチする TopLink の
実装の方が好ましいように思えますね．

> 例えば、Entityではない普通のBeanを戻り値として望む場合、JPQLなら
> SELECT new 句を使うと思いますが、これがSQLだと、戻り値がObject配列に
> なってしまいます。

JPA でも Native Query の結果を非エンティティに
マッピングする方法が決められていますが，かなり
面倒なのでなかなか使う気がしませんよね．
エンティティにマッピングするならそこまで面倒でも
ないのですが．．．
そもそもエンティティではない結果が欲しい場合にこそ
複雑な問い合わせが必要になって JPQL では無理な場合が
多いわけで，Native Query から非エンティティへの
マッピングが面倒なのは次期 JPA では改善して欲しい
ポイントの一つですね．

> 最後に、色々悩んだのが排他制御でした。

ここは悩みどころですね．

> 結局、Entityを一旦Sessionに保存し、mergeを使ってUPDATEする方法に
> 落ち着かせました。

一応，これが一番ベーシックなやり方ということに
なるのかもしれませんね．

自分は merge を使わず，主キーとバージョン番号指定で
SELECT し直す方が好きです．
その時に FOR UPDATE を付ける標準的な方法があると
いいのですが，今の JPA 仕様ではないですよね？
TopLink はヒントで指定できるらしいですが，これは
仕様として必須ではないかなぁ．

> この部分については、JPAでのベストな手段はどうなのか
> 未だによくわかっていません。ただ、個人的には
> ExtendedなEntityManagerはシステムの複雑性が増す気がするので
> あまり第一には考えたくないと思っています。

同意です．
ユーザ数が増えた場合のメモリの消費量も
気になりますし．．．

この点，SFSB + Extended Persistence Context を
活用してるらしい JBoss Seam を使ってる人がいれば
感想を聞いてみたいですね．


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