3.2.5 スケジュールキューの作成単位とキューの共有
キューは，J2EEアプリケーション単位，またはBean単位で作成できます。ここでは，スケジュールキューの構成と，キューの共有について説明します。また，キューを共有する場合としない場合の利点についても説明します。
(1) スケジュールキューの作成単位
クライアントからのリクエストは，CTMデーモンによって管理されるスケジュールキューによってスケジューリングされます。スケジュールキューは，J2EEアプリケーション単位またはBean単位で作成されます。デフォルトのキュー名称は，J2EEアプリケーション単位の場合はJ2EEアプリケーションの名称，Bean単位の場合はBean名となります。
(2) スケジュールキューの共有
J2EEアプリケーション単位またはBean単位でスケジュールキューを持つことで，異なるインタフェースを持つ業務処理プログラム間，またはJ2EEアプリケーションのBean間でキューを共有できます。なお，スケジュールキューで制御されるリクエストは，「EJBホームリファレンスのグローバルCORBAネーミングサービス登録名称」と「業務処理プログラムのリモートインタフェース名称」の組み合わせで管理されます。
スケジュールキューは，同じCTMデーモンに対応づけられている，次のJ2EEアプリケーション間またはBean間で共有できます。
- J2EEアプリケーション間で共有する場合
-
-
キュー名称が同じである
-
業務処理プログラムの構成が同じである（J2EEアプリケーションに含まれるEnterprise Beanが，CTMが認識する範囲で完全に一致する）
-
- Bean間で共有する場合
-
-
キュー名称が同じである
-
Beanが同じである
-
同じ業務処理プログラム構成でもキュー名称が異なる場合や，同じキュー名称でも異なる業務処理プログラム構成を持つJ2EEアプリケーション間では，スケジュールキューは共有できません。
複数のJ2EEサーバ間でスケジュールキューを共有することもできます。ただし，その場合は，ユーザ指定名前空間機能を使用して，それぞれの業務処理プログラムであるEnterprise Beanに別名（Optional Name）を付与する必要があります。ユーザ指定名前空間機能については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.3 JNDI名前空間へのオブジェクトのバインドとルックアップ」を参照してください。別名の付与は，J2EEアプリケーションのプロパティとして設定します。
- 参考
-
-
デフォルトの設定でJ2EEアプリケーションをインポートすると，業務処理プログラムをルックアップするための名称が「/HITACHI_EJB/SERVERS/＜J2EEサーバ名称＞/EJB/＜J2EEアプリケーション名称＞/＜業務処理プログラムの名称＞」になります。この場合，ルックアップ名称にJ2EEサーバ名称が含まれてしまうため，J2EEサーバ間でスケジュールキューを共有できません。
-
一つのJ2EEサーバ内で複数のJ2EEアプリケーションを同一名称でインポートして，スケジュールキューを共有することはできません。
-
(3) スケジュールキューを共有する効果
スケジュールキューを共有する効果について，J2EEアプリケーション単位での共有と，Bean単位での共有に分けて説明します。
(a) J2EEアプリケーション単位の場合
スケジュールキューを共有すると，複数のJ2EEサーバ上のJ2EEアプリケーションで，リクエストを分散処理できます。
スケジュールキューの共有には，次のような効果があります。
-
キューを共有するJ2EEアプリケーション間で同時実行スレッド数を制御できるので，特定のJ2EEアプリケーションに高い負荷が掛かった時の性能劣化を防げます。これによって，システムとしての処理性能を安定させやすくなります。
-
キューを共有しているどちらかのJ2EEサーバで障害が発生した場合に，縮退運転に切り替え，キューに滞留したリクエストを障害が発生していないJ2EEサーバのJ2EEアプリケーションで処理できます。このため，業務が停止しません。
スケジュールキューを共有する例を次の図に示します。
|
|
![[図データ]](GRAPHICS/ZU030100.GIF)
EJBクライアントからのルックアップは，グローバルCORBAネーミングサービスに対して実行します。スケジュールキューを共有している場合，共有しているキュー（この場合はX）のリファレンスが取得できるので，そのキューに対してcreateを実行します。そこで取得したCTMレギュレータのリファレンスに対してinvokeを実行すると，スケジュールキューXによって，J2EEサーバ1またはJ2EEサーバ2に処理が振り分けられます。
(b) Bean単位の場合
スケジュールキューを共有すると，複数のJ2EEサーバ上のBeanでリクエストを分散処理できます。
スケジュールキューの共有には，次のような効果があります。
-
同一のJ2EEアプリケーション内にあるほかのBeanの影響を受けることなく，J2EEアプリケーション内のBean種別ごとにキューを分けることができます。
-
キューを共有するBean間で同時実行スレッド数を制御できるので，特定のBeanに高い負荷が掛かった時の性能劣化を防げます。これによって，システムとしての処理性能を安定させやすくなります。
-
キューを共有しているどちらかのJ2EEサーバで障害が発生した場合，縮退運転に切り替え，キューに滞留したリクエストを障害が発生していないJ2EEサーバ上のBeanで処理できます。このため，業務が停止しません。
スケジュールキューを共有する例を次の図に示します。
|
|
![[図データ]](GRAPHICS/ZU030200.GIF)
EJBクライアントからのルックアップは，グローバルCORBAネーミングサービスに対して実行します。スケジュールキューを共有している場合，共有しているキュー（この場合はX）のリファレンスが取得できるので，そのキューに対してcreateを実行します。そこで取得したCTMレギュレータのリファレンスに対してinvokeを実行すると，スケジュールキューXによって，J2EEサーバ1またはJ2EEサーバ2上のBean Aに処理が振り分けられます。
(4) スケジュールキューを共有しない効果
スケジュールキューを共有しない場合，異なるJ2EEサーバに同じJ2EEアプリケーションがインポートされていたり，J2EEサーバ上に同じBeanがあったりしても，リクエストはそれぞれのキューで制御され，実行されます。
スケジュールキューを共有しないと，負荷分散や縮退運転はできなくなりますが，異なるスケジュールキューでリクエストが滞留してもその影響を受けなくなるため，優先的に業務処理を進められます。
スケジュールキューを共有しない場合は，それぞれのJ2EEアプリケーションに含まれる業務処理プログラムに別名を指定しないで，それぞれ異なるルックアップ名称にします。
スケジュールキューを共有しない例を次の図に示します。
|
|
![[図データ]](GRAPHICS/ZU030300.GIF)
EJBクライアントからのルックアップは，グローバルCORBAネーミングサービスに対して実行します。スケジュールキューを共有していない場合，指定したJ2EEアプリケーションを制御するキュー（この場合はX）のリファレンスが取得できるので，そのキューに対してcreateを実行します。そこで取得したCTMレギュレータのリファレンスに対してinvokeを実行すると，スケジュールキューXが制御しているJ2EEサーバ1に処理が振り分けられます。