Cosminexus　機能解説

[目次][用語][索引][前へ][次へ]

7.5.1　更新検知とリロードの概要

リロード機能は，展開ディレクトリ形式のJ2EEアプリケーションを使用している場合に使用できます。リロード機能を使用することで，J2EEサーバを再起動することなく，デプロイ済みのサーブレット，JSPやEJB-JARを動的に入れ替えられるようになります。

また，リロード機能を使用する場合には，通常のJ2EEアプリケーションの入れ替えで必要となる，入れ替え前のJ2EEアプリケーションの停止と削除，入れ替えるJ2EEアプリケーションのインポートとデプロイなどの手順が不要になります。このため，通常のJ2EEアプリケーションの入れ替えに比べて，少ない手順で入れ替えができるようになります。J2EEアプリケーションの入れ替えについては，「19.6.1　J2EEアプリケーション入れ替えの概要」を参照してください。

＜この項の構成＞
(1)　J2EEアプリケーションのリロード方法
(2)　リロードの適用範囲
(3)　リロード時のクラスローダの構成
(4)　エラー発生時の動作
(5)　リロードの注意事項および制限事項

(1)　J2EEアプリケーションのリロード方法

J2EEアプリケーションのリロードには，更新検知によるリロードと，コマンドによるリロードの2種類の方法があります。

(a)　更新検知によるリロード

更新検知によるリロードは，J2EEアプリケーション開発時のテストを支援する機能として利用できます。更新検知によるリロードを次の図に示します。

図7-6　更新検知によるリロード

[図データ]

展開ディレクトリ形式のJ2EEアプリケーションを構成するEJBアプリケーション（EJB-JAR）やWebアプリケーション（WAR）が更新された場合に，J2EEサーバがJ2EEアプリケーションの更新を検知し，更新後のEJB-JARやWARを自動的にリロードします。

J2EEサーバは，J2EEアプリケーションの構成ファイルを定期的に監視し，構成ファイルの更新を検知すると，J2EEアプリケーションのリロードを実行します。J2EEアプリケーションの更新からリロードまでの処理の流れを次の図に示します。

図7-7　更新検知によるリロードの処理の流れ

[図データ]

