―BEA WebLogic Server編―
| WebLogic Serverのセッション管理（応用編） |
 |
3. セッションのタイムアウト |
セッションのタイムアウト時間は次のプロパティで設定することができます(*3)。() 内はデフォルト値です。
|
weblogic.httpd.session.timeoutSecs (3600)
|
セッション・オブジェクトの有効期限（秒単位）を設定します。この時間アクセスのないセッション・オブジェクトはサーバのパトロール処理によって自動的に無効化されます。
Web Applicationでは、デプロイメント・ディスクリプタ（web.xml）でもセッションのタイムアウト時間を設定することができます。ただし、web.xmlで設定するタイムアウト時間は分単位ですので注意してください。
|
<session-config> |
タイムアウトした、あるいは無効化(invalidate)されたセッション・オブジェクトのチェックを行うパトロール処理のインターバルを、秒単位で指定します。例えば以下のように指定します。
|
weblogic.httpd.session.invalidationIntervalSecs
(60) |
セッションのタイムアウト時に、セッションで保持しているオブジェクトの後始末を行いたい場合があります。これを行うには、javax.servlet.http.HttpSessionBindingListener インターフェイスを利用します。このインターフェイスを実装したオブジェクトを HttpSessionにsetAttribute()すると、オブジェクトのvalueBound()が呼び出されます。同様に、removeAttribute()するとvalueUnbound()が呼び出されます。
|
public interface HttpSessionBindingListener |
valueUnbound()はセッションがタイムアウトした場合にも呼び出されるので、タイムアウト時の後処理をvalueUnbound()メソッド内に記述しておけばよいわけです。タイムアウト時のvalueUnbound()は、invalidationIntervalSecsで説明したパトロール処理のタイミングで呼び出されます。
このHttpSessionBindingListenerインターフェイスの呼び出しには、長い間クラスタ環境下で不具合があったのですがSP9でようやく改修される予定です。
次回は「Web Applicationのデプロイメント」と題して、web.xmlやweblogic.xml について今度はWebLogic
Server 6.0ベースで解説する予定です。
 |
本稿に関するご質問やご意見は下記のメールアドレスまでお願いします。
|
|||||||||||||||||||||||||||||||||||||||||
脚注：WebLogic Server 6.0での変更点
(*1) 前回、Cookieの場合session id名が “JSESSIONID” になったと説明しましたが、URL rewriting の場合 session id はリクエスト・パラメータとしてではなく、servlet 2.2 仕様に準拠した、';'をセパレータに“jsessionid”という名前でエンコードされるようになりました。
|
/order/Submit.jsp;jsessionid=OqXn3Ab9!-3044480099678014536!-926997315!7001!7002!-2679308213499512072!-926997316!7001!7002 |
このため、formでmethod="get"を使用する場合もsession idをhidden fieldで渡す必要がなくなりました。つまり、以下のように素直に encodeURL()を使用すればよいわけです。
|
<form action="<%= response.encodeURL
(request.getContextPath () + "/order/Submit.jsp") %>"
method="get"> |
(*2) クラスタの設定は、管理サーバ(Administration Server)上で一括して管理されるようになりました。
(*3) このようなセッション関係の設定はすべてweblogic.xml(WebLogic Server固有のWeb
Applicationデプロイメント・ディスクリプタ)で行うよう変更されています（http://www.beasys.co.jp/e-docs/wls60e/programming/weblogic_xml.html）。
(*4) Webサーバの代わりに、スティッキング機能を備えたスイッチやロード・バランサーなどのハードウェアを前に立ててクラスタリングさせることもできるようになりました
(in-cluster routing)。
(*5) (*1)のエンコードされたURLの例はクラスタリングした場合のものですが、5.1に比べコンパクト(クラスタ情報だけで約85bytes)になったのがお分かりいただけると思います。
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
