0

Java EE (WebSpere)、JPA、EJB3、JMS (MDB)、JSF というテクノロジー スタックがあります。

アーキテクチャ: JMS メッセージが (MDB 経由で) 到着し、永続エンティティとして登録されます (EntityManager を使用)。これらのエンティティの処理を担当する無限ループを持つシングルトン クラスがあります。Singleton は、MDB によって作成されたエンティティについて通知されます。最初に、エンティティは Singleton 内のキューに格納されます。作成されたエンティティは、最大数分処理できます。同時に処理できるエンティティは一定量までです (Singleton での複数の並列プロセス)。Singleton は EJB ではありませんが、それによって使用される EJB サービスがあります。特定のエンティティ (単純な DTO) の実行コンテキストを表すクラスがあります。

問題は、エンティティの処理が開始されますが、ある時点 (数秒後) で EntityManager が検索要求に対して null を返し始めることです。エンティティが更新されたのはほんの 1 秒前であるため、そうすべきではありません。

アーキテクチャが良くないようです。EM の動作は、MDB とシングルトンの間の対話が行われた後、しばらくして永続化コンテキストがなくなったことを示していると思われます。シングルトンの寿命は、システム内のマネージド Bean の寿命よりもはるかに長くなります。したがって、そのようなコンポーネントへの EJB インスタンス (および EM インスタンス) の注入は、まったく解決策ではないようです (注入された EJB インスタンスへの参照を MDB からシングルトンに渡すことは、おそらく最悪の決定です)。

おそらくEJBとEMは、必要になるたびにJNDIを使用してシングルトンで検索する必要がありますか? この場合、呼び出しごとに EJB をロックアップする必要がありますか?

システムをどのように設計しますか: MDB のみがメッセージを (エンティティとして) 登録した場合。また、エンティティの処理は後で開始される場合があります。また、いくつかの EJB サービス (ローカル インターフェイス) を使用する必要があります。また、Entity Manager もあります。

4

1 に答える 1