問題タブ [stateful]

私はステートレスプログラミングの利点について疑問に思っていましたが、私の質問を共有している人を見つけました： ステートレスプログラミングの利点は？

しかし、答えを読んでいると、逆の質問に興味を持ちました。ステートフルプログラミングの利点は何ですか？最近はステートレスコードに注目が集まっているようですが、トレンドには警戒しています。

ステートフル（つまり命令型）プログラミングは、ステートレス（つまり関数型）プログラミングよりも特定のシナリオに適しているようです。ステートフルプログラミングで解決できる問題をよりよく認識できるようにしたいと思います。

私は2つの豆を持っています。1 つのステートフルと 1 つのステートレス。ここで、ステートフル Bean からステートレス Bean にあるメソッドを呼び出したいと思います。これどうやってするの？ステートレス Bean にはインターフェースもあります。

Glassfish3.1 でステートフル セッション Bean をインスタンス化する際に問題が発生しています。

JSF アプリケーションの @ManagedBean (セッション スコープ) は、@Stateless セッション Bean の @Local インターフェースを使用していましたが、すべて正常に機能していました。

@Stateful Bean に変換する必要がありましたが、マネージド Bean にステートフル Bean を注入しようとすると例外が発生します。

問題のコードは、次の 3 つのレイヤーで構成されています。

CoreClassEAO は、データベースへのアクセス レイヤーを提示し、次のようになります。

最後のバージョンでは、ShopAdmin と CoreClassEAO の両方が @Stateless Bean の場合、すべてが完全に機能していました。しかし今、ShopAdminInterface を注入すると例外がスローされます

更新: 問題を絞り込みました: @Stateful Bean を別の @Stateful Bean に注入する他の質問を参照してください

Glassfish 3.1 サーバーには、@Stateful別のステートフル セッション Bean に挿入されるセッション Bean があります。

注入されたステートフル セッション Bean は、私のエンティティ アクセス レイヤーを提示します。それ自体に EntityManager が注入されて@PersistenceContextおり、このように見えます。

このアクセス層は、別のステートフル Bean に注入されます。

これはうまくいきました！- しかし、別のコンストラクターを MyEAO に追加するとすぐに、MyEAO を 2 番目の Bean に注入すると、例外が発生して失敗します。

奇妙なことは、両方の Bean@Statelessが過去にセッション Bean であり、まったく問題がなかったことです。

ところで、2 番目のコンストラクターを使用して、glassfish コンテナーの外部で実行される JUnit テストのエンティティ マネージャーを渡しました。

短い: 「ステートレス時代」では、すべてが期待どおりに機能していました!

私は EJB にまったく慣れていないので、ここで何が欠けているのでしょうか?

スタック トレースは次のとおりです。

「セッションスコープのシングルトン」を実装するためのベストプラクティスは何ですか?

他の Bean に「注入/挿入」できる「セッション スコープのシングルトン Bean」が必要@Statefulです。

単に Bean を注入するだけで@Statefulは役に立たないことを学びました。これは、他の Bean がそれぞれ、私の「それほど現実的ではないシングルトン Bean」の異なるインスタンスを取得したためです。アプリケーションスコープのシングルトンではなく、セッションスコープのシングルトンが必要なため、 as アノテーションを@Singleton付けても役に立ちません。

私はそれが非常に一般的な質問に聞こえることを知っていますが、これらの制限（ステートレス）で実行できるかどうかを知りたいステートレスサービスに本当に興味があります。たとえば、Google には多くのサービスがあります。私は、結果を非常に高速に返す必要があり (せいぜい数十ミリ秒)、膨大なデータが散らばっているサービスについてもっと心配しています (おそらく、すぐに要約をどこかに保持しているかもしれません)。これらの場合、「ビジネスロジック」サーバーがステートレスかステートフルかを誰でも判断できますか? ステートレスには、状態をストレージ レイヤー (gfs/memcached/bigtable) に簡単に移動できるという利点がありますが、ステートフルでは、リクエストを同じノードに転送すると、結果が内部メモリからスナップされる可能性があります。この種の巨大なスケーラビリティと巨大なリアルタイムの問題を経験した人はいますか?