図中の1.〜10.について説明します。

  1. J2EEアプリケーションの構成ファイルを更新します。
    展開ディレクトリ形式のJ2EEアプリケーションを構成するEJB-JARやWARを更新します。
  2. J2EEサーバがJ2EEアプリケーションの構成ファイルの更新を検知します。
    • J2EEサーバは，J2EEアプリケーションの構成ファイルを定期的に監視していて，構成ファイルが更新されると更新を検知します。J2EEアプリケーションの構成ファイルを監視して更新を検知する間隔は，更新検知インターバルとして設定します。更新検知インターバルについては，「7.5.3　J2EEアプリケーションの更新検知インターバル」を参照してください。
    • 更新を検知したあと，更新するファイルをロードします。このとき，ファイルのコピー中にロードが開始されてしまい，ロードに失敗することがあります。これを回避するため，構成ファイルの更新を検知してから処理中のリクエスト数の監視を開始するまでの時間を構成ファイル更新用インターバルとして設定しておくことができます。構成ファイル更新用インターバルについては，「7.5.4　J2EEアプリケーションの構成ファイル更新用インターバル」を参照してください。
    • JSPを更新した場合には，JSPの再コンパイル，またはクラスファイルの監視によって更新が検知されます。JSPのリロードについては，「7.5.6　JSPのリロード」を参照してください。
  3. リクエスト処理を閉塞します。
    構成ファイルの更新を検知し，構成ファイル更新用インターバルで指定した時間を経過すると，J2EEアプリケーションのリロードを実行するためにリクエスト処理を閉塞します。
    • EJBアプリケーション（EJB-JAR）の場合
      新規リクエストが来たらエラーを返します。処理中のリクエストがある場合には，処理を続行します。ただし，Stateless Session Beanの場合は，CTMを使用することで，新規リクエストを実行待ちにできます。
    • Webアプリケーション（WAR）の場合
      新規リクエストが来たら実行待ちになります。処理中のリクエストがある場合には，処理を続行します。このとき，リロード遅延実行機能を使用すると，リロードの開始処理を遅らせることができます。リロード遅延実行については，「7.5.5(1)　Webアプリケーションのリロード遅延実行」を参照してください。
      参考
      処理中のリクエストの処理が完了しない場合には，J2EEアプリケーション実行時間の監視のメソッドタイムアウトおよびメソッドキャンセルを実行することで，リロード処理を開始できます。リロードとJ2EEアプリケーション実行時間の監視との関係については，「7.5.7(2)　リロードとJ2EEアプリケーション実行時間の監視との関係」を参照してください。
  4. J2EEアプリケーションの終了処理をします。
    リロードを実行するために，J2EEアプリケーションを終了します。終了処理では，次の処理が実施されます。
    • リロード前のクラスローダにローディングされたサーブレットのインスタンスが破棄されます。サーブレットがdestroyメソッドを実装している場合，destroyメソッドが実行されます。また，JSPファイルから生成されたサーブレットのインスタンスも破棄されます。このとき，JSPファイルがjspDestroyメソッドを実装していると，jspDestroyメソッドが実行されます。
    • javax.servlet.ServletContextに登録されたオブジェクトは破棄されます。
    • リロード前のクラスローダにローディングされたEJBのインスタンスが破棄されます。このとき，次のEJBのコールバックメソッドが実行されます。
      分類 実行されるメソッド
      Stateless Session Beanの場合 ejbRemove
      PreDestroy
      Stateful Session Beanの場合 ejbRemove
      PreDestroy
      Entity Beanの場合 unsetEntityContext
      Message-driven Beanの場合 ejbRemove
  5. セッション情報をシリアライズし，セッション情報ファイルに出力します。
    Webアプリケーションをリロードする場合は，リロード実行前に生成したセッション情報を，リロード後も継続して利用できます。セッション情報の引き継ぎについては，「7.5.5(2)　Webアプリケーションのリロード時のセッション情報の引き継ぎ」を参照してください。
  6. J2EEアプリケーション単位のクラスローダを新規に作成します。
    J2EEアプリケーションのリロード処理が実行されると，J2EEアプリケーション単位のクラスローダが新たに作成され，リロード後のリクエスト処理で使用されます。
  7. セッション情報ファイルからセッション情報を読み込み，デシリアライズします。
    Webアプリケーションをリロードする場合は，セッション情報ファイルに出力されたセッション情報を新しいクラスローダに読み込みます。
  8. セッション情報ファイルを削除します。
  9. J2EEアプリケーションの開始処理をします。
    • リロード後は，初回アクセス時に更新後のサーブレットのインスタンスが作成され，initメソッドが実行されます。
    • 開始処理では，プールの最小値分のEJBを生成してプーリングします。このとき，次のEJBのコールバックメソッドが実行されます。
      分類 実行されるメソッド
      Stateless Session Beanの場合 setSessionContext
      ejbCreate
      PostConstruct
      Entity Beanの場合 setEntityContext
      Message-driven Beanの場合 setMessageDrivenContext
      ejbCreate
  10. リクエストの閉塞を解除し，リクエストの処理を再開します。
    3.で実行待ちにしていたリクエストの処理を再開します。
(b)　コマンドによるリロード

コマンドによるリロードは，J2EEアプリケーション開発時のテストを支援する機能，またはシステムの運用時にJ2EEアプリケーションの入れ替えを支援する機能として利用できます。コマンドによるリロードを次の図に示します。

図7-8　コマンドによるリロード

[図データ]

展開ディレクトリ形式のJ2EEアプリケーションを構成するEJBアプリケーション（EJB-JAR）やWebアプリケーション（WAR）を更新した場合に，ユーザがcjreloadappコマンドを実行します。J2EEサーバは，cjreloadappコマンドを契機にJ2EEアプリケーションの更新を検知し，更新後のEJB-JARやWARを自動的にリロードします。

