Oracle® Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発 11g リリース 1 (10.3.1) B55521-01 |
|
![]() 戻る |
![]() 次へ |
この章では、セッションとセッションの永続性を設定および使用する方法について説明します。
セッション トラッキングを使用すると、複数のサーブレットか HTML ページにわたって、本来はステートレスであるユーザの状況を追跡できます。セッションとは、ある期間中に同じクライアントから出される一連の関連性のあるブラウザ要求のことです。セッション トラッキングは、ショッピング カート アプリケーションのように、全体として何らかの意味を持つ一連のブラウザ要求 (これをページと見なす) を結合します。
WebLogic Server は、デフォルトによってセッション トラッキングを処理するよう設定されています。セッション トラッキングを使用する際にプロパティを設定する必要はありません。ただし、WebLogic Server がどのようにセッションを管理するかをコンフィグレーションすることは、最高のパフォーマンスを実現するためにアプリケーションをチューニングするときの重要な鍵となります。セッション管理を設定するときは、次のような要素を決定します。
サーブレットをヒットする予定ユーザ数
各セッションの継続時間
各ユーザに対する予定格納データ量
WebLogic Server インスタンスに割り当てられるヒープ サイズ
HTTP セッションのデータを永続的に格納することもできます。「セッションの永続性のコンフィグレーション」を参照してください。
WebLogic Server のセッション トラッキングは、WebLogic 固有のデプロイメント記述子である weblogic.xml
にプロパティを定義することによってコンフィグレーションします。セッション属性の全リストについては、「session-descriptor」を参照してください。
以前のリリースの WebLogic Server では、SessionID の形式が変更されたことで、ロード バランサがセッションの固定を保持できなくなっていました。サーバ起動フラグ (-Dweblogic.servlet.useExtendedSessionFormat=true
) に、ロード バランシング アプリケーションがセッションを固定するために必要な情報が保持されるようになりました。URL の書き換えがアクティブになっていると、拡張されたセッション ID の形式は URL の一部になり、起動フラグが true に設定されます。
HTTP セッションが期限切れになるまでの間隔を指定できます。セッションが期限切れになると、そのセッションに格納されたデータは破棄されます。この間隔は、次のとおり web.xml
または weblogic.xml
に設定できます。
WebLogic 固有のデプロイメント記述子である weblogic.xml
の session-descriptor
要素の timeout-secs
パラメータ値を設定する。この値は秒単位で設定します。詳細については、「session-descriptor」を参照してください。
J2EE 標準 Web アプリケーション デプロイメント記述子 web.xml
で session-timeout
要素を設定する。
WebLogic Server は、クッキーがクライアント ブラウザによってサポートされる場合、クッキーを使用してセッション管理を行います。
WebLogic Server がセッション トラッキングに使用するクッキーは、デフォルトによって一時的なものとして設定されているため、セッションより長く存続することはありません。ユーザがブラウザを終了すると、クッキーは失われ、セッションが終了します。この動作はセッションの用途の基本であり、このようにセッションを使用することをお勧めします。
クッキーのセッション トラッキング パラメータは、WebLogic 固有のデプロイメント記述子である weblogic.xml
でコンフィグレーションできます。セッションとクッキーに関連するパラメータの全リストについては、「session-descriptor」を参照してください。
長時間存続するクライアントサイド ユーザ データの場合、WebLogic Server アプリケーションは HTTP サーブレット API を介してブラウザに独自のクッキーを作成および設定し、HTTP セッションに関連付けられたクッキーは使用しようとはしません。WebLogic Server アプリケーションがクッキーを使用して特定のマシンのユーザの自動ログインを行う場合、新しいクッキーの存続期間を長く設定します。クッキーは、クライアント マシンだけから送ることができます。WebLogic Server アプリケーションは、そのユーザが複数の場所からアクセスする必要がある場合、サーバにデータを格納する必要があります。
ブラウザ クッキーの存続期間を直接セッションの長さに関連付けることはできません。クッキーがそれに関連付けられているセッションより早く期限切れになった場合、そのセッションは切り離されてしまいます。セッションがそれに関連付けられているクッキーより早く期限切れになった場合、サーブレットはそのセッションを見つけることができません。この場合、新しいセッションは request.getSession(true)
メソッドが呼び出されるときに自動的に割り当てられます。
クッキーの最大存続時間は、weblogic.xml
デプロイメント記述子のセッション記述子にある cookie-max-age-secs
要素で設定できます。「session-descriptor」を参照してください。
ユーザ認証情報は、ユーザのセッション データと、Web アプリケーションの対象となるサーバまたは仮想ホストのコンテキストの両方に格納されます。ユーザのログアウトに多く使われる session.invalidate()
メソッドでは、ユーザの現在のセッションのみが無効になり、ユーザの認証情報は有効なまま、サーバまたは仮想ホストのコンテキストに格納されます。サーバまたは仮想ホストが 1 つの Web アプリケーションのみのホストである場合、実際には session.invalidate()
メソッドでユーザをログアウトします。
複数の Web アプリケーションで認証を使用するときには、複数の Java メソッドと方式を使用できます。詳細については、「セッションのログアウトと終了」を参照してください。
デフォルトでは、Web アプリケーション間で同じセッションが共有されることはありません。Web アプリケーション間で同じセッションを共有する場合は、weblogic-application.xml
デプロイメント記述子において、アプリケーション レベルでセッション記述子をコンフィグレーションできます。Web アプリケーション間で同じセッションを共有するには、weblogic-application.xml
デプロイメント記述子内で、セッション記述子の sharing-enabled
属性を true
に設定します。「session-descriptor」の「sharing-enabled」を参照してください。
アプリケーション レベルで指定したセッション記述子のコンフィグレーションは、アプリケーション内のすべての Web アプリケーションについて、Web アプリケーション レベルで指定したすべてのセッション記述子コンフィグレーションをオーバーライドします。Web アプリケーション レベルで sharing-enabled
属性を true に設定しても、これは無視されます。
アプリケーション内のすべての Web アプリケーションは、次の例のように weblogic-application.xml
デプロイメント記述子内でセッション記述子を指定して、sharing-enabled
属性を true
に設定した場合、同じセッション インスタンスを使用して自動的に起動されます。
<?xml version="1.0" encoding="ISO-8859-1"?> <weblogic-application xmlns="http://xmlns.oracle.com/weblogic/weblogic-application";;> ... <session-descriptor> <persistent-store-type>memory</persistent-store-type> <sharing-enabled>true</sharing-enabled> ... </session-descriptor> ... </weblogic-application>
セッションの永続性を使用して、HTTP セッション オブジェクトにデータを永続的に格納し、WebLogic Server のクラスタ全体のフェイルオーバとロード バランシングを有効にします。アプリケーションが HTTP セッション オブジェクトにデータを格納するとき、データをシリアライズ可能にする必要があります。
セッションの永続性の実装は、以下の 5 つです。
メモリ (単一サーバ、非レプリケート)
ファイル システムの永続性
JDBC の永続性
クッキーベースの永続性
インメモリ レプリケーション (クラスタ全体)
最初の 4 つについてはここで説明します。インメモリ レプリケーションについては、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「HTTP セッション ステートのレプリケーション」を参照してください。
ファイル、JDBC、クッキーベース、およびメモリ (単一サーバ、非レプリケート) のセッション永続性には、共通のプロパティがいくつか存在します。以下の節で説明するとおり、各永続性メソッドはそれぞれ独自のコンフィグレーション可能なパラメータ セットを持っています。これらのパラメータは、weblogic.xml
デプロイメント記述子ファイルの session-descriptor
要素の下位要素です。
この節では、ファイルベースの永続性と JDBC ベースの永続性に共通するパラメータについて説明します。weblogic.xml
デプロイメント記述子ファイルの session-descriptor
要素で次のパラメータを定義することにより、メモリ内に保持されるセッション数をコンフィグレーションできます。これらのパラメータは、セッション永続性を使用している場合にだけ適用できます。
cache-size
- メモリ内で一度にアクティブにできるキャッシュされたセッションの数を制限します。同時に大量のアクティブ セッションが発生することが見込まれる場合、これらのセッションでサーバの RAM を満たしたくはありません。仮想メモリとのスワッピングにより、パフォーマンスが低下する可能性があるからです。キャッシュが満杯になると、最も古いセッションは永続ストレージに格納され、必要になったときに自動的に呼び戻されます。永続性を使用しない場合、このプロパティは無視され、メイン メモリに保持可能なセッション数はソフトウェアによって制限されなくなります。デフォルトでは、キャッシュされるセッションの数は 1028 です。キャッシュをオフにするには、この数を 0 に設定します。「session-descriptor」を参照してください。
注意 : cache-size は、JDBC およびファイルベースのセッションによって、インメモリ バブル キャッシュを保持する目的にのみ使用されます。他の永続性タイプには適用されません。 |
invalidation-interval-secs
- WebLogic Server が、タイムアウトの無効なセッションに対してハウスクリーニング チェックを実行してから古いセッションを削除してメモリを解放するまでの待ち時間を秒単位で設定します。この要素を使用すると、トラフィックの多いサイトで WebLogic Server の動作を最適化できます。「session-descriptor」を参照してください。
最小値は毎秒 (1) です。最大値は、週に 1 回 (604,800 秒) です。この属性を設定しない場合、デフォルトは 60 秒になります。
メモリ ベースのストレージを使用する場合、すべてのセッション情報はメモリに格納され、WebLogic Server を終了して再起動すると失われます。メモリ ベース、単一サーバ、非レプリケート永続ストレージを使用するには、weblogic.xml
デプロイメント記述子ファイルの session-descriptor
要素にある persistent-store-type
パラメータを memory
に設定します。「session-descriptor」を参照してください。
注意 : WebLogic Server を実行するときに十分なヒープ サイズを割り当てないと、負荷がかかったときにサーバのメモリが足りなくなることがあります。 |
ファイルベースの永続ストレージをセッション用にコンフィグレーションするには、次の手順に従います。
デプロイメント記述子ファイル weblogic.xml
で、session-descriptor
要素内の persistent-store-type
パラメータを
file
に設定します。「session-descriptor」を参照してください。
WebLogic Server がセッションを格納するディレクトリを設定します。「session-descriptor」を参照してください。
注意 : このディレクトリは手動で作成する必要があります。また、適切なアクセス権限がディレクトリに割り当てられていることを確認する必要があります。 |
JDBC の永続性は、この目的のために提供されたスキーマを使ってデータベース テーブルにセッション データを格納します。JDBC ドライバを備えたデータベースはすべて使用できます。データベース アクセスは、接続プールを使ってコンフィグレーションします。
JDBC セッションの永続性を利用している場合、WebLogic Server はシステム時間を使用してセッションの有効期間を判別しているため、同じクラスタ内のサーバが実行されているすべてのマシン上のシステム クロックを同期させておく必要があります。
JDBC ベースの永続ストレージをセッション用にコンフィグレーションするには、次の手順に従います。
weblogic.xml
デプロイメント記述子ファイルの session-descriptor
要素にある persistent-store-type
パラメータを jdbc
に設定します。「session-descriptor」を参照してください。
weblogic.xml
デプロイメント記述子ファイルの session-descriptor
要素にある persistent-store-pool
パラメータを使用して、永続ストレージに使用される JDBC 接続プールを設定します。WebLogic Server Administration Console で定義される接続プールの名前を使用します。「session-descriptor」を参照してください。
JDBC ベースの永続性のための wl_servlet_sessions
というデータベース テーブルを設定します。データベースに接続する接続プールは、このテーブルの読み取り/書き込みアクセス権を保有する必要があります。
注意 : データベースで自動的に作成されない場合は、wl_id および wl_context_path にインデックスを作成します。一部のデータベースでは、主キーのインデックスが自動的に作成されます。 |
カラム名とデータ型を次のように設定します。
表 10-1 wl_servlet_sessions の作成
カラム名 | データ型 |
---|---|
wl_id |
最大 100 文字の可変長の英数字カラム。例 : Oracle 主キーは次のように設定する。
|
wl_context_path |
最大 100 文字の可変長の英数字カラム。例 : Oracle VARCHAR2(100)。このカラムは主キーの一部として使用する ( |
wl_is_new |
1 文字のカラム。例 : Oracle |
wl_create_time |
20 桁の数値カラム。例 : Oracle |
wl_is_valid |
1 文字のカラム。例 : Oracle |
wl_session_values |
ラージ バイナリ カラム。例 : Oracle |
wl_access_time |
20 桁の数値カラム。例 : |
wl_max_inactive_interval |
整数カラム。例 : Oracle |
Oracle DBMS を使用している場合、次の SQL 文を使って wl_servlet_sessions
テーブルを作成できます。この SQL 文をユーザの DBMS に合わせて変更します。
コード リスト 10-1 Oracle DBMS を使用した wl_servlet_sessions テーブルの作成
create table wl_servlet_sessions ( wl_id VARCHAR2(100) NOT NULL, wl_context_path VARCHAR2(100) NOT NULL, wl_is_new CHAR(1), wl_create_time NUMBER(20), wl_is_valid CHAR(1), wl_session_values LONG RAW, wl_access_time NUMBER(20), wl_max_inactive_interval INTEGER, PRIMARY KEY (wl_id, wl_context_path) );
注意 : ユーザは、jdbc-connection-timeout-secs パラメータを使用して、JDBC セッション永続性がセッション データのロードに失敗するまで、接続プールからの JDBC 接続を待つ最大の期間をコンフィグレーションできます。詳細については、「session-descriptor」を参照してください。 |
SqlServer2000 を使用している場合、次の SQL 文を使って wl_servlet_sessions
テーブルを作成できます。この SQL 文をユーザの DBMS に合わせて変更します。
コード リスト 10-2 SqlServer 2000 を使用した wl_servlet_sessions テーブルの作成
create table wl_servlet_sessions ( wl_id VARCHAR2(100) NOT NULL, wl_context_path VARCHAR2(100) NOT NULL, wl_is_new VARCHAR(1), wl_create_time DECIMAL, wl_is_valid VARCHAR(1), wl_session_values IMAGE, wl_access_time DECIMAL, wl_max_inactive_interval INTEGER, PRIMARY KEY (wl_id, wl_context_path) );
Pointbase を使用する場合、Pointbase では SQL が変換されます。たとえば、コード リスト 10-1 に示した SQL は、Pointbase では次のように変換されます。
コード リスト 10-3 Pointbase での SQL 変換を使用した wl_servlet_sessions テーブルの作成
SQL> describe wl_servlet_sessions; WL_SERVLET_SESSIONS WL_ID VARCHAR(100) NULLABLE: NO WL_CONTEXT_PATH VARCHAR(100) NULLABLE: NO WL_IS_NEW CHARACTER(1) NULLABLE: YES WL_CREATE_TIME DECIMAL(20) NULLABLE: YES WL_IS_VALID CHARACTER(1) NULLABLE: YES WL_SESSION_VALUES BLOB(65535) NULLABLE: YES WL_ACCESS_TIME DECIMAL(20) NULLABLE: YES WL_MAX_INACTIVE_INTERVAL INTEGER(10) NULLABLE: YES Primary Key: WL_CONTEXT_PATH Primary Key: WL_ID
DB2 を使用している場合、次の SQL 文を使って wl_servlet_sessions
テーブルを作成できます。この SQL 文をユーザの DBMS に合わせて変更します。
コード リスト 10-4 DB2 を使用した wl_servlet_sessions テーブルの作成
CREATE TABLE WL_SERVLET_SESSIONS ( WL_ID VARCHAR(100) not null, WL_CONTEXT_PATH VARCHAR(100) not null, WL_IS_NEW SMALLINT, WL_CREATE_TIME DECIMAL(16), WL_IS_VALID SMALLINT, wl_session_values BLOB(10M) NOT LOGGED, WL_ACCESS_TIME DECIMAL(16), WL_MAX_INACTIVE_INTERVAL INTEGER, PRIMARY KEY (WL_ID,WL_CONTEXT_PATH) );
Sybase を使用している場合、次の SQL 文を使って wl_servlet_sessions
テーブルを作成できます。この SQL 文をユーザの DBMS に合わせて変更します。
コード リスト 10-5 Sybase を使用した wl_servlet_sessions テーブルの作成
create table WL_SERVLET_SESSIONS ( WL_ID varchar(100) not null , WL_CONTEXT_PATH varchar(100) not null , WL_IS_NEW smallint null , WL_CREATE_TIME decimal(16,0) null , WL_IS_VALID smallint null , WL_SESSION_VALUES image null , WL_ACCESS_TIME decimal(16,0) null , WL_MAX_INACTIVE_INTERVAL int null , ) go alter table WL_SERVLET_SESSIONS add PRIMARY KEY CLUSTERED (WL_ID, WL_CONTEXT_PATH) go
WebLogic Server は、要求が読み取り専用の場合は、HTTP セッション ステートをディスクに書き込みません。つまり要求によって HTTP セッションに変更が加えられることはありません。セッションがアクセスされると、データベース内では wl_access_time
カラムのみが更新されます。
読み取り専用でない要求の場合、Web アプリケーション コンテナは、HTTP リクエストのたびに、セッション ステートの変更についてデータベースを更新します。これが行われるのは、クラスタ内のすべてのサーバが、フェイルオーバに際して要求を処理し、データベースから最新のセッション ステートを取得できるようにするためです。
複数のデータベース クエリが生じることを回避するため、WebLogic Server では最近使用されたセッションがキャッシュされます。最近使用されたセッションは、要求ごとにデータベースからリフレッシュされることはありません。キャッシュ内のセッション数は、WebLogic Server 固有のデプロイメント記述子 weblogic.xml
の session-descriptor
要素内の cache-size
パラメータによって規定されます。「session-descriptor」を参照してください。
クッキーベースのセッション永続性は、ユーザのブラウザのクッキーにすべてのセッション データを格納することで、セッション永続性のステートレスなソリューションを提供します。クッキーベースのセッション永続性が最も役に立つのは、セッションに大量のデータを格納する必要がないときです。クッキーベースのセッション永続性は、クラスタ フェイルオーバ ロジックが必要ないので、WebLogic Server のインストール環境をより簡単に管理できます。セッションが格納されるのはブラウザ内であって、サーバ上ではありません。WebLogic Server の起動と停止は、セッションを失わずに行うことができます。
クッキーベースのセッション永続性には、次に示すいくつかの制限事項があります。
セッションに格納できるのは文字列属性のみ。セッションに他の種類のオブジェクトを格納した場合、IllegalArgument
例外が送出されます。
HTTP 応答はフラッシュできない (クッキーは応答が発行される前にヘッダ データに書き込まれる必要があるため)。
応答のコンテンツの長さがバッファ サイズを超える場合、応答は自動的にフラッシュされ、セッション データはクッキー内では更新できない。バッファ サイズはデフォルトで 8192 バイトです。バッファ サイズは javax.servlet.ServletResponse.setBufferSize() メソッドで変更できます。
使用できる認証は基本的なもの (ブラウザベース) のみ。
セッション データはクリア テキストでブラウザに送信される。
ユーザのブラウザを、クッキーを受け付けるようにコンフィグレーションする必要がある。
クッキーベースのセッション永続性を使用する場合、文字列でカンマ (,) を使用することはできない。これに従わない場合は例外が発生します。
クッキーベースのセッション永続性を設定するには、次の手順に従います。
weblogic.xml
デプロイメント記述子ファイルの session-descriptor
要素にある persistent-store-type
パラメータを cookie
に設定します。「session-descriptor」を参照してください。
必要な場合は、persistent-store-cookie-name
要素を使ってクッキーに名前を設定します。デフォルトは WLCOOKIE
です。「session-descriptor」を参照してください。
状況によっては、ブラウザまたは無線デバイスがクッキーを受け入れないこともあります。この場合、クッキーによるセッション トラッキングを行うことができません。URL 書き換えを使用すると、ブラウザがクッキーを受け入れないことを WebLogic Server が検出したときに、こうした状況を自動的に置き換えることができます。URL 書き換えでは、セッション ID を Web ページのハイパーリンクにエンコードし、サーブレットはそれらをブラウザに送り返します。ユーザが以後これらのリンクをクリックすると、WebLogic Server は URL アドレスからその ID を抽出し、サーブレットが getSession()
メソッドを呼び出すと適切な HttpSession
を見つけ出します。
WebLogic 固有のデプロイメント記述子である weblogic.xml
の session-descriptor
要素に url-rewriting-enabled
パラメータを設定することで、URL 書き換えを有効にします。この属性のデフォルト値は true
です。「session-descriptor」を参照してください。
URL 書き換えのサポートに関するガイドライン
次に示すように、URL を出力ストリームに直接書き出すことは避ける。
out.println("<a href=\"/myshop/catalog.jsp\">catalog</a>");
代わりに、HttpServletResponse.encodeURL()
メソッドを使用します。次に例を示します。
out.println("<a href=\" + response.encodeURL("myshop/catalog.jsp") + "\">catalog</a>");
encodeURL()
メソッドを呼び出すと、URL を書き換える必要があるかどうかが調べられます。書き換えが必要な場合、WebLogic Server は、セミコロンで始まるセッション ID を URL に追加することによって、URL を書き換えます。
WebLogic Server への応答として返される URL に加えて、リダイレクトを送信する URL をエンコードする。次に例を示します。
if (session.isNew()) response.sendRedirect (response.encodeRedirectUrl(welcomeURL));
WebLogic Server はセッションが新しいときには、ブラウザがクッキーを受け入れる場合でも URL 書き換えを使用します。これは、セッションの最初ではサーバはブラウザがクッキーを受け入れるかどうかを判断できないからです。
プラグイン (Apache、NSAPI、ISAPI、HttpClusterServlet
、または HttpProxyServlet
) を使用しており、バックエンド サーバで URL 書き換え (response.sendRedirect(url)
または response.encodeRedirectURL(url)
) を使用している場合は、一定の条件を満たすと、URL に PathTrim
パラメータと PathPrepend
パラメータの両方が適用されます。一定の条件とは、「PathPrepend
が null であるか、PathPrepend
がすでに適用されている」というもので、PathTrim
はこのいずれかを満たす場合にのみ適用されます。
サーブレットは、HttpServletRequest.isRequestedSessionIdFromCookie()
メソッドから返されるブール値をチェックすることによって、特定のセッション ID がクッキーから受け取られたかどうかを確認できる。WebLogic Server アプリケーションは適切に応答するか、WebLogic Server による URL 書き換えに依存します。
注意 : CISCO Local Director ロード バランサでは、URL 書き換えの区切り記号として疑問符 (? ) が想定されています。WLS の URL 書き換えメカニズムは区切り記号としてセミコロン (;) を使用するので、WLS の URL 書き換えとこのロード バランサの間には互換性がありません。 |
WAP アプリケーションを作成する場合、WAP プロトコルはクッキーをサポートしていないため、URL を書き換える必要があります。また、一部の WAP デバイスでは、URL の長さが 128 文字 (属性も含む) に制限されます。これにより、URL 書き換えによって転送できるデータ サイズが制限されます。属性用の領域を大きくするために、WebLogic Server でランダムに生成されるセッション ID のサイズを制限できます。
WAPEnabled
属性を使用するには、Administration Console の [サーバ|プロトコル|HTTP|詳細オプション] ページで指定します。WAPEnabled
属性を使用することで、セッション ID のサイズを 52 文字までに制限し、!
や #
などの特殊文字の使用を禁止できます。また、weblogic.xml
の IDLength パラメータを使うと、セッション ID のサイズをさらに制限できます。詳細については、「session-descriptor」を参照してください。
セッション トラッキングを使用すると、複数のサーブレットか HTML ページにわたって、本来はステートレスであるユーザの状況を追跡できます。セッションとは、ある期間中に同じクライアントから出される一連の関連性のあるブラウザ要求のことです。セッション トラッキングは、ショッピング カート アプリケーションのように、全体として何らかの意味を持つ一連のブラウザ要求 (これをページと見なす) を結合します。
以下の節では、HTTP サーブレットからのセッション トラッキングについて、さまざまな観点から説明します。
セッション トラッキングという概念が発展する前は、ページの非表示フィールドに情報を詰め込むか、長い文字列をリンクで使われる URL に追加してユーザの選択内容を埋め込むことで、ページに状態を組み込んでいました。このよい例が、サーチ エンジン サイトです。サーチ エンジン サイトの多くはいまだに CGI に依存しています。これらのサイトは、URL の後に HTTP で予約されている ? 記号を付け、その後に続く URL パラメータの名前 = 値の組を使用して、ユーザの選択を追跡します。このようにすると、URL は非常に長いものになることがあり、CGI スクリプトはこれを慎重に解析し、管理する必要があります。この手法の問題点は、情報をセッションからセッションへと渡せないことです。URL の制御を失うと、つまりユーザがページから離れると、ユーザ情報は永久に失われます。
その後、Netscape はブラウザのクッキーを発表しました。これを使用してサーバごとにクライアント上のユーザ関連情報を格納することができます。しかし、ブラウザによってはまだクッキーを完全にサポートしていないものもあり、またブラウザのクッキー オプションをオフにしておくことを選ぶユーザもいます。もう 1 つの考慮すべき要因は、ほとんどのブラウザではクッキーで格納できるデータ量を制限しているということです。
CGI の手法とは異なり、HTTP サーブレットの仕様では、サーバがサーバ上のユーザの詳細情報を単一のセッションを超えて格納できる方法が定義されており、セッションのトラッキングによるコードの複雑化を避けることが可能です。サーブレットを使用すると、HttpSession オブジェクトによって単一のセッションを超える範囲でユーザ入力を追跡し、セッションの詳細を複数のサーブレットで共有できます。セッション データは、WebLogic サービスで使用できるさまざまなメソッドを使用して保持することができます。
WebLogic が実装してサポートしている Java Servlet API では、各サーブレットは HttpSession
オブジェクトを使用して、サーバサイド セッションにアクセスすることができます。HttpServletRequest
オブジェクトを使用して、サーブレットの service()
メソッド内の HttpSession
オブジェクトにアクセスできます。次の例のように変数 request
を使用します。
HttpSession session = request.getSession(true);
引数 true
で request.getSession(true)
メソッドが呼び出されると、そのクライアントに対して既存の HttpSession
オブジェクトがない場合には、HttpSession オブジェクトが生成されます。セッション オブジェクトは、そのセッションの有効期間の間 WebLogic Server に存在し、そのクライアントに関連した情報を蓄積します。サーブレットは、必要に応じて、セッション オブジェクトで情報の追加や削除を行います。セッションは特定のクライアントに関連付けられます。クライアントがサーブレットを訪れると、毎回、getSession()
メソッドが呼び出されたときに関連する同じ HttpSession
オブジェクトが取得されます。
HttpSession
でサポートされるメソッドの詳細については、http://java.sun.com/j2ee/j2sdkee/techdocs/api/javax/servlet/http/HttpSession.html
の HttpServlet API を参照してください。
次の例では、service()
メソッドが、セッション中にユーザがサーブレットを要求する回数を数えます。
public void service(HttpServletRequest request, HttpServletResponse, response) throws IOException { // セッションおよびカウンタのパラメータ属性を取得する HttpSession session = request.getSession (true); Integer ival = (Integer) session.getAttribute("simplesession.counter"); if (ival == null) // カウンタを初期化する ival = new Integer (1); else // カウンタをインクリメントする ival = new Integer (ival.intValue () + 1); // セッションに新しい属性値を設定する session.setAttribute("simplesession.counter", ival); // HTML ページを出力する out.print("<HTML><body>"); out.print("<center> You have hit this page "); out.print(ival + " times!"); out.print("</body></html>"); }
セッションは、1 つのトランザクションの一連のページにわたるユーザの選択を追跡します。1 つのトランザクションは、ある品物を閲覧し、それをショッピング カートに追加した後、支払手続きをするといった複数のタスクで構成されます。セッションは永続的なものではなく、以下のいずれかの時点で、その有効期間は終了します。
ユーザがサイトを離れ、ブラウザがクッキーを受け入れない場合。
ユーザがブラウザを終了した場合。
動作がないため、セッションがタイム アウトになった場合。
セッションが完了し、サーブレットによって無効にされた場合。
ユーザがログアウトし、サーブレットによって無効にされた場合。
より永続的な長い時間データを保存するには、サーブレットで JDBC または EJB を使用して詳細をデータベースに書き込み、存続期間の長いクッキーやユーザ名とパスワードによって、そのデータとクライアントとを関連付ける必要があります。
注意 : このマニュアルでは、セッションが内部的にクッキーや永続性を使用すると説明していますが、セッションをユーザに関するデータ格納のための一般的なメカニズムとして使用してはいけません。 |
WebLogic Server では、各クライアントにどのセッションが関連付けられているのかが、どのようにして認識されるのでしょうか。HttpSession
がサーブレットで生成されると、ユニークな ID と関連付けられます。ブラウザは、このセッション ID をその要求に付与し、サーバが再びセッション データを見つけられるようにしなければなりません。サーバは、クライアントにクッキーを設定することによって、この ID を保存しようとします。一度クッキーが設定されると、ブラウザがサーバに要求を送るたびに、要求にはその ID を内包したクッキーが含まれます。サーバは自動的にクッキーを解析し、サーブレットが getSession()
メソッドを呼び出すと、セッション データを提供します。
クライアントがクッキーを受け入れない場合、代わりの方法としては、クライアントへ送り返されるページの中で、URL リンクにその ID をエンコードするしかありません。このため、サーブレットの応答に URL を入れる場合は、必ず encodeURL()
メソッドを使用します。WebLogic Server はブラウザがクッキーを受け入れるかどうかを検出して、不必要な URL のエンコードは行いません。自動的に、エンコードされた URL からセッション ID を解析し、getSession()
メソッドを呼び出すと、正しいセッション データを取得します。encodeURL()
メソッドを使用すると、セッション トラッキングにどの手順を使用しても、サーブレットのコードが破壊されることはありません。詳細については、「クッキーに代わる URL 書き換えの使用」を参照してください。
getSession(true)
メソッドを使用してセッションを取得した後、HttpSession.isNew()
メソッドを呼び出すことにより、そのセッションが生成されたばかりかどうかがわかります。このメソッドが true
を返した場合、クライアントはまだ有効なセッションを持っておらず、またこの時点では新規のセッションを認識しません。クライアントが新規のセッションを認識するのは、サーバから応答がポストされて戻ってからです。
ビジネス ロジックに合った方法で、新規または既存のセッションに適応するようにアプリケーションを設計してください。たとえば、セッションがまだ開始していないと判断すれば、次のサンプル コードのように、アプリケーションでクライアントの URL をログイン/パスワードのページにリダイレクトしてもよいでしょう。
HttpSession session = request.getSession(true); if (session.isNew()) { response.sendRedirect(welcomeURL); }
ログインのページでは、システムにログインするか、新規アカウントを作成するかを選択できるようにします。また、J2EE 標準の Web アプリケーション デプロイメント記述子 web.xml
の login-config
要素を使用して、Web アプリケーションでログイン ページを指定することもできます。
名前 = 値の組み合わせを使用して、HttpSession
オブジェクトにデータを格納できます。セッションに格納されたデータは、そのセッションを通じて利用することができます。セッションにデータを格納するには、次のメソッドを HttpSession
インタフェースから使用します。
getAttribute() getAttributeNames() setAttribute() removeAttribute() 次のコードでは、既存の名前 = 値の組み合わせをすべて取得する方法を示します。 Enumeration sessionNames = session.getAttributeNames(); String sessionName = null; Object sessionValue = null; while (sessionNames.hasMoreElements()) { sessionName = (String)sessionNames.nextElement(); sessionValue = session.getAttribute(sessionName); System.out.println("Session name is " + sessionName + ", value is " + sessionValue); }
名前の付いた属性を追加または上書きするには、setAttribute()
メソッドを使用します。名前の付いた属性を完全に削除するには、removeAttribute()
メソッドを使用します。
注意 : Java のObject の子孫をセッション属性として追加し、それに名前を関連付けることができます。ただし、セッション永続性を利用している場合、属性値オブジェクトは java.io.Serializable を実装しなければなりません。 |
アプリケーションがデリケートな情報を扱う場合は、セッションからログアウトする機能の提供を検討します。これは、ショッピング カートやインターネットの電子メール アカウントを使用する際には一般的な機能です。同一のブラウザがサービスに戻るとき、ユーザはシステムにログインし直さなければなりません。
ユーザ認証情報は、ユーザのセッション データと、Web アプリケーションの対象となるサーバまたは仮想ホストのコンテキストの両方に格納されます。ユーザのログアウトに多く使われる session.invalidate()
メソッドでは、ユーザの現在のセッションのみが無効になり、ユーザの認証情報は有効なまま、サーバまたは仮想ホストのコンテキストに格納されます。サーバまたは仮想ホストが 1 つの Web アプリケーションだけをホストしている場合は、session.invalidate()
メソッドを実行するとユーザはログアウトされます。
session.invalidate()
を呼び出した後、無効にされたセッションを参照しないでください。参照した場合、IllegalStateException
が送出されます。ユーザが次に同じブラウザからサーブレットにアクセスしたときには、セッション データは失われています。getSession(true)
メソッドを呼び出すと、新しいセッションが作成されます。この時点で、ユーザに再度ログイン ページを送信できます。
サーバまたは仮想ホストが複数の Web アプリケーションに割り当てられている場合、すべての Web アプリケーションからユーザをログアウトするには、別の方法が必要になります。Servlet 仕様では、すべての Web アプリケーションからユーザをログアウトするための API が用意されていないため、以下のメソッドを使用します。
weblogic.servlet.security.ServletAuthentication.logout()
- 認証データをユーザのセッション データから削除します。これにより、ユーザはログアウトされますが、セッションは引き続き有効です。
weblogic.servlet.security.ServletAuthentication.invalidateAll()
- すべてのセッションを無効にして、現在のユーザの認証データを削除します。クッキーも無効になります。
weblogic.servlet.security.ServletAuthentication.killCookie()
- 応答がブラウザに送信された直後に有効期限が切れるようにクッキーを設定して、現在のクッキーを無効にします。このメソッドでは、応答がユーザのブラウザに正常に届く必要があります。セッションはタイムアウトするまで維持されます。
シングル サインオンへの参加から Web アプリケーションを除外するには、除外する Web アプリケーションに異なるクッキー名を定義します。詳細については、「WebLogic Server セッション クッキーのコンフィグレーション」を参照してください。
WebLogic Server では、セッション トラッキングの処理方法を決定するさまざまな属性をコンフィグレーションできます。これらのセッション トラッキング属性のコンフィグレーションの詳細については、「session-descriptor」を参照してください。
状況によっては、ブラウザがクッキーを受け入れないこともあります。この場合、クッキーによるセッション トラッキングができません。代わりに URL 書き換えを使用すると、ブラウザがクッキーを受け入れないことを WebLogic Server が検出したときに、こうした状況を自動的に置き換えることができます。URL 書き換えでは、セッション ID を Web ページのハイパーリンクにエンコードし、サーブレットはそれらをブラウザに送り返します。ユーザが以後これらのリンクをクリックすると、WebLogic Server は URL アドレスからその ID を抽出し、適切な HttpSession
を見つけます。その後、
getSession()
メソッドを使用して、セッション データにアクセスできます。
WebLogic Server で URL 書き換えを有効にするには、WebLogic Server 固有のデプロイメント記述子 weblogic.xml
の session-descriptor
要素で URL-rewriting-enabled
パラメータを true
に設定します。「session-descriptor」を参照してください。
URL 書き換えをサポートするために、コードで URL を適切に処理するには、以下のガイドラインに従います。
次に示すように、URL を出力ストリームに直接書き出すことは避ける。
out.println("<a href=\"/myshop/catalog.jsp\">catalog</a>");
代わりに、HttpServletResponse.encodeURL()
メソッドを使用します。次に例を示します。
out.println("<a href=\"" + response.encodeURL("myshop/catalog.jsp") + "\">catalog</a>");
encodeURL()
メソッドを呼び出すと、URL を書き換える必要があるかどうかが調べられる。必要である場合、URL にセッション ID を組み込むことによって書き換えを行います。
WebLogic Server への応答として返される URL に加えて、リダイレクトを送信する URL をエンコードする。次に例を示します。
if (session.isNew()) response.sendRedirect(response.encodeRedirectUrl(welcomeURL));
WebLogic Server はセッションが新しいときには、ブラウザがクッキーを受け入れる場合でも URL 書き換えを使用します。これは、セッションの最初ではサーバはブラウザがクッキーを受け入れるかどうかを判断できないからです。
サーブレットは、HttpServletRequest.isRequestedSessionIdFromCookie()
メソッドから返されるブール値をチェックすることによって、所定のセッションがクッキーから返されたかを確認できます。アプリケーションは適切に応答するか、WebLogic Server による URL 書き換えに依存します。
注意 : CISCO Local Director ロード バランサでは、URL 書き換えの区切り記号として疑問符 (? ) が想定されています。WLS の URL 書き換えメカニズムは区切り記号としてセミコロン (; ) を使用するので、WLS の URL 書き換えとこのロード バランサの間には互換性がありません。 |
WAP アプリケーションを作成する場合、WAP プロトコルはクッキーをサポートしていないため、URL を書き換える必要があります。また、一部の WAP デバイスでは、URL の長さが 128 文字 (パラメータも含む) に制限されます。これにより、URL 書き換えによって転送できるデータ サイズが制限されます。パラメータ用に使えるスペースを増やすには、WebLogic Server 固有のデプロイメント記述子 weblogic.xml
の session-descriptor
要素で id-length
パラメータを使用してバイト数を指定し、WebLogic Server によってランダムに生成されるセッション ID のサイズを制限できます。「session-descriptor」を参照してください。
最小値は 8 バイト、デフォルト値は 52 バイト、最大値は Integer.MAX_VALUE
です。
WebLogic Server は、セッション データを永続ストレージに記録するように設定できます。セッション永続性を使用すると、以下の特性を利用できます。
フェイルオーバのよさ。サーバに障害が発生してもセッションが保存されるためです。
ロード バランシングのよさ。どのサーバでも、セッションがいくつあってもその要求を処理し、キャッシュを使用して、パフォーマンスを最適化できるためです。詳細については、「セッションの永続性のコンフィグレーション」で cache-size
プロパティを参照してください。
セッションを、クラスタ化された WebLogic Server 間で共有できる。WebLogic クラスタではセッション永続性は必要条件ではなくなりました。その代わりに、ステートのインメモリ レプリケーションを使用します。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』を参照してください。
顧客が最高品質のサーブレット セッション永続性を求めている場合は、JDBC ベースの永続性が最適。セッション永続性はある程度犠牲にしても、パフォーマンスを大幅に高めたい顧客の場合には、インメモリ レプリケーションが適切な選択です。JDBC ベースの永続性は、インメモリ レプリケーションよりも著しく低速です。サーブレット セッションに対して、インメモリ レプリケーションが JDBC ベースの永続性よりも 8 倍高いパフォーマンスを提供したケースもあります。
どの種類の Java オブジェクトでもセッションに入れることができるが、ファイル、JDBC、およびインメモリ レプリケーションに関しては、java.io.Serializable
であるオブジェクトだけがセッションに格納される。詳細については、「セッションの永続性のコンフィグレーション」を参照してください。
セッション永続性を、セッション間の長期データを格納する目的には使わないでください。つまり、後日クライアントがサイトに戻ったときに、アクティブなままのセッションがあっても、それに依存してはいけません。むしろアプリケーションでは、長期にわたる情報や重要な情報は、データベースの中に記録すべきです。
セッションはクッキーのコンビニエンス ラッパーではありません。セッションには長期間であろうと一定期間であろうと、クライアント データを格納しようとしてはいけません。それよりも、アプリケーションのほうでクッキーをブラウザ上に作成し設定すべきです。例として、クッキーが長期間存続できる自動ログイン機能、クッキーが短期間で失効する自動ログアウト機能などがあります。この場合、HTTP セッションを使用しないでください。代わりに、アプリケーション固有のロジックを記述します。
永続セッションを使用する場合、セッションに追加するすべての属性値オブジェクトは
java.io.Serializable
を実装する必要があります。
独自のシリアライズ可能なクラスを永続セッションに加える場合は、クラスの各インスタンス変数もシリアライズ可能になっているかに注意してください。シリアライズ可能でない場合は、それを transient
として宣言できます。WebLogic Server は、その変数を永続ストレージには保存しません。transient
とするべきインスタンス変数の一般的な例としては、HttpSession
オブジェクトが挙げられます (「セッションの永続化」の、セッションにおけるシリアライズされたオブジェクトの使用に関する注意を参照)。
HttpServletRequest
属性、ServletContext
属性、および HttpSession
属性は、WebLogic Server インスタンスが Web アプリケーション クラスローダで変更を検出するとシリアライズされます。クラスローダは、Web アプリケーションが再デプロイされた場合、サーブレットで動的な変更があった場合、または Web アプリケーション間で転送またはインクルードがあった場合に変更されます。
サーブレットの動的な変更時に属性がシリアライズされないようにするには、weblogic.xml
で servlet-reload-check-secs
を無効にします。Web アプリケーション間のディスパッチや Web アプリケーションの再デプロイメントの場合、属性のシリアライゼーションを回避する方法はありません。「servlet-reload-check-secs」を参照してください。
永続セッションの設定の詳細については、「セッションの永続性のコンフィグレーション」を参照してください。
新しいセッションが作成され続けているのに、インメモリ サーブレット セッションの使用をコンフィグレーションすることができなければ、サーバはやがて、メモリ不足を送出します。これを回避するため、WebLogic Server では作成されるセッション数に対して、コンフィグレーション可能な制限を設けています。この数を超えると、新しいセッションの作成が試行されるたびに、weblogic.servlet.SessionCreationException
が発生します。この機能は、レプリケートされたインメモリ セッションと、レプリケートされないインメモリ セッションの双方に適用される。
制限されたインメモリ サーブレット セッションの使用をコンフィグレーションするには、weblogic.xml
デプロイメント記述子の max-in-memory-sessions
要素で、制限を設定します。「session-descriptor」を参照してください。
メモリが過負荷になると、すべての getSession(true)
の試行に対して、weblogic.servlet.SessionCreationException (RuntimeException)
が発生します。サーブレット開発者は、次のようにしてこの例外に対処します。
例外発生時に、ユーザに状況を説明する適切なエラー メッセージを返す。
J2EE 標準の Web アプリケーション デプロイメント記述子 web.xml
で、weblogic.servlet.SessionCreationException
をエラー ページにマップする。
デフォルトでは、メモリ過負荷保護は無効になっています。これはドメイン レベルのフラグで有効化できます。
weblogic.management.configuration.WebAppContainerMBean.OverloadProtectionEnabled