sessionscopedマネージドBeanとステートフルejb

Question

@ManagedBeanが@SessionScopedの場合、なぜ@Stateful EJBを使用しますか？以前はショッピングカートや会話型の状態を維持していましたが、管理されたBeanはユーザーセッション中に保持されるため、そこで状態を保存してから、bussinessロジック用にSLSBを呼び出してください。あれは正しいですか？そうであれば、トランザクションなどが必要なときなど、より具体的なアプリケーションのためにステートフルなejbが残されますか？

Answer 1

多くの場合、ステートレスセッションBeanは、多くのビジネス上の問題に使用できます。

ステートフルは、リモートサーバが状態を保持することを必ずしも意味しませんが、これは確かにオプションの1つです。リモートのSwingクライアントは、最初にステートフルセッションBeanに一連のデータを送信し、スタブを保持した後、このデータで動作するコマンドを送信することができます。これにより、クライアントは毎回同じ（大量の）データを送信する必要がなくなります。

リモート・ユースのケースでは、Webクライアント（ブラウザ）を使用すると、実際にはHTTPセッションの使用がミラーリングされます。主な相違点は、セッションはここではBeanごとですが、HTTPセッションではセッションは多くのBeanによって共有されるスコープです。 HTTPセッションはCookieに基づいており、ブラウザ全体のドメインに対してCookieがグローバルなので、HTTPセッションは同じクライアントから複数のセッションを直接サポートすることはできません（タブ単位またはウィンドウ単位など）。これは、ステートフルセッションBeanでは簡単です。

しかし...

リモートEJBと通信するリモートスイングクライアントはあまり一般的ではありません。

あなたの質問で説明したコンテキストでは、通常はローカルEJBを使用し、HTTPセッション（共有には注意してください）にほとんどの状態を保存し、最近はビュースコープまたは会話スコープで保存します。

最後に、このシナリオでステートフルセッションBeanを使用する場合はいつですか？

重要な使用例の1つはextended persistence contextで、JPAです。通常、トランザクションスコープのエンティティマネージャでは、エンティティがEJBメソッド呼び出しのトランザクション境界を越えると、エンティティマネージャはデタッチされます。ユーザーのやりとりの間でエンティティを（楽観的に）ロックしたい場合、これは望ましくありません。あなたはロックを失います。

拡張永続コンテキストでは、ステートフルセッションBeanへの呼び出しから戻るときに、エンティティはアタッチされたままで、ロックは有効です。これは、プレビュー後に大丈夫なときに他の誰もエンティティを変更していないことを確認するプレビュー機能に非常に便利です。または実際にカート内で商品を他の誰かに売ることができないことを保証したいショッピングカートの場合。