問題タブ [stateless-session-bean]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
jakarta-ee - ステートレス セッション Bean よりもステートフル セッション Bean を使用する場合は?
ステートフル セッション Bean は次のように定義されます。
ステートフル セッション Bean オブジェクトの状態は、そのインスタンス変数の値で構成されます。ステートフル セッション Bean では、インスタンス変数は一意のクライアント Bean セッションの状態を表します。クライアントはその Bean と対話 (「対話」) するため、この状態は多くの場合、会話状態と呼ばれます。
ステートレス セッション Bean は次のように定義されます。
ステートレス セッション Bean ステートレス セッション Bean は、クライアントとの会話状態を維持しません。クライアントがステートレス Bean のメソッドを呼び出すと、Bean のインスタンス変数には、そのクライアントに固有の状態が含まれる場合がありますが、呼び出しの間だけです。メソッドが終了すると、クライアント固有の状態は保持されません。ただし、クライアントは、プールされたステートレス Bean のインスタンス変数の状態を変更することができ、この状態は、プールされたステートレス Bean の次の呼び出しまで保持されます。メソッドの呼び出し中を除いて、ステートレス Bean のすべてのインスタンスは同等であるため、EJB コンテナはインスタンスを任意のクライアントに割り当てることができます。つまり、ステートレス セッション Bean の状態は、すべてのクライアントに適用される必要があります。
ステートフル セッション Bean よりもステートレス セッション Bean を使用する利点は次のとおりです。
ステートレス セッション Bean は複数のクライアントをサポートできるため、多数のクライアントを必要とするアプリケーションのスケーラビリティが向上します。通常、アプリケーションは、同じ数のクライアントをサポートするために、ステートフル セッション Bean よりも少ないステートレス セッション Bean を必要とします。
頭に浮かぶ疑問は、いつステートフル セッション Bean を使用する必要があるかということです。この問題についての私の素朴な理解では、できる限りステートレス セッション Bean を使用することに固執する必要があります。
ステートフル セッション Bean を使用する候補は何ですか? 良い例はありますか?
multithreading - 異なるスレッドは、ステートレス EJB の特定のインスタンスの異なるメソッドにアクセスできますか?
の特定のインスタンスを考えてみましょうMyBean1
。次に、複数のスレッドが同時にアクセスできないことがわかりmethod1()
ます。method2()
しかし、method1()
スレッドによってアクセスされている間method2()
、別のスレッドからアクセスできますか?
jakarta-ee - リモート セッション Bean を介して DTO/DAO サービス バックエンドに渡されるパラメータ
私はJavaEEでの開発に比較的慣れていません。オブジェクトの作成または削除の呼び出しのためにパラメーターをセッション Bean に渡すという点で、最適な形式は何か疑問に思っています。
私のバックエンドでは、DAO で DTO を使用して、データベースで作成、更新、削除、および読み取り操作を実行します。
私は単純なDAOインターフェースを持っています:
BusinessDAO
(この段階での実装は無関係だと思います)
私の実際の質問に進みます-リモート(ステートレスセッションBean)EJBインターフェースがある場合、リモートEJBインターフェース内にメソッドを定義する必要があります:
または、次のようなもの:
これらのメソッドのいずれかを呼び出す単純なクライアント プログラムがあります。
私の考えでは、オブジェクトの作成についてはBusinessObject bo
定義の方がうまくいくと思いますが、リモート インターフェイスの他の定義について従うことができるパターンがあるようです。
次のようなものに同じスタイルのメソッド定義を組み込む方法がわかりませんfindObject(BusinessObject bo)
を作成し、そのオブジェクトの ID フィールドのみを提供する標準的な方法はありBusinessObject
ますか?DAO 実装は、(セッション Bean を介して) 入力されたオブジェクトをクライアントに返しますか?
それとも、代わりに をメソッドに渡して、単に を返すほうがよいint id
でしょfindObject
うBusinessObject
か?
jakarta-ee - EJB は各ビジネス メソッド呼び出しの前にすべての依存関係を再注入しました
この質問は疑いではなく、実はヒントです。
各ビジネス メソッド呼び出しの前に、セッション EJB がすべての依存関係を再注入することをご存知でしたか? ええと、数分前まで知らなかったので、頭が痛くなりました。
依存性注入はインスタンスの作成時にのみ発生すると思っていましたが、そうではありません。EJB 3.1 の仕様には次のように書かれています。
「セッション Bean が依存性注入を利用する場合、コンテナーは、Bean インスタンスが作成された後、Bean インスタンスでビジネス メソッドが呼び出される前に、これらの参照を注入します。」セクション 4.3.2
どういうわけか、この定義は Stateless Session Bean に会話状態を持つ能力を与えることができます。それはまさに私が必要としていたものです。たとえば、SLSB に @SessionScoped Bean を注入すると、プールのどのインスタンスがリクエストを処理するかに関係なく、SessionScoped Bean は常に現在のクライアントのセッションに準拠します。つまり、SLSB インスタンスが別のクライアントの SessionScoped Bean を持つ可能性はありません。
これにより、2 人のユーザーが SLSB の同じインスタンスを交互に使用する場合に、SLSB が @Inject を介してログに記録されたユーザーをインスタンス フィールドとして受け取ることができます。例えば:
次に、「test」メソッドのさまざまな呼び出しの結果は次のとおりです。
同じインスタンスを呼び出しても、フィールド「loggedInUser」はメソッドを呼び出したユーザーによって正しく異なることに注意してください。
stateless-session-bean - ShoppingCart をステートフル セッション Bean として使用する理由
ステートフル セッション Bean を使用する典型的な例の 1 つは、ShoppingCart の例です。ShoppingCart クラスの Bean インスタンスを作成し、このインスタンスを HttpSession 内に格納します。ただし、通常の Java クラス (またはステートレス セッション Bean) である ShoppingCart クラスを使用すると、同じことが簡単に実現できます。商品を追加するリクエストが来たら、cart オブジェクトを作成し、その cart オブジェクトを HttpSession 内に配置します。
したがって、ここでステートフル セッション Bean の ShoppingCart を使用する意味がわかりません。一般に、ステートフル セッション Bean は重要な役割を果たしているようには見えません。
java - スレッドからセッション Bean を呼び出すときの NullPointerException
簡単な運動プログラムに問題があります。スレッドからSession Beanを呼び出したいのですが、NullPointer例外になってしまいます!しかし、メインスレッドから呼び出すと、正常に実行できます
これは警告と例外です
これは、リモート セッション Bean を呼び出す実行可能なクラスです。
これが私の主な機能です
これがセッションビーンです