Web アプリケーションにおけるセッションとセッション永続性の使用



\| WebLogic Server ホーム \| Web アプリケーション \| 前へ \| 次へ \| 目次 \| 索引 \| PDF 版

この章では、セッションとセッションの永続性を設定する方法について説明します。

HTTP セッションの概要

セッショントラッキングを使用すると、複数のサーブレットか HTML ページにわたって、本来はステートレスであるユーザの状況を追跡できます。セッションの定義は、ある一定期間中に同じクライアントから出される一連の関連性のあるブラウザリクエストです。セッショントラッキングは、ショッピングカートアプリケーションのように、全体として何らかの意味を持つ一連のブラウザリクエスト（これらのリクエストをページとみなす）を結合します。

セッション管理の設定

WebLogic Server は、デフォルトによってセッショントラッキングを処理するよう設定されています。セッショントラッキングを使用する際にプロパティを設定する必要はありません。ただし、WebLogic Server がどのようにセッションを管理するかをコンフィグレーションすることは、最高のパフォーマンスを実現するためにアプリケーションをチューニングするときの重要な鍵となります。チューニングの内容は、以下のような要素によって異なります。

サーブレットをヒットする予定ユーザ数
サーブレットをヒットする同時ユーザ数
各セッションの継続時間
各ユーザに対する予定格納データ量
WebLogic Server インスタンスに割り当てられるヒープサイズ

HTTP セッションプロパティ

WebLogic Server のセッショントラッキングは、WebLogic 固有のデプロイメント記述子である weblogic.xml のプロパティでコンフィグレーションします。WebLogic 固有のデプロイメント記述子の編集手順については、手順 4 : セッションパラメータの定義を参照してください。

セッション属性の全リストについては、 session-descriptor 要素を参照してください。

セッションタイムアウト

HTTP セッションが期限切れになるまでの間隔を指定できます。セッションが期限切れになると、そのセッションに格納されたデータは破棄されます。間隔は、以下の 2 通りの方法で設定できます。

WebLogic 固有のデプロイメント記述子である weblogic.xml の session-descriptor 要素の TimeoutSecs 属性を設定します。この値は秒単位で設定します。
Web アプリケーションデプロイメント記述子である web.xml の <session-timeout>（ session-config 要素を参照）要素を設定します。

セッションクッキーのコンフィグレーション

WebLogic Server は、クライアントブラウザによってサポートされる場合、クッキーを使用してセッション管理を行います。

WebLogic Server がセッショントラッキングに使用するクッキーは、デフォルトによって一時的なものとして設定されており、ブラウザの実行期間より長く存続することはありません。ユーザがブラウザを終了すると、クッキーは失われ、セッション有効期間が終了したものと見なされます。この動作はセッションの用途の基本であり、このようにセッションを使用することをお勧めします。

WebLogic 固有のデプロイメント記述子である weblogic.xml で定義される属性によって、セッションのトラッキングに使われるクッキーのさまざまな側面をコンフィグレーションできます。セッションの全リストとクッキーに関連する属性については、 session-descriptor 要素を参照してください。

WebLogic 固有のデプロイメント記述子の編集手順については、手順 4 : セッションパラメータの定義を参照してください。

存続期間が長いクッキーの使い方

長期間存続するクライアントサイドユーザデータの場合、WebLogic Server アプリケーションは HTTP サーブレット API を介してブラウザに独自のクッキーを作成および設定し、HTTP セッションに関連付けられたクッキーは使用しようとはしません。WebLogic Server アプリケーションがクッキーを使用して特定のマシンのユーザの自動ログインを行う場合、新しいクッキーの存続期間を長く設定します。クッキーは、クライアントマシンだけから送ることができます。WebLogic Server アプリケーションは、そのユーザが複数の場所からアクセスする必要がある場合、サーバにデータを格納する必要があります。

ブラウザクッキーの存続期間を直接セッションの長さに関連付けることはできません。クッキーがそれに関連付けられているセッションより早く期限切れになった場合、そのセッションは切り離されてしまいます。セッションががそれに関連付けられているクッキーより早く期限切れになった場合、サーブレットはそのセッションを見つけることができません。この場合、新しいセッションは request.getSession(true) メソッドが呼び出されるときに割り当てられます。セッションの使用は一時的なものに限定する必要があります。

クッキーの最大存続時間は、weblogic.xml デプロイメント記述子のセッション記述子にある CookieMaxAgeSecs パラメータで設定できます。詳細については、手順 4 : セッションパラメータの定義を参照してください。

セッションのログアウトと終了

