タイマー・サービスに対するクラスター環境の考慮事項

単一サーバー環境では、どのサーバー・インスタンスが、指定された Bean に対して Bean のタイムアウト・メソッドを呼び出すかは明確です。 マルチサーバー・クラスター環境では、振る舞いを管理するための考慮事項が他にあります。

WebSphere® Application Server は、Enterprise JavaBeans (EJB) タイマー・サービスを実装します。ビジネスのニーズに基づき、パーシスタント・タイマーまたは非パーシスタント・タイマーを使用できます。パーシスタント・タイマーは、サーバーのシャットダウンおよび再始動でも中断せず、サーバーのライフサイクルを超えてタイマーが存続することを必要とする、時間ベースのイベントに対してタイマーを作成する場合に有用です。前に始動済みのパーシスタント・タイマーは、サーバーの始動時に自動的に開始され、またデータベース・インスタンスを必要とします。非パーシスタント・タイマーは、データ・ストアを使用せず、アプリケーション・サーバーが停止またはアクティブ状態を維持できない場合は取り消されます。 非パーシスタント・タイマーは、それらが作成されたサーバー上にのみ存在します。 クラスター環境で、EJB アプリケーションが自動的に非パーシスタント・タイマーを作成し、このアプリケーションが複数のサーバーでミラーリングされている場合、各サーバーには、そのサーバー環境内で動作する独自の非パーシスタント・タイマーがあります。 プログラムで作成された非パーシスタント・タイマーは、それが作成されたクラスター・メンバー内でのみ実行されます。

マルチサーバーのクラスター・サーバー環境にパーシスタント・タイマーを構成する場合は、以下に示した、サーバー・インスタンスが特定の Bean のタイムアウト・メソッドを呼び出す可能性を考慮してください。

  • サーバー・プロセスまたはクラスター・メンバーごとに、タイマー・サービス・データベースを分離します。 これはデフォルト構成です。 タイマーにアクセスし、そのタイマー Bean のタイムアウト・メソッドを実行できるのは、そのタイマーを作成したサーバー・インスタンスまたはクラスター・メンバーだけです。サーバー・インスタンスが使用不可の場合、タイマーは指定された時刻に実行されず、またサーバーが再始動するまで実行されません。 また、エンタープライズ Bean が getTimers() メソッドを呼び出す場合、サーバー・インスタンスで作成されたタイマーのみが検出されます。 エンタープライズ Bean が関連するすべてのタイマーをキャンセルしようとする 場合、例えばエンタープライズ Bean が除去されるとき、これは予期しない動作の原因となります。 生産レベルのシステムでは、この構成は推奨されません。
  • クラスター用の共有または共通タイマー・サービス・データベース。 タイマーは、サーバー・プロセスまたはクラスター・メンバー上で作成し アクセスすることができます。 サーバー・プロセスの 1 つで作成されたタイマーは、クラスター内の他のサーバー・プロセスでは getTimers() メソッドによって検出されます。 エンティティー Bean が除去されるとき、すべてのタイマーは、どこで作成されたかによらず、キャンセルされます。 ただし、すべてのタイマーがクラスター内の単一サーバーで実行されます。すなわち、Bean のタイムアウト・メソッドは、単一サーバー上のすべてのタイマーに対して実行されます。どのサーバーがタイマーを実行するかは、どのサーバー・プロセスが共通 データベース表上にロックを取得しているかによります。 タイマーを実行しているサーバーが使用不可になった場合、他のサーバー またはクラスター・メンバーが引き継ぎ、そのスケジュールされた時刻で すべてのタイマーの実行を開始します。 これはすべての生産レベル・システムに対して推奨される構成です。
  • トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): マルチスレッドのデータベース・アクセスを使用してアプリケーション内の EJB タイマー・サービスを使用するときは、アプリケーション・フローによってデッドロックの問題が生じる可能性があります。gotcha
    これを避けるために、wsPessimisticUpdate アクセス・インテントを使用します。 このアクセス・インテントにより、アプリケーション内に finder メソッ ドは、汎用選択の代わりに 更新の選択 ステートメントを実行します。 これが今度は、複数のスレッドが更新を実行するためにロックを段階的に 拡大しようとするとき、ロック・エスカレーション・デッドロックを防ぎます。
各サーバー・プロセスのタイマー・サービスに使用されるデータ・ソース (データベース) を構成する方法については、エンタープライズ Bean に EJB タイマー・サービスを使用する方法に関する情報を参照してください。
トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): タイマー・サービスのデータ・ソースが異なるデータベースをポイントするように変更された場合、次回のサーバー始動時に、サーバー・プロセスは自動的にそのデータベース内に必要な表を作成しようとします。gotcha
サーバー・プロセスの始動に関連したユーザー ID が、構成されたタイマー・サービス・データベース内でデータベース表の作成を許可されていない場合は、表を手動で作成しなければなりません。
トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): 本製品内でプロキシー・サーバーを使用する場合、スケジューラーを EJB タイマー・サービス用に使用するスケジューラーとして構成するときは、このスケジューラーをセル・レベルで定義しないでください。これを行うと、パーシスタント・タイマーが実行されなくなります。 これは、プロキシー・サーバーでスケジューラーがリースされた場合に発生する可能性があります。 プロキシー・サーバー内でアプリケーションは実行されないため、スケジューラーによって送信されるタイマー・イベントを処理するためのアプリケーション・コードもありません。gotcha
トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): EJB タイマー/スケジューラーを構成するとき、デフォルトのスケジューラーは、機能する環境を素早く稼働できるようにするために、単純なファイル・ベースの Apache Derby データベースをデフォルトで使用することに留意してください。Derby データベースを実動用に使用しないでください。また、デフォルトの Derby データベースは、クラスター化されたジョブ・スケジューラー、およびクラスター化されたバッチ・コンテナーをサポートしません。gotcha

トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rejb_timerservice_v8
ファイル名:rejb_timerservice_v8.html