問題タブ [stateless-session-bean]

JavaのステートレスBeanは、クライアントからの2つの呼び出しの間で状態を保持しません。つまり、一言で言えば、それらをビジネスメソッドを持つオブジェクトと見なすことができます。各メソッドはパラメーターを受け取り、結果を返します。メソッドが呼び出されると、いくつかのローカル変数が実行スタックに作成されます。メソッドが戻ると、ローカルはスタックから削除され、一時オブジェクトが割り当てられている場合は、とにかくガベージコレクションされます。

私の見解では、同じ単一インスタンスのメソッドを別々のスレッドで呼び出すのと同じです。では、なぜコンテナは、多数のBeanをプールする代わりに、Beanの1つのインスタンスを使用できないのでしょうか。

私はEJB3（アプリとWebサービスレイヤーの場合はHibernate + Glassfish、WebUIの場合はLifton Glassfish）を使用してJavaで多層金融処理アプリケーションを開発中です。私のビジネスロジックを置きます。

このプロジェクトが開始されたとき、私たちの最初の概念は、ビジネスロジックの大部分をステートレスセッションBeanに入れることでした。ただし、時間が経つにつれて、EJBフレームワークによって提供される依存性注入が制限されすぎることがわかりました。そのため、ビジネスロジックの多くは、ステートレスセッションBeanの@PostConstructメソッドでGuiceによってアセンブルされるPOJOになりました。 。この進歩により、セッションBeanとPOJOの間のビジネスロジックが断片化されました。私は、これを修正するためのアプローチを見つけようとしています。

最初に、Web層でセッションBeanのリモートインターフェイスを使用して、UIとWebサービスレイヤーの両方からアクセスできるいくつかの機能を実行しようとしました。これは、@WebService注釈付きのステートレスセッションBeanによって提供されます。これは、永続性とパフォーマンスの観点からは悪夢であることが判明しました。エンティティグラフが非常に大きくなる可能性があり、分離されたエンティティグラフを永続性コンテキストに再アタッチするとエラーが発生しやすいことが判明したため、ソリューションはオブジェクトの受け渡しを開始することでした。必要な場所でデータベースからエンティティを検索します。

私の基本的な質問はこれです：ビジネスロジックをセッションBeanとPOJOのどちらにするかを決定するために、どのような原則とガイドラインを提案できますか？複雑なオブジェクトグラフがある場合、エンティティBeanを渡すことが理にかなっているのはいつですか。

EJB 2.1 セッションおよびエンティティ Bean を使用する J2EE 1.3 アプリケーションがあります。現在、このアプリは JBoss で EAR ファイルとして実行されます。OSGi が提供するすべての利点のために、SpringSource dm Application Server に切り替えたいと考えています。

EJB コンテナーとして機能する OSGi バンドルがあるかどうかは誰にもわかりませんか? OpenEJBはこれを行うことができますか?

J2SE アプリケーションからリモート ステートレス セッション Bean を呼び出しており、ルックアップのコストを削減するためにセッション Bean への参照をキャッシュしたいと考えています。これでよろしいですか？

EJB2 では ServiceLocator パターンを使用してリモート リソースへのルックアップをキャッシュするのが一般的でしたが、EJB3 には個別の EJB ホーム (通常はキャッシュされていた) とリモート オブジェクトがありません。

これに対する一般的な答えは、EJB3 インジェクションを使用することですが、J2SE クライアントからリモート EJB サーバーへの呼び出しを行っているため、インジェクションを使用できません。

かなり前に作成された、かなりの数のEJB2ステートレスセッションBeanを含むプロジェクトがあります。これらは、RMIを介してクライアントからアクセスされる最初の行のBeanではなく、特定の機能を実行するためにそのコードによって使用されます。しかし、セッションBeanとして使用しても何も得られないと思うようになりました。

• RMIを介してアクセスする必要はありません。
• それらは状態を保持しません。それらは、複雑さを軽減するために最初のBeanセットから除外されたコードにすぎません。
• それらには、私たちが交換している複数の異なる実装がありません。それぞれが何年もの間そうであったようです（バグ修正と機能追加を除いて）。
• それらのいずれも、それらを呼び出すBeanから入ってくるトランザクションを変更しません（つまり、新しいトランザクションを必要としない、既存のトランザクションに参加しない、またはその他の方法で変更する必要はありません）。

なぜこれらすべてが、いくつかの静的関数を持ち、EJBトラップがまったくないクラスである必要がないのですか？

EJB 2.1 SLSB として実装された使用頻度の高いサービス オブジェクトを想像してみてください。これは、まったく状態を持たないため、たまたまそれ自体がスレッド セーフになっています。すべてのパブリック メソッドは (CMT を介して) トランザクションに対応しており、ほとんどは単純にトランザクションを必要としますが、新しいトランザクションを必要とするものもあります。

この SLSB を本物のシングルトン POJO に変換すると (DI フレームワークなどを使用して)、アプリケーションのスケーラビリティにどのような影響がありますか? サービスが SLSB の場合、EJB コンテナーはインスタンスのプールを管理し、そこから各クライアントが独自のコピーを取得するため、それをシングルトン POJO にすると、その単一インスタンスに何らかの競合が発生するのではないかと考えています。

FWIW、このサービスのメソッドはどれもsynchronized.

明確化: SLSB を POJO に変換する私の動機は、オブジェクトのライフサイクル (真のシングルトンとコンテナー管理) とコード自体 (1 つのインターフェースと 1 つの注釈付き POJO に対して、3 つのインターフェース、1 つの Bean クラス、および束) の両方の単純さです。 XML の ejb-jar.xml 内)。

また、FWIW、問題のサービスは、JBoss 3.x で実行されているコロケーションされた Web アプリの 1 つのコンポーネントです。

次のように定義された EJB があります。

Weblogic (WL) にデプロイされると、myBean という名前が付けられます。これが重要かどうかはわかりません。

このコードで Bean を呼び出そうとします:

次のエラーが発生する理由を知っている人はいますか?

1つのパブリックメソッド、いくつかのプライベートメソッド、およびいくつかのインスタンスレベル変数を含むステートレスセッションBeanがあります。以下は擬似コードの例です。

私が見ているのは、methodBがMethodAに渡されなかった値を出力しているということです。最善の方法として、同じBeanの他のインスタンスからの値を出力していることがわかります。これは何が原因でしょうか？

コードは99.9％の確率で期待どおりに機能することを指摘しておく必要があります。しかし、.01％は私にとっていくつかの深刻な問題/懸念を引き起こしています。

パブリックメソッドが異なると、呼び出し間で同じBeanが返されない可能性があり、その結果、この動作が発生する可能性があることを理解しています。ただし、この場合、唯一の呼び出しは単一のパブリックメソッドへの呼び出しです。コンテナ（この場合はGlassfish）は、プライベートメソッド呼び出し間でBeanを交換しますか？

（編集）混乱を引き起こしていたため、「クラスレベル」の名前を「インスタンスレベル」に変更しました。

通常、ビジネス/dao レイヤーにはシングルトン インスタンスを使用します。EJB の場合にステートレス セッション Bean をプールする理由は何ですか?