それがここでの私の最初の質問であり、私はそれが正しく行われていることを願っています。

Java EEプロジェクトに取り組む必要があるので、始める前に、簡単なことをして、それができるかどうかを確認しようとしています。

ステートフルセッションBeanで立ち往生しています。

質問は次のとおりです。SFSBを使用してユーザーのセッションを追跡するにはどうすればよいですか。私が見たすべての例は、 SFSBをHttpSession属性に「入れる」ことになりました。でも理由がわかりません！つまり、Beanがステートフルである場合、それを維持するためにHttpSessionを使用する必要があるのはなぜですか？

適切なSFSBをクライアントに返すEJBコンテナのタスクではありませんか？

簡単なカウンターBeanで試してみました。セッションを使用しない場合、2つの異なるブラウザに同じカウンターBeanがあります（「インクリメント」をクリックすると、両方の値が変更されます）。セッションを使用すると、ブラウザごとに2つの異なる値があります（Firefoxで「インクリメント」をクリックすると、FirefoxのBeanに1つ追加されます）。

しかし、私の先生は、SFSBは「クライアントとの会話状態」を維持していると言ったのに、なぜHttpSessionを使用せずに機能しないのでしょうか。

私が正しく理解していれば、SFSBでHttpSessionを使用することは、代わりにSLSBで使用することと同じではありませんか？

私の質問が明確であり、私の英語がそれほど貧弱ではないことを願っています！

編集：私はログインシステムに取り組んでいます。すべてがうまくいき、ログインが完了すると、ユーザーのデータを表示するプロファイルページに移動します。しかし、ページをリロードするとデータが消えてしまいます！ロギング中にHttpSessionを追加しようとしましたが、このようにすると、ログアウト後もデータが保持されます。

私はかなりGUIの重いAndroidアプリを開発しています.実行時に動的に構成される小さなウィジェット(テキストフィールド、ボタンなど)がたくさんあります。アプリケーションにフォーカスがあるときはすべてが十分に機能していますが、ユーザーがアプリをバックグラウンドにプッシュして復元すると、すべてのウィジェットが動的な状態を失い、レイアウトで定義されたデフォルトの状態に戻ります。これは Android アプリの適切な動作ですか?

私は他のプラットフォーム (iOS、Windows、Mac) で多数の UI を開発してきましたが、このような動作は見たことがありません。ヒントをいただければ幸いです。

私は現在、基本的に Web サービスからメッセージを受信し、このメッセージの内容に基づいてダウンロード プロセスを開始する新しい EJB アプリケーションを作成しています。このアプリケーションは Glassfish 3.1.1 で動作します。

私の最初のアイデアは、Web サービスからメッセージを読み取り、ステートフル セッション Bean を使用してダウンロード自体を開始および処理するシングルトン Bean を作成することでした。シングルトンとステートフル Bean の間の変換状態 (ダウンロード ステータスなど) が必要なため、ステートフル Bean を使用する必要があります。

「問題」は、Web サービスから複数のメッセージを受信した場合、複数のダウンロードを並行して開始することになっていることです。もちろん、各ダウンロードには独自のコンテキストがあります。シングルトンからステートフル セッション Bean を呼び出す場合、常に同じ Bean を取得するので、どうすればこれを達成できるのでしょうか? 私が見る唯一の解決策は、シングルトンから作成および起動されるスレッドを使用することですが、これは EJB 仕様では許可されていません...

ご協力いただきありがとうございます ！

Lift と Play に関するChris Hagan の回答では、Lift のステートフル性によって実際にコーディングが容易になると述べており、Lift の例を示しています。

}

ステートフルネスの処理における Lift と Play の違いを理解するプロセスを簡素化するために、同じアプリケーション フラグメントを使用した Chris Hagan の Lift の例に対する Play のカウンター例を探しています。