J2EEアプリケーションの更新からリロードまでの処理の流れを次の図に示します。

図7-9　コマンドによるリロードの処理の流れ

[図データ]

図中の1.〜4.について説明します。5.以降の手順については，更新検知によるリロードの場合と同じです。5.以降の手順については，「(a)　更新検知によるリロード」を参照してください。

  1. J2EEアプリケーションの構成ファイルを更新します。
    展開ディレクトリ形式のJ2EEアプリケーションを構成するEJB-JARやWARを更新します。
  2. cjreloadappコマンドを実行します。
  3. cjreloadappコマンドを契機に，J2EEサーバがJ2EEアプリケーションの構成ファイルの更新を検知します。
  4. リクエスト処理を閉塞します。
    J2EEアプリケーションのリロードを実行するためにリクエスト処理を閉塞します。
    • EJBアプリケーション（EJB-JAR）の場合
      新規リクエストが来たらエラーを返します。処理中のリクエストがある場合には，処理を続行します。ただし，Stateless Session Beanの場合は，CTMを使用することで，新規リクエストを実行待ちにできます。
    • Webアプリケーション（WAR）の場合
      新規リクエストが来たら実行待ちになります。処理中のリクエストがある場合には，処理を続行します。
      参考
      処理中のリクエストの処理が完了しない場合には，J2EEアプリケーション実行時間の監視のメソッドタイムアウトおよびメソッドキャンセルを実行することで，リロード処理を開始できます。リロードとJ2EEアプリケーション実行時間の監視との関係については，「7.5.7(2)　リロードとJ2EEアプリケーション実行時間の監視との関係」を参照してください。

(2)　リロードの適用範囲

リロードの対象として指定できるアプリケーションの種類を次の表に示します。

表7-3　リロードの対象として指定できるアプリケーションの種類

アプリケーションの種類 適用の有無 制限事項
EJBアプリケーション（EJB-JAR） Stateless Session Bean △ リロード中の新規リクエストはエラーになります。なお，CTMを利用している場合は，リロード中の新規リクエストは実行待ちになります。
Stateful Session Bean △ リロード中の新規リクエストはエラーになります。また，リロードするとアプリケーションの状態が破棄されるため，アプリケーション開始前の状態になります。
Entity Bean △ リロード中の新規リクエストはエラーになります。
Message-driven Bean △
Webアプリケーション（WAR） サーブレット ○ −
JSP ○ −
ライブラリJAR − ○ −

（凡例）
○：リロードの対象として指定できる
△：リロードの対象として指定できるが，制限事項がある
−：該当しない

リロードの適用範囲は，次の範囲で指定できます。

注　app，web，jspは，usrconf.propertiesのejbserver.deploy.context.reload_scopeキーの指定値です。なお，noneを指定した場合は，リロード機能は無効になります。

appを指定した場合
  • EJBアプリケーションを更新すると，EJBアプリケーション，サーブレット，およびJSPがリロードされます。
  • サーブレットを更新するとサーブレットとJSPがリロードされます。
  • JSPを更新するとJSPがリロードされます。

webを指定した場合
  • サーブレットを更新するとサーブレットとJSPがリロードされ，JSPを更新するとJSPがリロードされます。
  • サーブレットがあってJSPがない場合は，サーブレットだけがリロードされます。JSPがあってサーブレットがない場合は，JSPだけがリロードされます。
  • EJBアプリケーションを更新してもリロードは動作しません。

jspを指定した場合
  • JSPを更新するとJSPがリロードされます。
  • EJBアプリケーションまたはサーブレットを更新しても，リロードは動作しません。

なお，リロード機能の有効／無効は，usrconf.propertiesのejbserver.rmi.localinvocation.scopeキーで指定するローカル呼び出し最適化機能の適用範囲と，リロード機能の適用範囲の組み合わせによって決まります。ローカル呼び出し最適化機能の適用範囲とリロード機能の適用範囲の対応を次の表に示します。

