WebLogic Server Web アプリケーションの開発
![]() |
![]() |
![]() |
![]() |
この章では、セッションとセッションの永続性を設定する方法について説明します。
セッション トラッキングを使用すると、複数のサーブレットか HTML ページにわたって、本来はステートレスであるユーザの状況を追跡できます。セッションの定義は、ある一定期間中に同じクライアントから出される一連の関連性のあるブラウザ リクエストです。セッション トラッキングは、ショッピング カート アプリケーションのように、全体として何らかの意味を持つ一連のブラウザ リクエスト (これをページと見なす) を結合します。
WebLogic Server は、デフォルトによってセッション トラッキングを処理するよう設定されています。セッション トラッキングを使用する際にプロパティを設定する必要はありません。ただし、WebLogic Server がどのようにセッションを管理するかをコンフィグレーションすることは、最高のパフォーマンスを実現するためにアプリケーションをチューニングするときの重要な鍵となります。セッション管理を設定するときは、次のような要素を決定します。
HTTP セッションのデータを永続的に格納することもできます。「セッションの永続性のコンフィグレーション」を参照してください。
デプロイメント記述子の編集については、「Web アプリケーションのデプロイメント」の「デプロイメント記述子」を参照してください。
WebLogic Server のセッション トラッキングは、WebLogic 固有のデプロイメント記述子である weblogic.xml
にプロパティを定義することによってコンフィグレーションします。セッション属性の全リストについては、「session-descriptor」を参照してください。
WebLogic Server 7.0 では、SessionID の形式が変更されたことで、ロード バランサがセッションの固定を保持できなくなっていました。
新しいサーバ起動フラグ (-Dweblogic.servlet.useExtendedSessionFormat=true) に、ロード バランシング アプリケーションがセッションを固定するために必要な情報が保持されるようになりました。URL の書き換えがアクティブになっていると、拡張されたセッション ID の形式は URL の一部になり、起動フラグが true に設定されます。
HTTP セッションが期限切れになるまでの間隔を指定できます。セッションが期限切れになると、そのセッションに格納されたデータは破棄されます。この間隔は、次のとおり web.xml または weblogic.xml に設定できます。
weblogic.xml
の session-descriptor 要素の TimeoutSecs
属性を設定します。この値は秒単位で設定します。詳細については、「session-descriptor」を参照してください。web.xml
で session-timeout 要素を設定します。詳細については、「session-config」を参照してください。WebLogic Server は、クッキーがクライアント ブラウザによってサポートされる場合、クッキーを使用してセッション管理を行います。
WebLogic Server がセッション トラッキングに使用するクッキーは、デフォルトによって一時的なものとして設定されているため、セッションより長く存続することはありません。ユーザがブラウザを終了すると、クッキーは失われ、セッションが終了します。この動作はセッションの用途の基本であり、このようにセッションを使用することをお勧めします。
クッキーのセッション トラッキング属性は、WebLogic 固有のデプロイメント記述子である weblogic.xml
でコンフィグレーションできます。セッションとクッキーに関連する属性の全リストについては、「session-descriptor」を参照してください。
長時間存続するクライアントサイド ユーザ データの場合、WebLogic Server アプリケーションは HTTP サーブレット API を介してブラウザに独自のクッキーを作成および設定し、HTTP セッションに関連付けられたクッキーは使用しようとはしません。WebLogic Server アプリケーションがクッキーを使用して特定のマシンのユーザの自動ログインを行う場合、新しいクッキーの存続期間を長く設定します。クッキーは、クライアント マシンだけから送ることができます。WebLogic Server アプリケーションは、そのユーザが複数の場所からアクセスする必要がある場合、サーバにデータを格納する必要があります。
ブラウザ クッキーの存続期間を直接セッションの長さに関連付けることはできません。クッキーがそれに関連付けられているセッションより早く期限切れになった場合、そのセッションは切り離されてしまいます。セッションがそれに関連付けられているクッキーより早く期限切れになった場合、サーブレットはそのセッションを見つけることができません。この場合、新しいセッションは request.getSession(true)
メソッドが呼び出されるときに自動的に割り当てられます。
クッキーの最大存続時間は、weblogic.xml
デプロイメント記述子のセッション記述子にある CookieMaxAgeSecs
属性で設定できます。
ユーザ認証情報は、ユーザのセッション データと、Web アプリケーションの対象となるサーバまたは仮想ホストのコンテキストの両方に格納されます。ユーザのログアウトに多く使われる session.invalidate()
メソッドでは、ユーザの現在のセッションのみが無効になり、ユーザの認証情報は有効なまま、サーバまたは仮想ホストのコンテキストに格納されます。サーバまたは仮想ホストが 1 つの Web アプリケーションのみのホストである場合、実際には session.invalidate()
メソッドでユーザをログアウトします。
複数の Web アプリケーションで認証を使用するときには、複数の Java メソッドと方式を使用できます。詳細については、『WebLogic HTTP サーブレット プログラマーズ ガイド』の「複数のアプリケーションに対するシングル サインオンの実装」を参照してください。
セッションの永続性を使用して、HTTP セッション オブジェクトにデータを永続的に格納し、WebLogic Server のクラスタ全体のフェイルオーバとロード バランシングを有効にします。アプリケーションが HTTP セッション オブジェクトにデータを格納するとき、データをシリアライズ可能にする必要があります。
最初の 4 つについてはここで説明します。インメモリ レプリケーションについては、『WebLogic Server クラスタ ユーザーズ ガイド』の「HTTP セッション ステートのレプリケーション」を参照してください。
ファイル、JDBC、クッキーベース、およびメモリ (単一サーバ、非レプリケート) のセッション永続性には、共通のプロパティがいくつか存在します。以下の節で説明するとおり、各永続性メソッドはそれぞれ独自の属性セットを持っています。これらの属性は、weblogic.xml デプロイメント記述子ファイルの session-descriptor 要素の子要素である session-param 要素の一部です。
この節では、ファイルベースの永続性と JDBC ベースの永続性に共通する属性について説明します。メモリ内に保持されるセッションの数は、WebLogic 固有のデプロイメント記述子である weblogic.xml
の <session-param>
要素で次の属性を定義してコンフィグレーションできます。これらのプロパティは、セッション永続性を使用している場合にだけ適用できます。
メモリ内で一度にアクティブにできるキャッシュされたセッションの数を制限します。同時に大量のアクティブ セッションが発生することが見込まれる場合、これらのセッションでサーバの RAM を満たしたくはありません。仮想メモリとのスワッピングにより、パフォーマンスが低下する可能性があるからです。キャッシュが満杯になると、最も古いセッションは永続ストレージに格納され、必要になったときに自動的に呼び戻されます。永続性を使用しない場合、このプロパティは無視され、メイン メモリに保持可能なセッション数はソフトウェアによって制限されなくなります。デフォルトでは、キャッシュされるセッションの数は 256 です。キャッシュをオフにするには、この数を 0 に設定します。
注意 : CacheSize
は、JDBC およびファイルベースのセッションによって、インメモリ バブル キャッシュを保持する目的にのみ使用されます。他の永続性タイプには適用されません。
WebLogic Server が、タイムアウトの無効なセッションに対してハウスクリーニング チェックを実行してから古いセッションを削除してメモリを解放するまでの待ち時間を秒単位で設定します。この属性は、<session-timeout>
に設定された値より小さい値に設定します。この属性を使用すると、トラフィックの多いサイトで WebLogic Server の動作を最適化できます。
最小値は毎秒 (1) です。最大値は、週に 1 回 (604800 秒) です。この属性を設定しない場合、デフォルトは 60 秒になります。
<session-timeout>
を設定するには、「session-config」を参照してください。
メモリ ベースのストレージを使用する場合、すべてのセッション情報はメモリに格納され、WebLogic Server を終了して再起動すると失われます。メモリ ベース、単一サーバ、非レプリケート永続ストレージを使用するには、weblogic.xml
ファイルの <session-param>
要素にある PersistentStoreType
属性を memory に設定します。
注意 : WebLogic Server を実行するときに十分なヒープ サイズを割り当てないと、負荷がかかったときにサーバのメモリが足りなくなることがあります。
ファイルベースの永続ストレージをセッション用にコンフィグレーションするには、次の手順に従います。
注意 : このディレクトリは手動で作成する必要があります。また、適切なアクセス権限がディレクトリに割り当てられていることを確認する必要があります。
JDBC の永続性は、この目的のために提供されたスキーマを使ってデータベース テーブルにセッション データを格納します。JDBC ドライバを備えたデータベースはすべて使用できます。データベース アクセスは、接続プールを使ってコンフィグレーションします。
JDBC セッションの永続性を利用している場合、WebLogic Server はシステム時間を使用してセッションの有効期間を判別しているため、同じクラスタ内のサーバが実行されているすべてのマシン上のシステム クロックを同期させておく必要があります。
JDBC ベースの永続ストレージをセッション用にコンフィグレーションするには、次の手順に従います。
weblogic.xml
で、<session-descriptor>
要素の PersistentStorePool
プロパティを使用して、JDBC 接続プールが永続ストレージ用に使用されるよう設定します。WebLogic Server Administration Console で定義される接続プールの名前を使用します。wl_servlet_sessions
というデータベース テーブルを設定します。データベースに接続する接続プールは、このテーブルの読み取り/書き込みアクセス権を保有する必要があります。注意 : データベースで自動的に作成されない場合は、wl_id
および wl_context_path
にインデックスを作成します。一部のデータベースでは、主キーのインデックスが自動的に作成されます。
Oracle DBMS を使用している場合、次の SQL 文を使って wl_servlet_sessions
テーブルを作成できます。この SQL 文をユーザの DBMS に合わせて変更します。
コード リスト 4-1Oracle 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) );
注意 : ユーザは、JDBCConnectionTimeoutSecs
属性を使用して、JDBC セッション永続性がセッション データのロードに失敗するまで、接続プールからの JDBC 接続を待つ最大の期間をコンフィグレーションできます。詳細については、「JDBCConnectionTimeoutSecs」を参照してください。
SqlServer2000 を使用している場合、次の SQL 文を使って wl_servlet_sessions
テーブルを作成できます。この SQL 文をユーザの DBMS に合わせて変更します。
コード リスト 4-2SqlServer 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 が変換されます。たとえば、コード リスト 4-1 に示した SQL は、Pointbase では次のように変換されます。
コード リスト 4-3Pointbase での 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
クッキーベースのセッション永続性は、ユーザのブラウザのクッキーにすべてのセッション データを格納することで、セッション永続性のステートレスなソリューションを提供します。クッキーベースのセッション永続性が最も役に立つのは、セッションに大量のデータを格納する必要がないときです。クッキーベースのセッション永続性は、クラスタ フェイルオーバ ロジックが必要ないので、WebLogic Server のインストール環境をより簡単に管理できます。セッションが格納されるのはブラウザ内であって、サーバ上ではありません。WebLogic Server の起動と停止は、セッションを失わずに行うことができます。
クッキーベースのセッション永続性には、次に示すいくつかの制限事項があります。
IllegalArgument
例外が送出されます。javax.servlet.ServletResponse.setBufferSize()
メソッドで変更できます。クッキーベースのセッション永続性を設定するには、次の手順に従います。
状況によっては、ブラウザまたは無線デバイスがクッキーを受け入れないこともあります。この場合、クッキーによるセッション トラッキングを行うことができません。URL 書き換えを使用すると、ブラウザがクッキーを受け入れないことを WebLogic Server が検出したときに、こうした状況を自動的に置き換えることができます。URL 書き換えでは、セッション ID を Web ページのハイパーリンクにエンコードし、サーブレットはそれらをブラウザに送り返します。ユーザが以後これらのリンクをクリックすると、WebLogic Server は URL アドレスからその ID を抽出し、サーブレットが getSession()
メソッドを呼び出すと適切な HttpSession
を見つけ出します。
WebLogic 固有のデプロイメント記述子である weblogic.xml
の <session-param>
要素に URLRewritingEnabled
属性を設定することで、URL 書き換えを有効にします (この属性のデフォルト値は、
true
です)。「URLRewritingEnabled」を参照してください。
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 を書き換えます。
if (session.isNew())
response.sendRedirect (response.encodeRedirectUrl(welcomeURL));
WebLogic Server はセッションが新しいときには、ブラウザがクッキーを受け入れる場合でも URL 書き換えを使用します。これは、セッションの最初ではサーバはブラウザがクッキーを受け入れるかどうかを判断できないからです。
HttpServletRequest.isRequestedSessionIdFromCookie()
メソッドから返されるブール値をチェックすることによって、特定のセッション ID がクッキーから受け取られたかどうかを確認できます。WebLogic Server アプリケーションは適切に応答するか、WebLogic Server による URL 書き換えに依存します。WAP アプリケーションを作成する場合、WAP プロトコルはクッキーをサポートしていないため、URL を書き換える必要があります。
また、一部の WAP デバイスでは、URL の長さが 128 文字 (属性も含む) に制限されます。これにより、URL 書き換えによって転送できるデータ サイズが制限されます。属性用の領域を大きくするために、WebLogic Server でランダムに生成されるセッション ID のサイズを制限できます。
WAPEnabled
属性を使用するには、Administration Console の [サーバ|プロトコル|HTTP|詳細オプション] ページで指定します。WAPEnabled
属性を使用することで、セッション ID のサイズを 52 文字までに制限し、! や # などの特殊文字の使用を禁止できます。また、weblogic.xml の IDLength パラメータを使うと、セッション ID のサイズをさらに制限できます。詳細については、「IDLength」を参照してください。
![]() ![]() |
![]() |
![]() |