問題タブ [stateful-session-bean]

ユーザーと、データベースに永続化されたこのユーザーに固有のデータを含む Java EE を使用してアプリケーションを開発する必要があります。私は現在、Java を使用した Web 開発を学んでいるので、ログインしたユーザー ID をステートフル セッション Bean に保持し、これらのデータを更新および取得するメソッドを含むステートレス ビンにこのステートフル ビンを注入することが正しいかどうかを尋ねたいと思います。ステートフル Bean から取得した ID に基づいていますか?

統計または監視にEJB-@Singleton（javax.ejb.Singleton）を使用する必要がありますか、それとも共通の@ SessionScoped-Beanに統計をキャッシュする方がよいでしょうか？私の質問をクリアするために、ここに2つのシナリオがあります。

シナリオI：

ユーザーはWebセッションを開始し、統計またはデータテーブルを表示するためにデータベースクエリを実行します。これらのクエリは、そのセッション内で実行されます。したがって、10.000ユーザーは10.000の等しいデータベースクエリを作成します。

シナリオII：

ユーザーはWebセッションを開始し、事前に初期化された@Singleton-Beanから統計またはデータテーブルのデータを再試行します。@Singleton（javax.ejb.Singleton）は、Server-Startup（@Startup）の開始時にクエリを実行しました。したがって、10.000ユーザーは1つのキャッシュ（@Singleton）から読み取ることができ、データベースにクエリを実行する必要はありません。私の@Singleton-Beanは、他の誰かがデータを作成/編集/削除した場合に、キャッシュされたデータの更新をトリガーします。

だから私の質問は：

• シナリオIIはシナリオIよりもスケーリングが優れていますか？はい、そうですね。私は正しいですか？
• 他に考慮すべき注意事項や事柄はありますか？
• Stateless-Beansは、@statefulや@Singletonよりもはるかにスケールアウトします。@ Stateless-Beanを使用して、JPA /HibernateCachesなどでクエリをキャッシュすることを検討する必要があります。
• プロキシを使用するには、@ Singleton（javax.ejb.Singleton）の代わりに@ApplicationScoped（javax.enterprise.context）を使用する必要がありますか？それはもっと良いでしょうか？

Stateful Session Beanログイン セッションを保持するとJSF Session BeanがありServlet Filterます。

私がしなければならないことは、ログインしていないユーザーが自分のページにアクセスできないようにすることです。そのため、フィルターをかけました。

そのdoFilter()ようなもの：

whereuserManagerは で見つかります:

現在、System.out.println(userManager.isLogged());出力は常にfalse ですが、#{loginBean.logged}出力は true です。

loginBean.loggedちょうどであることに注意してください

そして、私の管理対象 Bean では、次のようuserManagerに取得されます

サーブレットは JSF Managed Bean と同じ SFSB を使用していないようです。

私は何を間違っていますか？

編集: 新しいコード

サーブレット

jsf ビーン

@StatefulEJB（3.x）では、Session Beans：および。を選択できます@Stateless。これらの2つのオプションの背後にある基本を理解している場合：

• @Stateful-各ユーザー/クライアントは独自のものを取得するため、通常はプールされません。複数のリクエストにわたって状態を維持します
• @Stateless-リクエスト間の状態を維持しないため、通常はプールされるため、新しいクライアントリクエストごとに新しいBeanが取得されます

ここでの私の中心的な質問は非常に単純ですが、それに接するいくつかのミニ質問があります。私のPOJOデザインはBeanとBeanでどのように異なりますか？@Stateful@Statelessつまり、インターフェイスHelloWorldを実装するBeanがある場合Hello、そのPOJOのデザインは、ステートフルにするかどうかによってどのように変化しますか？

これに接する：

• アプリコンテナ（私の場合はGlassFish）は、ステートフルであるかどうかに応じて、EJBにどのような異なる制限を課しますか？
• の場合@Stateful、同じユーザー/クライアントからのクライアント側のリクエストは、どのようにして正しいBean（前のリクエストからのクライアントの状態を維持しているBean）にマップされますか？
• セッションBeanはいつ死にますか？のリクエストが行われた直後だと思います@Statelessが、の手がかりはありません@Stateful。

ここで明確にしてくれてありがとう。

ステートフルセッションBeanは、多くの場合、ショッピングカートを実装することで示されます。Java EEの外部から来たので、私の傾向は、永続的なモデルエンティティ（Productsとquantitiesを持つShoppingCartオブジェクト）を使用してこの種の状態を処理することです。このように、私の状態は、アプリケーションサーバーではなく、他のすべての状態とともにデータベースによって維持されます。

「通常の」永続性に対するステートフルセッションBean設計の技術的な利点は何ですか？Java EEベースのWebアプリケーションのショッピングカートは、実際には通常SFSBで作成されていますか、それとも他のシステムのように、より複雑なドメインモデリングによって作成されていますか？

