この項目では、Hypertext Transfer Protocol (HTTP) セッションの作成または使用に関するトラブルシューティング情報を提供しています。
ここで説明するセッション・マネージャーの設定を表示および更新するには、管理コンソールを使用します。
問題のアプリケーションがホスティングされているアプリケーション・サーバーを選択し、「追加プロパティー」の下の「Web コンテナー」を選択して、次に「セッション・マネージャー」を選択します。
該当する問題がここで説明されていないか、またはこれらのステップで問題が修正できない場合は、以下を行ってください。
HTTP セッションが作成されないか、または要求と要求の間に失われる
デフォルトでは、セッション・マネージャーは Cookie を使用して、要求と要求の間にクライアントにセッション ID を保管します。
Cookies ベースのセッション・トラッキングを回避する場合以外は、以下のようにして、Cookies が WebSphere Application Server とブラウザーの間を流れていることを確認します。
- 「セッション・トラッキング・メカニズム」プロパティーの下の「Cookie を使用可能にする」チェック・ボックスにチェックマークを付けてください。
- テストを実施するブラウザー、またはユーザーがアプリケーションにアクセスしているブラウザーで Cookies が使用可能になっていることを確認します。
- 「SessionManager」で指定されている Cookies ドメインをチェックします
(Cookies の設定を表示または更新する場合は、
「セッション・トラッキング・メカニズム」->「Cookies を使用可能にする」プロパティーで、
「変更」をクリックします)。
- 「SessionManager」で指定されている「Cookie パス」をチェックします。問題の URL が、指定された Cookie パスよりも階層的に下になっていることをチェックしてください。このようになっていない場合は、Cookie パスを訂正します。
- Cookie maximum age プロパティーが設定されている場合は、クライアント (ブラウザー) マシンの日付と時刻が、時間帯を含めてサーバーの日付と時刻と同じであることを確認します。クライアントとサーバーの時間の差が「Cookie 最大経過時間」よりも大きい場合は、その Cookie はアクセス後に「期限切れ」になるため、すべてのアクセスは新規セッションになります。
- エンタープライズ・アプリケーション内にセッションを追跡する複数の Web モジュールがある場合は、以下のようにします。
- エンタープライズ・アプリケーション内の各 Web モジュールで異なるセッションの設定を使用する場合は、各 Web モジュールで異なる Cookie 名またはパスを指定するようにします。
- エンタープライズ・アプリケーション内の Web モジュールが共通の Cookie 名とパスを使用している場合は、Cookie の最大経過時間などの HTTP セッションの設定がすべての Web モジュールで同じになるようにしてください。
これを行なわないと、Cookie の振る舞いは予測不能となり、
そのセッションを作成したアプリケーションによって異なるようになります。
このことは、セッション・データには影響を与えないことに注意してください。セッション・データは、Web モジュールによって個別に保守されています。
- 以下のようにして、ブラウザーとサーバーの間の Cookie の流れをチェックします。
- ブラウザーで「Cookie プロンプト」を使用可能にします。サーブレットをヒットし、Cookie が要求されることを確認します。
- サーバーで SessionManager のトレースを使用可能にします。トレース指定「com.ibm.ws.webcontainer.httpsession.*=all=enabled」を使用して、
HTTP セッション・マネージャー・コンポーネントに対して
トレースを使用可能にします。
トレースが使用可能になった後、セッションを使用するサーブレットまたは JSP を実行して、トレース出力のダンプと参照のための指示に従ってください。
- ブラウザーからセッション・サーブレットにアクセスします。
- ブラウザーは Cookie を要求します。jsessionid をメモしておいてください。
- サーブレットを再ロードし、新規の Cookie が送信されてきた場合は、前の Cookie を書き留めておきます。
- セッション・トレースをチェックして、セッション ID を探し、スレッドにより要求をトレースします。以下のようにして、Web 要求の間でセッションが継続していることを確認します。
- セッション要求の開始である getIHttpsession(...) を探します。
- サーブレット要求の終わりである releaseSession(..) を探します。
- Cookies ではなく URL の再書き込みを使用している場合は、以下のようにします。
- アプリケーションのナビゲーション・パスに静的な HTML ページが存在していないことを確認します。
- サーブレットおよび JSP ファイルが URL の再書き込みを正しく実装していることを確認します。
詳細および例については、セッション・トラッキング・オプション
を参照してください。
- SSL をセッション・トラッキング・メカニズムとして使用している場合は、以下のようにしてください。
- IBM HTTP Server または iPlanet HTTP サーバーで SSL が使用可能になっていることを確認します。
- セッション・トラッキング・オプション
を参照してください。
同一のクライアント・マシン上の複数のブラウザーでセッションが共用される
この振る舞いは、ブラウザーに依存します。
ブラウザーは、ブラウザーのベンダーによって異なり、ブラウザーが新規のプロセスとして起動されるか、または既存のブラウザー・セッションのサブプロセスとして起動されるか (例えば、Windows の場合は Ctl-N を押します) に応じて変化します。
Cookie がセッション・トラッキング・メカニズムとして使用されている場合は、セッション・マネージャーの Cookie の最大経過時間プロパティーもこの振る舞いに影響を与えます。
最大経過時間が正の値に設定されている場合、すべてのブラウザー・インスタンスで Cookies が共用されます。Cookie は、指定された最大経過時間の間、クライアント側のファイルで永続化されます。
指定されたセッションのタイムアウト間隔の経過後、セッションが即時に無効にならない
SessionManager の無効化プロセスのスレッドは x 秒ごとに実行され、無効なセッションを無効化します。この場合、x は、セッション・マネージャーのプロパティーで指定されたセッション・タイムアウト間隔に基づいて決定されます。
デフォルト値が 30 分の場合は、x はおよそ 300 秒になります。この場合は、特定のセッションが無効化されるまでに、30 分のタイムアウトしきい値を超えてから最大 5 分 (300 秒) かかります。
不要なセッションが JavaServer Pages によって作成される
JavaServer Pages (JSP) 仕様によって、JSP ページは、デフォルトでは request.getSession(true) を実行します。その結果、そのクライアントにセッションが存在していない場合はセッションが作成されます。
JSP ページが新規のセッションを作成することを防ぐには、以下のようにページ・ディレクティブを使用して、
.jsp ファイルのセッションの有効範囲を
false に設定します。
<% @page session="false" %>
1 つのクライアント用のセッション・データが、別のクライアントにも表示される
まれに、アプリケーション・エラーが原因で、1 つのクライアント用のセッション・データが別のクライアントにも表示されることがあります。
この状態は、セッション・データ・クロスオーバーと呼ばれます。
DebugSessionCrossover カスタム・プロパティーが
true に設定されていると、セッション・データ・クロスオーバーのインスタンスを検出し、記録するのにコードを使用できます。
要求に関連するセッションのみがアクセスされるか、または参照されていることを確認するために検査が実行されます。
矛盾が検出されると、メッセージがログに記録されます。
これらのメッセージを使用して、この問題のデバッグを開始します。
この追加チェックは、ユーザーが作成したスレッドではなく、WebSphere 管理のディスパッチ・スレッドで
実行されている場合にのみ行われます。
このプロパティーの設定方法についての追加情報は、
Web コンテナーのカスタム・プロパティー
の項目を参照してください。
Enterprise JavaBeans (EJB) 参照を含むセッションのフェイルオーバー中に ClassCastException 例外が発生する
WebSphere® Application Server for z/OS® バージョン 6.0.1 を実行して、
EJB 参照を複製するようにセッション・マネージャーを構成した場合は、
セッション・フェイルオーバーにより、サーバー領域ジョブ・ログで、以下の例外の表示がトリガーされる
場合があります。
java.lang.ClassCastException: cannot cast class
org.omg.stub.java.rmi._Remote_Stub to interface javax.ejb.EJBObject
このログでは、NULL ポインター例外も表示されます。
この問題は、WebSphere Application Server for z/OS が C9C21355 マイナー・コードとともに CORBA::COMM_FAILURE 例外を発行しているセッション・アウトバウンド要求が原因で発生します。
この振る舞いが発生するのは、ご使用のアプリケーション・サーバーに以下のすべての構成が含まれているためです。
- SAF がユーザー・レジストリーであるとともにローカル・オペレーティング・システムになっています。
- 属性の伝搬が有効になっています。
- 非認証ユーザーがセッション・アウトバウンド要求を開始しています。
この問題を訂正するには、APAR PK06777 修正を WebSphere Application
Server for z/OS V6.0.1 に適用します。
前述のサーバー構成を維持することもできます。
HTTP セッションのタイマーが
期限切れになると、ユーザーがログアウトされない
WebSphere Application Server の
ユーザーがアプリケーションにログオンし、指定された HTTP セッション・タイムアウト値を超えて
アイドル状態を続けた場合、ユーザー情報は無効にならず、LTPA トークンがタイムアウトになるまで
ユーザー・クレデンシャルはアクティブのままです。
PK25740 の適用後、
以下のステップを実行すると、HTTP セッションが期限切れとなった後に
ユーザーをアプリケーションからログアウトさせることができます。
- 管理コンソールで、「セキュリティー」>「管理、アプリケーション、およびインフラストラクチャーの保護
」とクリックします。
- 「カスタム・プロパティー」で「新規」をクリックします。
- 「名前」フィールドに、com.ibm.ws.security.web.logoutOnHTTPSessionExpire と入力します。
- 「値」フィールドに true と入力します。
- 「適用」および「保管」をクリックして、構成の変更を保管します。
- サーバーを再同期して再始動します。
IBM からのトラブルシューティングのヘルプ
の説明のとおり、IBM サポートが提供する資料およびツールを利用することによって、問題の解決に必要な情報収集の時間が節約できます。
問題報告書を開く前に、以下のサポート・ページを参照してください。