問題タブ [lazy-initialization]

子オブジェクトが参照される直前にセッションが開いているように見えますが、コレクションのセッションの永続コンテキストマップ（org.hibernate.engineStatefulPersistenceContext.collectionEntries）に特定の子オブジェクトセットのレコードがありません（他の子オブジェクトが含まれている場合でも）。

親エンティティと子エンティティの関係は、次のように定義されます。

これがLazyInitializationExceptionをトリガーする理由として考えられるものは何ですか？

あいさつ今日、怠惰な初期化コードを実行していて、null合体演算子を使用してこれを実行しないのはなぜかと思いました。短いですが、この方法で実行するためのオーバーヘッドや追加コストがあると思いました。

以下は、遅延初期化に使用されるより一般的な形式と、null合体演算子を使用する形式を示す簡略化されたサンプルコードです。それらはまったく同じ結果をもたらし、同等に見えます。私の最初の考えは、オブジェクトが作成された後、を使用してそれ自体に追加の割り当てがあるということ??です。これは問題ではなく、コンパイラ/ JITはこれを何らかの方法で最適化しますか、何かもっと悪質なことが起こっているので、で怠惰な初期化を行うべきではありません??。または、完全に安全で、悪いモジョが発生することはありません。

私はJavaメモリモデルのビデオプレゼンテーションを行っていますが、著者はStatic Lazy Initialization比較して使用する方が良いと言っていLazy Initializationますが、彼が何を言いたいのかはっきりとはわかりません。

コミュニティに連絡したかったので、誰かが簡単なJavaコード例Static Lazy Initializationとの違いを説明していただければ幸いです。Lazy Initialization

リファレンス：高度なプログラミングトピック-Javaメモリモデル

Hibernate を使用していますが、アプリで LazyInitializationException に問題があります。この問題はSpringフレームワーク（いくつかの注釈、構成など）で簡単に解決できますが、私はこのフレームワークを知らず、今は学びたくありません（私は初心者です）。

この問題はかなり古いので、 OpenSessioninViewパターンで解決する方法を見つけましたが、もっと簡単な方法があるはずです。

私のアプリは最新のglassfishアプリケーションサーバーで実行されているので知りたいですwhat the typical way to work with lazy initialization in EJB container?

私は持っています：

これは私のサービスです：

私はgwtで私のサービスを使おうとしています：

私は、Hibernate セッションを理解できないもう 1 人の初心者だと思います。Spring の TransactionTemplate かもしれません。これが私の話です。

私はHibernate 3.5.5-Final、Spring 3.0.4.RELEASEを使用しており、注釈のみで生きようとしています(HibernateとSpring MVCの場合)。

私の最初の試みは、適切に設定されたトランザクション マネージャーと組み合わせて @Transactional アノテーションを使用することでした。最初はうまくいったように見えましたが、長い目で見ると (約 36 時間)、何度も "LazyInitializationExceptions" を受け取るようになりました (前の時間には問題なく実行されていた場所から!)。

そのため、Spring TransactionTemplate を使用して手動トランザクションに切り替えました。

基本的に、私は BaseService にこの保護されたもののようなものを持っています

そして、サービスの実装からこのメソッドを使用しても問題なく動作し、LazyInitializationException は 10 日間表示されませんでした (Tomcat をこの単一のアプリで 24*7 で 10 日間実行し、再起動しませんでした) ... しかし、フープよりも! それは再びポップしました:-/

LazyInitializationException は「inTransaction」メソッドの下の場所から発生し、「inTransaction 再帰」は含まれていないため、同じ Hibernate セッションで悲しいことに同じトランザクションにいる必要があると確信しています。関連する「前のセッションからのデータ」はありません（私のコードが行く限り、サービスレイヤーはトランザクションを開き、必要なHibernateからすべてのデータを収集し、それを処理して結果を返します==サービスは他のトップサービスをリコールしません）

私は自分のアプリをプロファイリングしていません (10 日間などの長期実行でそれを適切に行う方法さえ知りません) が、私の唯一の推測は、どこかでメモリ リークが発生しており、JVM がヒープ制限に達していることです... ありますか? SpringまたはHibernat内に含まれるいくつかの「SoftReferences」? 知らない...

