タイマー・サービスに対するクラスター環境の考慮事項
単一サーバー環境では、どのサーバー・インスタンスが、指定された Bean に対して Bean のタイムアウト・メソッドを呼び出すかは明確です。 マルチサーバー・クラスター環境では、振る舞いを管理するための考慮事項が他にあります。
WebSphere® Application Server は、Enterprise JavaBeans (EJB) タイマー・サービスを実装します。ビジネスのニーズに基づき、パーシスタント・タイマーまたは非パーシスタント・タイマーを使用できます。パーシスタント・タイマーは、サーバーのシャットダウンおよび再始動でも中断せず、サーバーのライフサイクルを超えてタイマーが存続することを必要とする、時間ベースのイベントに対してタイマーを作成する場合に有用です。前に始動済みのパーシスタント・タイマーは、サーバーの始動時に自動的に開始され、またデータベース・インスタンスを必要とします。非パーシスタント・タイマーは、データ・ストアを使用せず、アプリケーション・サーバーが停止またはアクティブ状態を維持できない場合は取り消されます。 非パーシスタント・タイマーは、それらが作成されたサーバー上にのみ存在します。 クラスター環境で、EJB アプリケーションが自動的に非パーシスタント・タイマーを作成し、このアプリケーションが複数のサーバーでミラーリングされている場合、各サーバーには、そのサーバー環境内で動作する独自の非パーシスタント・タイマーがあります。 プログラムで作成された非パーシスタント・タイマーは、それが作成されたクラスター・メンバー内でのみ実行されます。
マルチサーバーのクラスター・サーバー環境にパーシスタント・タイマーを構成する場合は、以下に示した、サーバー・インスタンスが特定の Bean のタイムアウト・メソッドを呼び出す可能性を考慮してください。
- サーバー・プロセスまたはクラスター・メンバーごとに、タイマー・サービス・データベースを分離します。 これはデフォルト構成です。 タイマーにアクセスし、そのタイマー Bean のタイムアウト・メソッドを実行できるのは、そのタイマーを作成したサーバー・インスタンスまたはクラスター・メンバーだけです。サーバー・インスタンスが使用不可の場合、タイマーは指定された時刻に実行されず、またサーバーが再始動するまで実行されません。 また、エンタープライズ Bean が getTimers() メソッドを呼び出す場合、サーバー・インスタンスで作成されたタイマーのみが検出されます。 エンタープライズ Bean が関連するすべてのタイマーをキャンセルしようとする 場合、例えばエンタープライズ Bean が除去されるとき、これは予期しない動作の原因となります。 生産レベルのシステムでは、この構成は推奨されません。
- クラスター用の共有または共通タイマー・サービス・データベース。 タイマーは、サーバー・プロセスまたはクラスター・メンバー上で作成し アクセスすることができます。 サーバー・プロセスの 1 つで作成されたタイマーは、クラスター内の他のサーバー・プロセスでは getTimers() メソッドによって検出されます。 エンティティー Bean が除去されるとき、すべてのタイマーは、どこで作成されたかによらず、キャンセルされます。 ただし、すべてのタイマーがクラスター内の単一サーバーで実行されます。すなわち、Bean のタイムアウト・メソッドは、単一サーバー上のすべてのタイマーに対して実行されます。どのサーバーがタイマーを実行するかは、どのサーバー・プロセスが共通 データベース表上にロックを取得しているかによります。 タイマーを実行しているサーバーが使用不可になった場合、他のサーバー またはクラスター・メンバーが引き継ぎ、そのスケジュールされた時刻で すべてのタイマーの実行を開始します。 これはすべての生産レベル・システムに対して推奨される構成です。
- これを避けるために、wsPessimisticUpdate アクセス・インテントを使用します。 このアクセス・インテントにより、アプリケーション内に finder メソッ ドは、汎用選択の代わりに 更新の選択 ステートメントを実行します。 これが今度は、複数のスレッドが更新を実行するためにロックを段階的に 拡大しようとするとき、ロック・エスカレーション・デッドロックを防ぎます。
トラブルの回避 (Avoid trouble): マルチスレッドのデータベース・アクセスを使用してアプリケーション内の EJB タイマー・サービスを使用するときは、アプリケーション・フローによってデッドロックの問題が生じる可能性があります。gotcha