表7-4　ローカル呼び出し最適化機能の適用範囲とリロード機能の適用範囲の対応

項目 ejbserver.rmi.localinvocation.scopeキーの値
all app none
ローカル呼び出し最適化の範囲 同一J2EEサーバ内となります。 同一アプリケーション内となります。 範囲はありません。
ejbserver.deploy.context.reload_scopeキーの値 app 　×※ ○ ○
web ○ ○ ○
jsp ○ ○ ○
none × × ×

（凡例）○：リロード機能を使用できる　×：リロード機能を使用できない

注※　設定に誤りがあります。ejbserver.rmi.localinvocation.scope=allの場合にejbserver.deploy.context.reload_scope=appを指定すると，J2EEサーバを起動するときにメッセージが出力されて起動に失敗します。


(3)　リロード時のクラスローダの構成

リロード時のクラスローダの構成は，ローカル呼び出し最適化の範囲によって異なります。ローカル呼び出し最適化の範囲とクラスローダの構成の対応を次の表に示します。なお，クラスローダの構成については，「付録H　クラスローダの構成」を参照してください。

表7-5　ローカル呼び出し最適化の範囲とクラスローダの構成の対応

項目 ejbserver.rmi.localinvocation.scopeキー※の値
all app none
ローカル呼び出し最適化の範囲 同一J2EEサーバ内となります。 同一アプリケーション内となります。 範囲はありません。
クラスローダ構成 ローカル呼び出し最適化時のクラスローダ構成になります。 デフォルトのクラスローダ構成になります。 デフォルトのクラスローダ構成になります。

注※　usrconf.propertiesに指定するキーです。


リロード機能では，ApplicationClassLoader以下，またはWebappClassLoader以下のクラスローダを入れ替えます。EJB-JARをリロードする場合，デフォルトのクラスローダ構成で，次のファイルをロードします。

EJB-JARをリロードするためにApplicationClassLoaderを入れ替える場合は，下位にあるWebappClassLoader，およびJasperLoaderも入れ替える必要があります。したがって，EJB-JAR，ライブラリJAR，参照ライブラリをリロードする場合は，WARを含めたリロードになります。

(4)　エラー発生時の動作

リロード機能の使用中にエラーが発生した場合の動作を次の表に示します。

表7-6　リロード機能でのエラー発生時の動作

エラーの内容 結果
リロード中（アプリケーション内で処理しているリクエストがない状態）にリクエストがサーバに来た場合 EJB-JARの場合はクライアントにエラーが返ります。WARの場合，新規リクエストはリロードが完了するまで実行待ちとなります。
リロード中に例外が発生した場合（クラスファイルのロードの失敗を含む） 更新検知は停止しないで，アプリケーションを停止します。更新を検知した場合，停止したJ2EEアプリケーションは再び開始されます。
リロード以外の処理（更新チェック中，構成ファイル更新用インターバル中，リロード遅延実行中）で例外が発生した場合 更新検知は停止しないで，J2EEアプリケーションは開始状態のまま監視を続けます。
J2EEアプリケーションのメソッドがハングアップなどで終了しない場合 J2EEアプリケーション実行時間の監視でメソッドをキャンセルしないとリロードできません。また，cjreloadappコマンドを使用しないとリロードできません。
J2EEアプリケーション実行時間の監視については，「7.5.7(2)　リロードとJ2EEアプリケーション実行時間の監視との関係」を参照してください。

(5)　リロードの注意事項および制限事項

リロードに関する注意事項および制限事項を次に示します。

(a)　リロード機能の使用に関する注意事項
(b)　EJBアプリケーション（EJB-JAR）の注意事項
(c)　EJBアプリケーション（EJB-JAR）の制限事項
(d)　Webアプリケーション（WAR）の注意事項

[目次][前へ][次へ]

[他社商品名称に関する表示]

All Rights Reserved. Copyright (C) 2006, 2007, Hitachi, Ltd.