もう 1 つの面白い点は、Google GSON シリアライザーを使用して結果を JSON にシリアライズしようとすると、常に例外が発生することです。私はゲッターを使用していないことを知っています...実際のフィールドの代わりにゲッターを使用している独自のパッチを適用したバージョンがあります (そのため、Hibernate プロキシメカニズムをバイパスしないようにしています)。ここで何らかの役割を果たすと思いますか?

最後の面白い点は、例外が常に単一のサービスメソッドで発生していることです (他の場所ではありません)。レイジーフェッチを使用して JSON に)、ハァッ???

何を試すべきか提案はありますか？似たような経験はありませんか？

ありがとう、ヤクブ

pojo class A { B b ; を休止状態にしています。クラスBのlazy = trueを使用した他のいくつかのプロパティ}。オブジェクトAを取得すると、Bはロードされず、休止状態はそのプロキシを返します。このオブジェクトを別のモジュールに渡すと、そのモジュールは A のすべてのオブジェクトをトラバースし、B.getXXX に遭遇すると LazyInitialization 例外をスローします。この特定のケースでは、クラス B は必須ではないため、ロードしたくありません。モジュールが LazyInitialization エラーをスローしないように、B でメソッドを呼び出すときに null を返すか、B のプロキシを実際のオブジェクト B に変換する方法はありますか。クラスBのゲッター、セッターは共通のクラスであり、他の多くのクラスで使用されるため、変更できません。

私が目にする以前の多くの質問のトピックですが、これほどではありません。Hibernates の遅延フェッチ戦略、open-session-in-view などは理解していますが、私の関連付けが何があっても遅延フェッチされる、この単純な小さなことに対する解決策を見つけることができないようです。

私のWebアプリはそれなしで構築されており、現在「移行」するのが複雑になっているため、ビューでオープンセッションを使用していません...

a <- b <- c <- d -> eなどの参照のチェーンがあるとしましょう
。たいていの場合、 a をフェッチすると、 b、c、およびdが必要になります。したがって、これらは常に熱心にフェッチされるように設定されています (lazy=false休止状態のマッピング ファイルで指定することにより)。これは機能します!!

ただし、 d がフェッチされるたびに、関連付けeを常に熱心にフェッチする必要もあります。eはdに対していくつかの論理演算を実行するために重要であるため。

そして、これが機能を停止する場所です... eは、dの多対1の関連付けとしてdに関連付けられています。これを に設定してlazy=falseもうまくいかず、まだ適切に初期化されておらず、dからeのプロパティにアクセスすると LazyInitialisationException が発生します。

これがうまくいくと期待するのは間違っていますか？lazy プロパティは、hibernate v. 3.2.6 および Spring バージョン 2.5.6 を使用して hbm ファイルで指定されます。

誰かが私のために物事を明確にしてくれることを願っています...

是非、別の投稿を見つけたら参考にしてみてください。これをカバーするものが見つからないようです...

私は最近 .Net の Lazy クラスについて学びましたが、おそらくそれを使いすぎています。以下の例では、熱心な方法で評価できた可能性がありますが、何度も呼び出されると同じ計算が繰り返されることになります。この特定の例では、Lazy を使用するコストが利点を正当化しない可能性があります。ラムダと遅延呼び出しがどれほど高価であるかをまだ理解していないため、これについてはわかりません。複雑なロジックを小さな管理しやすいチャンクに分割できるため、チェーン化された Lazy プロパティを使用するのが好きです。また、何かを初期化するのに最適な場所を考える必要もなくなりました。知っておく必要があるのは、使用しない場合は初期化されず、使用を開始する前に一度だけ初期化されるということだけです。しかし、lazy とラムダを使い始めると、単純なクラスがより複雑になりました。これが正当化される時期と、これが複雑さ、読みやすさ、おそらく速度の点でやり過ぎである時期を客観的に判断することはできません。あなたの一般的な推奨事項は何ですか？

シングルトンが次のように実装されている場合、

この実装は、遅延初期化アプローチとどう違うのですか? この場合、クラスがロードされたときにインスタンスが作成され、クラス自体は最初のアクティブな使用時にのみロードされます (たとえば、Singleton.getInstance() は、インスタンス Singleton singleton = null; を宣言するときではありません)。

遅延初期化アプローチでも、インスタンスは getInstance() の呼び出しで作成されます

ここで何か不足していますか？