18.8.8 Webアプリケーションのリロード
Webアプリケーションをリロードする場合には，リロード遅延実行機能を使用することで，J2EEアプリケーションのサービス停止期間を最小限に抑えることができます。また，Webアプリケーションのリロードでは，リロード実行前に生成したセッション情報を引き継いで，リロード後も継続して利用することができます。ここでは，Webアプリケーションのリロード遅延実行とセッション情報の引き継ぎについて説明します。
(1) Webアプリケーションのリロード遅延実行
デフォルトでは，構成ファイルの更新を検知すると，次のような手順でリロード処理を実行します。
-
Webアプリケーションのリクエスト処理を閉塞します。
構成ファイルの更新を検知して構成ファイル更新用インターバルで指定した時間を経過すると，処理中のリクエスト数の監視を開始し，次のようにリクエストを処理します。
-
新規リクエスト：実行待ちにします。
-
処理中のリクエスト：処理を続行します。
-
-
処理中のリクエストの処理が完了すると，リロードを実行します。
この場合，処理中のリクエストの処理時間が長くなるほど，新規リクエストの処理開始時間が遅くなり，新規リクエストに対するアプリケーションのサービス停止期間が長くなります。これを回避するために，リロード遅延実行を設定しておくことをお勧めします。リロード遅延実行機能を使用すると，処理中のリクエストの実行待ち時間を減らして，アプリケーションのサービス停止期間を最小限に抑えられます。
リロード遅延実行機能では，この機能を使用するかどうか，およびリロード処理を開始するまでの時間（最大遅延時間）を設定します。リロード遅延実行機能を使用すると，処理中のリクエストの処理が終わるまで，新規リクエストを受け付けることができます。処理中のリクエスト数が0になると，リロード処理を開始して新規リクエストを実行待ちにします。ただし，処理中のリクエスト数が0になるかどうかは，アクセス状況に依存します。リクエストが途切れない場合には，リロード処理を開始できません。このような場合には，構成ファイルの更新を検知してから，新規リクエストを実行待ちにするまでの最大遅延時間を設定します。最大遅延時間を経過すると，それ以降の新規リクエストは実行待ちとなり，処理中のリクエストの処理が完了するのを待ってリロード処理を開始します。
リロード遅延実行を設定した場合と設定しない場合の，アプリケーションのサービス停止期間の違いを，次の図に示します。
|
|
![[図データ]](GRAPHICS/ZU091300.GIF)
リロード遅延実行の最大遅延時間を設定している場合には，構成ファイルの更新を検知して構成ファイル更新用インターバルで指定した時間を経過すると，処理中のリクエスト数の監視を開始し，リロード遅延実行の最大遅延時間のカウントを開始します。例えば，最大遅延時間を5分と設定していた場合，アクセス状況によってリロード処理の開始時間が次のように異なります。
-
最大遅延時間を経過する前に処理中のリクエストが0になった場合
最大遅延時間のカウントを開始してから3分後に，処理中のリクエストが0になった場合には，その時点でリロード処理を開始します。また，新規リクエストを実行待ちにします。
-
最大遅延時間を経過した場合
リクエストが途切れないため処理中のリクエストが0にならない場合には，最大遅延時間のカウントを開始してから5分後に，新規リクエストを実行待ちにします。処理中のリクエストの処理が完了したら，リロード処理を開始します。
- 参考
-
処理中のリクエストの処理が完了しない場合には，J2EEアプリケーション実行時間の監視のメソッドタイムアウトおよびメソッドキャンセルを実行することで，リロード処理を開始できます。J2EEアプリケーション実行時間の監視については，「18.8.10(2) リロードとJ2EEアプリケーション実行時間の監視との関係」を参照してください。
(2) Webアプリケーションのリロード時のセッション情報の引き継ぎ
Webアプリケーションをリロードする場合は，リロード実行前に生成したセッション情報を引き継いで，リロード後も継続して利用します。
(a) セッション情報ファイル
Webアプリケーションをリロードする場合，セッション情報（javax.servlet.http.HttpSessionオブジェクトに登録したオブジェクト）をシリアライズし，セッション情報ファイルに出力します。セッション情報ファイルからセッション情報を読み込み，リロード後のクラスローダ上でデシリアライズします。なお，シリアライズ処理，およびデシリアライズ処理の時間は，リロードを実行しているWebアプリケーション上で生成されたセッション数，javax.servlet.http.HttpSessionオブジェクトに登録したオブジェクトの容量などに依存します。
- 注意事項
-
シリアライズ対象となるセッションに登録したオブジェクトのクラス，およびそこから参照されるオブジェクトのクラスを，デシリアライズできない構成に更新してリロードを実行した場合，セッションのデシリアライズに失敗します。デシリアライズに失敗すると，Webアプリケーション上のすべてのセッション情報が破棄されます。
セッション情報ファイルは，リロード処理開始時に作成され，リロード処理完了時に削除されます。リロード実行時にセッションが存在しない場合でもセッション情報ファイルは作成されます。
セッション情報ファイルには，Webコンテナが自動生成する情報（2キロバイト）とセッション情報が出力されます。セッション情報は，セッション数とセッションに登録したセッション情報（オブジェクト）に依存します。
セッション情報ファイルのファイル容量は，リロード時に出力されるシリアライズ処理完了のメッセージからファイル容量を確認し，セッション数に応じて算出してください。シリアライズ処理完了時のメッセージの出力例を次に示します。
KDJE39168-I The serialization of session objects has finished. (J2EE application = app1, context root = /examples, number of sessions = 10, session information file size(byte) = 12345)
この出力例では，コンテキストルート名が「examples」のWebアプリケーション「app1」上に10個のセッションがあり，セッション情報ファイルのサイズは，12,345バイトです。
(b) セッション情報を引き継ぐ場合の注意事項
-
リロード時のセッション引き継ぎ機能を使用する場合，javax.servlet.http.HttpSessionに登録するセッション情報は，シリアライズできるオブジェクトである必要があります。
-
HttpSessionオブジェクトに登録したオブジェクトから参照するオブジェクトは，transientで宣言されているか，またはシリアライズできるオブジェクトである必要があります。以降，参照するオブジェクトも同様です。シリアライズできるオブジェクトについての詳細は，J2SEの仕様書を参照してください。
-
セッション情報としてシリアライズできないオブジェクトを登録した場合は，エラーが発生します。エラーの内容はオブジェクトによって異なります。
-
javax.servlet.http.HttpSessionに登録したオブジェクトの場合
HttpSessionオブジェクトに登録したオブジェクトが，シリアライズできないオブジェクトである場合，該当するオブジェクトだけを破棄します。破棄されたオブジェクトは，リロードが完了したあとに使用することはできません。また，該当するオブジェクトが，javax.servlet.http. HttpSessionBindingListenerインタフェースを実装していても，Webコンテナからアンバインドされたイベントは通知されません。
-
javax.servlet.http.HttpSessionに登録したオブジェクトから参照されるオブジェクトの場合
HttpSessionに登録したオブジェクトから参照されるオブジェクトがシリアライズできないオブジェクトの場合，すべてのセッション情報が破棄されます。HttpSessionに登録したオブジェクトから参照されるオブジェクトが，HttpSessionに登録したオブジェクトの場合も同様に，すべてのセッション情報が破棄されます。
-