ユーザ認証の情報は、ユーザのセッションデータ、およびサーバのコンテキストまたは Web アプリケーションにより割り当てられた仮想ホストのコンテキストの両方に格納されます。ユーザのログアウトに多く使われる session.invalidate() メソッドを使用すると、ユーザの現在のセッションのみが無効になり、ユーザの認証情報は有効なまま、サーバまたは仮想ホストのコンテキストに格納されます。サーバまたは仮想ホストが 1 つの Web アプリケーションだけをホストしている場合は、session.invalidate() メソッドを実行するとユーザはログアウトされます。

複数の Web アプリケーションで認証を使用するときには、複数の Java メソッドと戦略を使用できます。詳細については、『HTTP サーブレットプログラマーズガイド』「複数のアプリケーションに対する単一のサインオンの実装」を参照してください。

セッションの永続性のコンフィグレーション

セッションの永続性によって、HTTP セッションオブジェクトに格納されたデータは永続的に格納され、WebLogic Server のクラスタ全体のフェイルオーバとロードバランシングを有効にします。

セッションの永続性の実装は、以下の 5 つです。

メモリ（単一サーバ、非レプリケート）
ファイルシステムの永続性
JDBC の永続性
クッキーベースの永続性
インメモリレプリケーション（クラスタ全体）

最初の 4 つについてはここで説明します。インメモリレプリケーションについては、「HTTP セッションステートのレプリケーションについて」を参照してください。

ファイル、JDBC、クッキーベース、およびインメモリレプリケーションの場合、PersistentStoreType などの追加属性を設定する必要があります。各メソッドは、次に示すように独自の属性セットを持ちます。

アプリケーションが HTTP セッションオブジェクトにデータを格納するとき、データをシリアライズ可能にする必要があります。

共通プロパティ

メモリ内に保持されるセッションの数は、WebLogic 固有のデプロイメント記述子である weblogic.xml の <session-descriptor> 要素で次のプロパティを設定してコンフィグレーションできます。これらのプロパティは、セッション永続性を使用している場合にだけ適用できます。

CacheSize

メモリ内で一度にアクティブにできるキャッシュされたセッションの数を制限します。同時に大量のアクティブセッションが発生することが見込まれる場合、これらのセッションでサーバの RAM を満たしたくはありません。仮想メモリとのスワッピングにより、パフォーマンスが低下する可能性があるからです。キャッシュが満杯になると、最も古いセッションは永続ストレージに格納され、必要になったときに自動的に呼び戻されます。永続性を使用しない場合、このプロパティは無視され、メインメモリに保持可能なセッション数はソフトウェアによって制限されなくなります。デフォルトでは、キャッシュされるセッションの数は 1024 です。最小値は 16、最大値は Integer.MAX_VALUE です。空のセッションは 100 バイト未満のメモリしか使用しませんが、データの追加に応じて大きくなります。

SwapIntervalSecs

cacheEntries の制限に達したときに、WebLogic Server が最も古いセッションをキャッシュから永続ストレージにパージするまでの待ち時間です。

このプロパティを設定しない場合、デフォルトは 10 秒です。最小値は 1 秒、最大値は 604800 秒（1 週間)です。

InvalidationIntervalSecs

WebLogic Server が、タイムアウトの無効なセッションに対してハウスクリーニングチェックを実行してから古いセッションを削除してメモリを解放するまでの待ち時間を秒単位で設定します。このパラメータは、<session-timeout> 要素の設定値より小さく設定します。このパラメータを使用すると、トラフィックの多いサイトで WebLogic Server の動作を最適化できます。

最小値は毎秒（1）です。最大値は、週に 1 回(604800 秒)です。このパラメータを設定しない場合、デフォルトは 60 秒です。

Web アプリケーションデプロイメント記述子である web.xml の session-config 要素に <session-timeout> を設定します。

メモリベース、単一サーバ、非レプリケート永続ストレージの使い方

メモリベース、単一サーバ、非レプリケート永続ストレージを使用するには、WebLogic 固有のデプロイメント記述子である weblogic.xml の <session-descriptor> 要素にある PersistentStoreType プロパティを memory に設定します。メモリベースのストレージを使用する場合、すべてのセッション情報はメモリに格納され、WebLogic Server を終了して再起動すると失われます。

注意: WebLogic Server を実行するときに十分なヒープサイズを割り当てないと、負荷がかかったときにサーバのメモリが足りなくなることがあります。

ファイルベースの永続ストレージの使い方

ファイルベースの永続ストレージをセッション用に使用するには、次の手順に従います。

WebLogic 固有のデプロイメント記述子である weblogic.xml の <session-descriptor> 要素の PersistentStoreType プロパティを file に設定します。
WebLogic Server がセッションを格納するディレクトリを設定します。このディレクトリの設定の詳細については、 PersistentStoreDirを参照してください。
この属性値を明示的に設定しなかった場合、WebLogic Server によって一時ディレクトリが自動的に作成されます。

クラスタ環境 (WebLogic Cluster の、または WebLogic Cluster ではない複数の WebLogic インスタンスの) でファイルベースの永続ストレージを使用するには、以下の点に注意します。

