HTTP セッションの問題
Hypertext Transfer Protocol (HTTP) セッションを作成または使用するときの問題に関するトラブルシューティング情報を使用します。
ここで説明するセッション・マネージャーの設定を表示および更新するには、管理コンソールを使用します。 問題のアプリケーションがホスティングされているアプリケーション・サーバーを選択し、「追加プロパティー」の下の「Web コンテナー」を選択して、次に「セッション・マネージャー」を選択します。
- HTTP セッションが作成されないか、または要求と要求の間に失われる
- HTTP セッションがパーシスタントでない
- 同一のクライアント・マシン上の複数のブラウザーでセッションが共有される
- 指定されたセッションのタイムアウト間隔の経過後、セッションが即時に無効にならない
- 不要なセッションが JavaServer Pages によって作成される
1 つのクライアント用のセッション・データが、別のクライアントにも表示される
- HTTP セッションのタイマーが 期限切れになると、ユーザーがログアウトされない
- セッション・パーシスタンスが有効になっている場合にアプリケーションを更新すると、実行時に例外が発生することがある
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- セッション・マネージャー関連の問題のデバッグのための一般的なステップについて、HTTP セッション・マネージャーのトラブルシューティングのヒントを参照してください。
セッション・マネージャーの構成方法、およびそれを使用するためのベスト・プラクティスについて、タスクの概要: HTTP セッションの管理を参照してください。
- 使用可能なオンライン・サポート (ヒント、技術情報、およびフィックス) を参照して、問題が特定され、文書化されているかどうかを確認してください。
- 問題がリストされていない場合は、IBM サポートに連絡してください。
HTTP セッションが作成されないか、または要求と要求の間に失われる
- 「セッション・トラッキング・メカニズム」プロパティーの下の「Cookie を使用可能にする」チェック・ボックスにチェックマークを付けてください。
- テストを実施するブラウザー、またはユーザーがアプリケーションにアクセスしているブラウザーで Cookies が使用可能になっていることを確認します。
- 「SessionManager」で指定されている Cookie ドメインをチェックします
(Cookie の設定を表示または更新する場合は、「変更」をクリックします)。
- 例えば、Cookie ドメインが「.myCom.com」と設定されている場合、そのドメイン・ネームを使用してリソースにアクセスする必要があります。例: http://www.myCom.com/myapp/servlet/sessionservlet
- ドメイン・プロパティーが設定されている場合は、それがドット (.) で始まっていることを確認してください。. Netscape のバージョンによっては、ドメイン・ネームがドットで始まっていないと Cookies を受け付けない場合があります。Internet Explorer は、ドットがあってもドットがなくてもそのドメインを受け入れます。例えば、ドメイン・ネームが mycom.com に設定されている場合は、それを .mycom.com に変更します。これにより、Netscape も Internet Explorer も Cookie を受け入れます。注: サーバーが別のホスト上にある場合は、プラグインを使用している、または Cookie ドメインを設定している Web サーバーなどのフロントエンド・ルーターを構成することにより、セッション Cookie がすべてのサーバーに流れるようにします。
プロパティーで、 - 「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.session.*=all=enabled」を使用して、HTTP セッション・マネージャー・コンポーネントに対してトレースを使用可能にします。トレースを使用可能にした後、セッションを使用するサーブレットまたは JSP を実行し、指示に従ってトレース出力をダンプして参照します。
- ブラウザーからセッション・サーブレットにアクセスします。
- ブラウザーは Cookie を要求します。jsessionid をメモしておいてください。
- サーブレットを再ロードし、新規の Cookie が送信されてきた場合は、前の Cookie を書き留めておきます。
- セッション・トレースをチェックして、セッション ID を探し、スレッドにより要求をトレースします。以下のようにして、Web 要求の間でセッションが継続していることを確認します。
- セッション要求の開始である getIHttpsession(...) を探します。
- サーブレット要求の終わりである releaseSession(..) を探します。
- Cookies ではなく URL の再書き込みを使用している場合は、以下のようにします。
- アプリケーションのナビゲーション・パスに静的な HTML ページが存在していないことを確認します。
サーブレットおよび JSP ファイルが URL の再書き込みを正しく実装していることを確認します。 詳細および例については、セッション・トラッキング・オプションを参照してください。
- SSL をセッション・トラッキング・メカニズムとして使用している場合は、以下のようにしてください。
非推奨の機能 (Deprecated feature): SSL ID を使用したセッションのトラッキングは、 WebSphere Application Server バージョン 7.0 では推奨されません。 セッション・トラッキングを構成して Cookie を使用するか、あるいはアプリケーションを変更して、URL 再書き込みを使用することができます。depfeat
- IBM HTTP Server または iPlanet HTTP サーバーが SSL 対応になっていることを確認します。
セッション・トラッキング・オプションを参照してください。
- クラスター (複数のノード) 環境の場合は、セッション・パーシスタンスが使用可能になっていることを確認します。
HTTP セッションがパーシスタントでない
- データ・ソースを確認します。
- セッション・マネージャーのパーシスタンス設定のプロパティーをチェックします。
- セッション・パーシスタンスを使用したい場合は、 「パーシスタンス」が「データベース」に設定されていることを確認します。
パーシスタンスを「メモリー間の複製」に設定することもできます。
- データベース・ベースのパーシスタンスを使用している場合は、以下のようにします。
- データ・ソースの JNDI 名が SessionManager に正しく設定されているかどうかを確認します。
- データベースにアクセスするための正しいユーザー ID とパスワードを指定します。
これらの設定では、管理コンソールで既存のデータ・ソースのプロパティーと照合する必要があることに注意してください。 セッション・マネージャーでは、セッション・データベースが自動的に作成されません。
- データ・ソースは、非 JTA、例えば 非 XA 対応である必要があります。
JVM ログで該当するデータベース・エラー・メッセージを確認します。
ログで該当するデータベース・エラー・メッセージを確認します。
- DB2® では、4k 以外の行サイズについて、指定された行サイズが DB2 のページ・サイズに一致するかどうかを確認します。 表スペース名が正しく指定されていることを確認します。
- メモリー・ベースのパーシスタンス (Network Deployment 環境でのみ使用可能) を使用している場合は、以下のようにします。
- メモリー間の複製を参照してください。
- セッション・マネージャーの内部複製ドメインのプロパティーを確認してください。
同一のクライアント・マシン上の複数のブラウザーでセッションが共有される
この振る舞いは、ブラウザーに依存します。 ブラウザーの動作は、ブラウザーのベンダーによって異なります。 また、ブラウザーが新規のプロセスとして起動されるか、または既存のブラウザー・セッションのサブプロセスとして起動される (例えば、Windows の場合は Ctl-N を押す、など) かに応じて変化する場合があります。
Cookie がセッション・トラッキング・メカニズムとして使用されている場合は、セッション・マネージャーの Cookie の最大経過時間プロパティーもこの振る舞いに影響を与えます。 最大経過時間が正の値に設定されている場合、すべてのブラウザー・インスタンスで Cookies が共有されます。Cookie は、指定された最大経過時間の間、クライアント側のファイルで永続化されます。
指定されたセッションのタイムアウト間隔の経過後、セッションが即時に無効にならない
SessionManager の無効化プロセスのスレッドは x 秒ごとに実行され、無効なセッションを無効化します。この場合、x は、セッション・マネージャーのプロパティーで指定されたセッション・タイムアウト間隔に基づいて決定されます。 デフォルト値が 30 分の場合は、x はおよそ 300 秒になります。この場合は、特定のセッションが無効化されるまでに、30 分のタイムアウトしきい値を超えてから最大 5 分 (300 秒) かかります。
不要なセッションが JavaServer Pages によって作成される
<% @page session="false" %>
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
1 つのクライアント用のセッション・データが、別のクライアントにも表示される
まれに、アプリケーション・エラーが原因で、1 つのクライアント用のセッション・データが別のクライアントにも表示されることがあります。 この状態は、セッション・データ・クロスオーバーと呼ばれます。 DebugSessionCrossover カスタム・プロパティーが true に設定されていると、セッション・データ・クロスオーバーのインスタンスを検出し、記録するのにコードを使用できます。 要求に関連するセッションのみがアクセスされるか、または参照されていることを確認するために検査が実行されます。 矛盾が検出されると、メッセージがログに記録されます。 これらのメッセージを使用して、この問題のデバッグを開始します。 この追加チェックは、ユーザーが作成したスレッドではなく、WebSphere 管理のディスパッチ・スレッドで 実行されている場合にのみ行われます。
このプロパティーの設定方法についての追加情報は、 Web コンテナーのカスタム・プロパティーの項目を参照してください。
HTTP セッションのタイマーが 期限切れになると、ユーザーがログアウトされない
WebSphere Application Server の ユーザーがアプリケーションにログオンし、指定された HTTP セッション・タイムアウト値より長い時間アイドル状態であった場合、ユーザー情報は無効にならず、LTPA トークンがタイムアウトになるまで ユーザー・クレデンシャルはアクティブのままです。
- 管理コンソールで、「セキュリティー」>「グローバル・セキュリティー」とクリックします。
- 「カスタム・プロパティー」の下で、「新規」をクリックします。
- 「名前」フィールドに、com.ibm.ws.security.web.logoutOnHTTPSessionExpire と入力します。
- 「値」フィールドに true と入力します。
- 「適用」および「保存」をクリックして、構成の変更を保存します。
- サーバーを再同期して再始動します。
セッション・パーシスタンスが有効になっている場合にアプリケーションを更新すると、実行時に例外が発生することがある
実行時にセッション・パーシスタンスを有効にしてアプリケーション更新を実行するユーザーは、アプリケーションの再始動後に予期しない例外を受け取ることがあります。
保存されている属性を変更するような更新が行われた場合、関連するアプリケーションがそれらの変更を処理できないのであれば、 そのアプリケーションによって作成されたすべてのセッションをアプリケーション更新よりも前に無効にしなければならない可能性があります。 この場合、すべてのセッション・オブジェクトをバックエンドからも削除する必要があります。 これらのセッションを適切に削除する方法について詳しくは、『HTTP セッションの無効化』のトピックを参照してください。