認証モジュールとして機能するステートフルセッションBean（SFSB）があります。SFSBには、ログインしている現在のユーザーを格納します。さらに、エンティティのJPA / SQLを処理するファサード（ステートレスセッションBean（SLSB））がいくつかあります。現在のユーザーのアクセス許可を確認するために、SLSBからSFSBを呼び出そうとします。ただし、SLSBから呼び出された場合、現在のユーザーフィールドは常に「null」です。SFSBを直接呼び出す場合、現在のユーザーフィールドが正しく設定されています...呼び出しには、@EJBアノテーションを使用します。

問題が何であるかについて何か考えはありますか？それはどういうわけか文脈の問題ですか？SLSBからSFSBを呼び出して、その状態を維持することは一般的に可能ですか？

よろしくお願いします！

私たちの問題は、JSF + EJB を使用してデータベースを編集するための非常に基本的で単純な実装です。

簡単に言うと、2 つの別個の XHTML ビューで、2 つの別個のマネージド Bean @RequestScope を使用します。

WebuserListBean と EditWebuserBean、および @ManagedProperty を使用して WebuserListBean を注入し、選択したユーザー データを取得できるようにします。これまでのところ問題はありません。ビューにデータが正常に入力されました!

しかし！ユーザーを編集できるようにしたい！そしてここで（驚いたことに）、この問題を克服することはできません。

最初の試行: ビューを埋めた後にリクエスト スコープ Bean が停止しているため、Save() メソッドで @PostConstruct が再度起動しようとしますが、もちろんできません。そのため、データベースなどから取得することさえできませんでした。

2 回目の試行: リクエスト スコープ Bean はビューを埋めた後に死んでいるため、@postconstruct でユーザーをフィールドとして設定しないと、前のビューにリンクされていた (そして注入されたが、現在そのビューはあまりにも死んでいる）。

3 回目の試行: ViewScoped に RequestScope を挿入できない

わかりました、そして私たちの制限は、それが間違っていると思うからです:

1. このために SessionScoped Managed Bean を作成したくありません
2. パラメータなどを使用したくない.EJBを使用したい
3. モジュールのエンドポイントであるステートフル セッション Bean にデータを格納できるかどうかわかりません。適切なアプローチですか？

アドバイスありがとうございます。コードを貼り付けることができますが、それは無意味だと思います! 乾杯！

私の @SessionScoped WorkflowManager マネージド Bean は、セッションがタイムアウトしたときに状態をリセットでき、ウェルカム スプラッシュ画面が表示されました。@Stateful を WorkflowManager に追加した後、ウェルカム画面が一貫して表示されず、server.log を見ると、一貫した方法でセッションが実際に適切にタイムアウトしていないようです。セッション タイムアウト後にブラウザがリクエストを行うと、ViewExpiredExceptionHandler がスプラッシュ スクリーンにリダイレクトされることになっています。代わりに、次のスタック トレースと警告が表示されます。

セッションがタイムアウトした後、WorkflowManager は破棄され、クライアントからの次のリクエストによって新しい WorkflowManager が作成されます。これは、WorkflowManager がマネージド Bean であったときに正常に機能した方法です。では、JBoss が以前に破棄された WorkflowManager を復元しようとするのはなぜでしょうか? これを解決するにはどうすればよいですか?

編集：

Java EEアプリケーションにフィルターを追加しようとしていますが、いくつかの問題が発生しています。

ログインの目的でフィルターを使用したいので、ログインを管理するUserManagerBeanと「通信」させる必要があります。

これが私の構造です：

• LoginFilter：ServletFilter
• LoginBean：SessionScopedマネージドBean
• UserManager：ステートフルセッションBean

UserManagerには、ログインプロセスを処理するメソッドがあるため、 LoginFilterとLoginBeanの両方からアクセスする必要があります。

LoginBeanにいる間、次の単純な行でUserManagerを取得します。

LoginFilterでそれを行うことができないため、ルックアップメソッドを作成する必要がありました。

このUserManagerLocalをリクエスト属性に追加する行もありましたが、lookupメソッドを呼び出すときにリクエストがないため、NPEがスローされるため、doFilter（）メソッドに移動しました。

ここで問題が発生します。

LoginFilterとLoginBeanは、UserManagerの2つの異なるインスタンスを使用します。LoginBeanはUserManagerの別のインスタンスで機能し、 LoginFilterはログインが完了したことを認識しないため、これにより、ログインしているユーザーでもフィルターが停止します。

どうすれば修正できますか？ルックアップとインジェクションはSSFBの同じインスタンスを返すと思いました！

私はステートフルな EJB を持っており、それにアプリケーション スコープの CDI Bean を注入しました。私の CDI Bean はシリアライズ可能ではなかったため、Findbugs は警告を出しました。この場合、CDI Bean をシリアライズ可能にする必要がありますか? 私の意見では、パッシベーションを避けるためにそうすべきではありません。このフィールドを「一時的」にすることは十分ですか?これは適切な解決策ですか?