上記の属性を、クラスタ内のすべてのサーバがアクセスできる共有ディレクトリに明示的に設定しなければなりません。このディレクトリは手動で作成する必要があります。
維持型のセッションであり続けるためには、フロントエンドのプロキシサーバも必要です。与えられたクライアントに対して、同じサーバでリクエストが処理されなければなりません。そうでないと、複数のサーバが同じストレージに書き込もうとしたときに問題が発生します。
weblogic.xml で、InvalidationIntervalSecs 属性を非常に大きい値に設定する必要もあります。

データベースの永続ストレージとしての使い方（JDBC 永続性）

JDBC の永続性は、この目的のために提供されたスキーマを使ってデータベーステーブルにセッションデータを格納します。JDBC ドライバを備えたデータベースはすべて使用できます。データベースアクセスは、接続プールを使ってコンフィグレーションします。

JDBC ベースの永続ストレージをセッション用にコンフィグレーションするには、次の手順に従います。

WebLogic 固有のデプロイメント記述子である weblogic.xml の <session-descriptor> 要素にある PersistentStoreType プロパティを jdbc に設定し、JDBC を永続ストレージの方法として設定します。
WebLogic 固有のデプロイメント記述子 weblogic.xml のPersistentStorePool プロパティを使用して、JDBC 接続プールを永続ストレージ用に使うよう設定します。WebLogic Server Administration Console で定義した接続プールの名前を使用します。
データベース接続プールの設定の詳細については、「JDBC 接続の管理」を参照してください。
許可を持っているユーザに対応する接続用 ACL を設定します。データベース接続の詳細については、「JDBC 接続の管理」を参照してください。

JDBC ベースの永続性用に wl_servlet_sessions というテーブルを設定します。データベースに接続する接続プールは、このテーブルの読み取り/書き込みアクセス権を保有する必要があります。次の表では、このテーブルを作成するときに使用するカラム名とデータ型を示します。

表4-1 JDBC ベースの永続性のための wl_servlet_sessions テーブル

カラム名	タイプ
`wl_id`	最大 100 文字の可変長の英数字カラム。例 : Oracle `VARCHAR2(100)`。主キーは次のように設定しなければならない。 `wl_id + wl_context_path.`
`wl_context_path`	最大 100 文字の可変長の英数字カラム。例 : Oracle `VARCHAR2(100)`。このカラムは主キーの一部として使用する（`wl_id` カラムの説明を参照）。
`wl_is_new`	1 文字のカラム。例 : Oracle `CHAR(1)`。
`wl_create_time`	20 桁の数値カラム。例 : Oracle `NUMBER(20)`。
`wl_is_valid`	1 文字のカラム。例 : Oracle `CHAR(1)`。
`wl_session_values`	ラージバイナリカラム。例 : Oracle `LONG RAW`。
`wl_access_time`	20 桁の数値カラム。例 : `NUMBER(20)`。
`wl_max_inactive_interval`	整数のカラム。例 : `Integer`。セッションが無効になるまでのクライアントリクエストの間隔の秒数。値がマイナスの場合、セッションがタイムアウトしないことを示す。

Oracle DBMS を使用している場合は、次の SQL 文を使用して 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) );

DBMS を使用して上記の SQL 文を変更できます。

注意: ユーザは、JDBConnectionTimeoutSecs 属性が設定されたセッションデータのロードに失敗するまで、JDBC セッション永続性が接続プールからの JDBC 接続を待つ最大の期間をコンフィグレーションできます。詳細については、 JDBConnectionTimeoutSecsを参照してください。

クッキーベースのセッション永続性の使用

クッキーベースのセッション永続性は、ユーザのブラウザのクッキーにすべてのセッションデータを格納することで、セッション永続性のステートレスなソリューションを提供します。クッキーベースのセッション永続性が最も役に立つのは、セッションに大量のデータを格納する必要がないときです。クッキーベースのセッション永続性は、クラスタフェイルオーバロジックが必要ないので、WebLogic Server のインストール環境をより簡単に管理できます。セッションが格納されるのはブラウザ内であって、サーバ上ではありません。WebLogic Server の起動と停止は、セッションを失わずに行うことができます。

クッキーベースのセッション永続性を使用すると、リクエストのバランシングは、セッション単位ではなく、リクエスト単位に行われます。クッキーベースのセッション永続性は完全にステートレスであり、どのサーバがリクエストを処理しても違いはないので (データはクライアントサイドで格納される)、リクエスト単位のバランシングは正しい動作です。

クッキーベースのセッション永続性を使用するときには、次に示すいくつかの制限事項があります。

