JSFのセッションにデータを保存する

Question

私はJ（2）EEとWebアプリケーション開発の世界では初めてですが、その周りを素早くナビゲートし、多くのことを学びます。毎日私にとって新しい発見の素晴らしい航海です。

私は現在、Glassfish v2でVisual JSF Woodstockを使用しているプロジェクトに取り組んでいます。私はJSFもかなり新しいです。

リクエスト間にいくつかのオブジェクト（MyObjectなど）を保存する必要があることがあります。これまでに読んで理解してきたことから、これらのオブジェクトをさまざまな要求の間に保存するためにセッションを使用する必要があります。ここまでは順調ですね。

これを行う方法は、私の懸念がある場所です。 JSPで、クッキーやURLの書き換えや隠れたフォーム変数を使ってクライアント側でオブジェクトを保存するsession.setAttribute("myObj", myObject)を使うことができます。

一方、JSFではセッションスコープのBean、たとえばSessionBean1をSessionBean1プロパティ（例：SessionBean1.setSomeOjb(myObj)）として使用します。これは正しいことですか？

私は、各リクエストがセッションスコープ付きBeanの新しいインスタンス、SessionBean1とSessionBean1内の保存されたmyObjectインスタンスによって利用されるメモリを作成するため、サーバー側でメモリ使用率が向上すると推測しています。

FacesContext.getExternalContext().getSession/getSessionMap()を使用すると、クライアント側でセッション変数を保存できることがわかりました。

セッションのスコープ付きBeanまたはセッションの要求間のアクセスにオブジェクトを保存するセッションマップを使用することをお勧めしますか？

ありがとうございました。

Answer 1

一般に、Java EE Webアプリケーションは、セッションデータのクライアント側を保存するとは思われません。サーバー側のセッションが肥大化するのは当然のことですが、大きなリソースとパフォーマンスの問題を引き起こす大きなセッションフットプリントがあり、特にクラスタ化された環境である可能性があります。

私は私はあなたがFacesContext.getExternalContextを（使用できることを読んだあなたは

を参照してくださいどこ知りたいのですが）。のgetSession/getSessionMap（）クライアント側でセッション変数を保存することになります。

私はあなたが、これは自分自身に戻ってオブジェクトを送信しません同じ

session.setAttribute("myObj", myObject) 

を使用することができた上で、これは単にHttpSessionオブジェクトへのアクセスを与えること（この点について私を修正）と考えていますクライアントは、サーバーに保持され、通常はクッキーに渡されるいくつかのセッション識別子によってキーされます。

これ以外にも2つの方法があります：JSFやJSPからアクセス可能なサーブレットAPIを使用して、独自の製造元のCookieにデータを明示的に入れることができます。フォームを作成し、セッションデータを渡します。

しかし、これを考慮してください。私が使用するApp Serverの経験則では、1k-4kのHttpSessionは問題にならない傾向があります。それより大きく（そして私はセッション数をメガバイト単位で見てきました）、インフラストラクチャに重点を置いています。あなたがそのサイズのセッションを心配していたなら、Cookieや隠されたフィールドにあるメガバイトのデータを毎回ブラウザに送り返すことを期待していますか？おそらく1k-2kも少し大きいでしょう。

ので推奨：

1. はそれをシンプルに保ちます。 Session APIまたはそのJSF表現を使用します。

2. セッション内のデータ量を制御します。

クラスタリングについての質問に応答して追加された：要求が戻って同じクラスタメンバーに送信されるように、一般的に

は、クラスタ環境では、我々は、セッションの親和性を有します。しかし、要求が別のサーバーに送信されたときに、（おそらくクラスター・メンバーが失敗した）場合を検討する必要があります。

いくつかのApp Serverベンダーは、サーバー間の直接通信またはセッションをデータベースに永続化することによってセッション複製を提供します。ここでは間接的にオーバーヘッドが発生するため、失敗の

セッションデータの価値が高い場合は、アプリケーションによって永続化されるべきであり、実際にはビジネスデータであり、そのように扱う必要があるという議論があります。ますます、CloudantやMongoDbなどのNOSQLデータベースがこれに使用されています。この場合、エラーの際にセッションデータを取り出すことができるという知識のもとで、HTTPセッションをキャッシュと考えることができる。

私は、ショッピングカートはビジネスにとってかなりの価値があると主張します。それは彼らがお金を費やしたいものを顧客が思慮深く蓄積したことを表しています。ですから、それは永続化されるべきであり、むしろセッションに保持されるべきです。一度それを維持しようと決めたら、多くのクライアントデバイスで統合された経験など、他の面白いシナリオにつながることがわかります。顧客はデスクトップPCで自宅でショッピングを開始しますが、オンラインで購入を完了します。

したがって、さらなる原則：

3）。そこにあるからといってHTTPセッションを過度に使用しないでください。データのビジネス価値と永続化する必要があるかどうかを検討します。

Answer 2

セッションのスコープ付きBeanまたはセッションの要求間のアクセスにオブジェクトを保存するセッションマップを使用することをお勧めします。

これらの2つのデータは、正確に同じ場所にデータを格納します。一度式で参照

<managed-bean> 
    <managed-bean-class>foo.Bar</managed-bean-class> 
    <managed-bean-name>bar</managed-bean-name> 
    <managed-bean-scope>session</managed-bean-scope> 
</managed-bean> 

、あなたはexternal contextを経由して、プログラムで「bar」をルックアップすることができます。 JSF2に、宣言を除去することができるとの注釈に置き換える：FYI

@ManagedBean(name="bar") @SessionScoped 
public class Bar { 
... 

Answer 3

私は私の同僚と、大学のプロジェクトに取り組んでいますが、GoogleImageラベラーなどのウェブです。 さて、私たちは、ログイン、ログアウトなどのメソッドを持つUserControllerを持っています...

@ManagedBean(name = "userController") 
@SessionScoped 

[OK]これはNetBeansのウィザードが作成するものです。その後、registerメソッドで

（我々はXHTMLでフォームの属性を使用した...）私たちはDB内のユーザーを保持して：

セッションの作成および管理の我々の方法がありますセッションに値を追加します。

FacesContext context = FacesContext.getCurrentInstance(); 
context.getExternalContext().getSessionMap().put("user", current); 

ここで、「現在」はユーザー（もちろんログインしたユーザー）です。 ログイン方法で同じことがあります。私はこれがあなたの役に立てば幸い

FacesContext.getCurrentInstance().getExternalContext().invalidateSession(); 

：私たちが持っているlogoutメソッドで

。