セッションに格納できるのは文字列属性だけです。セッションに他の種類のオブジェクトを格納した場合、IllegalArgument 例外が送出されます。
HTTP 応答はフラッシュできません（クッキーは応答が発行される前にヘッダデータに書き込まれる必要があるため）。
応答のコンテンツの長さがバッファサイズを超える場合、応答は自動的にフラッシュされ、セッションデータはクッキー内では更新できません。バッファサイズはデフォルトで 8192 バイトです。バッファサイズは javax.servlet.ServletResponse.setBufferSize() メソッドで変更できます。
使用できる認証は基本的なもの（ブラウザベース）だけです。
セッションデータはクリアテキストでブラウザに送信されます。
ユーザのブラウザを、クッキーを受け付けるようにコンフィグレーションする必要があります。
クッキーベースのセッション永続性を使用するときは、文字列の中でカンマ (,) を使用できません。使用すると、例外が発生します。

クッキーベースのセッション永続性を設定するには、次の手順に従います。

WebLogic 固有のデプロイメント記述子である weblogic.xml の <session-descriptor> 要素の PersistentStoreType パラメータを cookie に設定します。
必要な場合は、PersistentStoreCookieName パラメータを使ってクッキーに名前を設定します。デフォルトは WLCOOKIE です。

安全なクッキー

サービスパック 2 では、sessionCookie を保護するように指定するための新しいパラメータが導入されました。このパラメータを設定すると、クライアントのブラウザは、HTTPS 接続を通してだけクッキーを返送します。この機能は、クッキーの ID が安全であることを保証するするもので、HTTPS だけを使用する Web サイトでのみ使用する必要があります。この機能を有効にすると、HTTP 経由でのセッションクッキーは動作しなくなり、HTTPS 以外を使用する場所にクライアントを渡そうとしても、セッションは送信されません。この機能を使用する場合は、URLRewriting をオフにすることを強くお勧めします。アプリケーションが URL をコード化しようとした場合、セッション ID は HTTP を介して共有されます。この機能を使用するには、weblogic.xml に以下のコードを追加してください。

<session-param>
<param-name>CookieSecure</param-name>
<param-value>true</param-value>
</session-param>
<session-param>

URL 書き換えの使い方

状況によっては、ブラウザまたは無線デバイスがクッキーを受け入れないこともあります。この場合、クッキーによるセッショントラッキングを行うことができません。URL 書き換えを使用すると、ブラウザがクッキーを受け入れないことを WebLogic Server が検出したときに、こうした状況を自動的に置き換えることができます。URL 書き換えでは、セッション ID を Web ページのハイパーリンクにエンコードし、サーブレットはそれらをブラウザに送り返します。ユーザが以後これらのリンクをクリックすると、WebLogic Server は URL アドレスからその ID を抽出し、サーブレットが getSession() メソッドを呼び出すと適切な HttpSession を見つけ出します。

WebLogic Server で URL 書き換えを有効にするには、 URLRewritingEnabled属性を true に設定します。WebLogic 固有のデプロイメント記述子である weblogic.xml の <session-descriptor> 要素に URLRewritingEnabled 属性を設定します（この属性のデフォルト値は、true です）。

URL 書き換えのコーディングに関するガイドライン

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 を組み込むことによって書き換えを行います。セッション ID は URL に付加され、セミコロンで始まります。
WebLogic Server への応答として返される URL に加えて、リダイレクトを送信する URL をエンコードします。次に例を示します。
```
if (session.isNew())
  response.sendRedirect (response.encodeRedirectUrl(welcomeURL));  
```
WebLogic Server はセッションが新しいときには、ブラウザがクッキーを受け入れる場合でも URL 書き換えを使用します。これは、セッションの最初ではサーバはブラウザがクッキーを受け入れるかどうかを判断できないからです。
サーブレットは、HttpServletRequest.isRequestedSessionIdFromCookie() メソッドから返されるブール値をチェックすることによって、特定のセッション ID がクッキーから受け取られたかどうかを確認できます。WebLogic Server アプリケーションは適切に応答するか、WebLogic Server による URL 書き換えに依存します。

URL 書き換えと Wireless Access Protocol（WAP）

WAP アプリケーションを作成する場合、WAP プロトコルはクッキーをサポートしていないため、URL を書き換える必要があります。また、一部の WAP デバイスでは、URL の長さが 128 文字（パラメータも含む）に制限されます。これにより、URL 書き換えによって転送できるデータサイズが制限されます。パラメータ用の領域を増やすために、WebLogic Server によってランダムに生成されるセッション ID のサイズを制限できます。そのためには、 IDLength属性を使用してバイト数を指定します。

WAP 有効化属性を設定すると、余分な領域を節約できます。これによって、WebLogic Server は主情報と副情報を URL と共に送信しなくなります。WAP 有効化属性は、Administration Consoleで、[サーバ｜コンフィグレーション｜HTTP] タブを選択して設定できます。