単一サーバー環境では、指定された Bean で ejbTimeout() メソッドを呼び出す必要があるサーバー・インスタンスは明らかです。
マルチサーバー・クラスター環境では、2 つの可能性があります。
- サーバー・プロセスまたはクラスター・メンバーごとに、タイマー・サービス・データベースを分離します。
これはデフォルト構成です。
タイマーを作成したサーバー・インスタンスまたはクラスター・メンバー
のみが、タイマーにアクセスし、ejbTimeout() メソッドを実行することができます。
サーバー・インスタンスが使用不可の場合、タイマーは指定された時刻に実行されず、またサーバーが再始動するまで実行されません。
また、エンタープライズ Bean が findTimers() メソッドを呼び出す場合、サーバー・インスタンス上で作成されたタイマーのみが検出されます。
エンタープライズ Bean が関連するすべてのタイマーをキャンセルしようとする
場合、例えばエンタープライズ Bean が除去されるとき、これは予期しない動作の原因となります。
生産レベルのシステムでは、この構成は推奨されません。
- クラスター用の共用または共通タイマー・サービス・データベース。
タイマーは、サーバー・プロセスまたはクラスター・メンバー上で作成し
アクセスすることができます。
サーバー・プロセスの 1 つで作成されたタイマーは、クラスター内の他の
サーバー・プロセス上で findTimers() メソッドによって検出されます。
エンティティー Bean が除去されるとき、すべてのタイマーは、どこで作成されたかによらず、キャンセルされます。
しかし、すべてのタイマーはクラスター内の単一サーバー上で実行されま
す。すなわち、ejbTimeout() メソッドは単一サーバー上のすべて
のサーバーに対して実行されます。
どのサーバーがタイマーを実行するかは、どのサーバー・プロセスが共通
データベース・テーブル上にロックを取得しているかによります。
タイマーを実行しているサーバーが使用不可になった場合、他のサーバー
またはクラスター・メンバーが引き継ぎ、そのスケジュールされた時刻で
すべてのタイマーの実行を開始します。
これはすべての生産レベル・システムに対して推奨される構成です。
- デッドロックおよびアクセス・インテントについての注: マル
チスレッドのデータベース・アクセスを使用してアプリケーション内の EJB
タイマー・サービスを使用するときは、アプリケーション・フローがデッドロック問題を導入する可能性があります。
これを避けるために、wsPessimisticUpdate アクセス・インテントを使用します。
このアクセス・インテントにより、アプリケーション内に finder メソッ
ドは、汎用選択の代わりに 更新の選択 ステートメントを実行します。
これが今度は、複数のスレッドが更新を実行するためにロックを段階的に
拡大しようとするとき、ロック・エスカレーション・デッドロックを防ぎます。
各サーバー・プロセス・タイマー・サービスに対して使用されるデータ
・ソース (データベース) の構成法についての詳細は、タイマー・サービスの構成
を参照してください。
タイマー・サービスのデータ・ソースが変更されて異なるデータベースを
示すようになると、次のサーバーが始動す
るときに、サーバー・プロセスは自動的にそのデータベース内で要求されたテーブルを作成しようとします。
サーバー・プロセスの始動に関連したユーザー ID が、構成されたタイマ
ー・サービス・データベース内でデータベース・テーブルの作成を許可され
ていない場合は、テーブルを手動で作成しなければなりません。
詳しくは、DDL ファ
イルを使用したスケジューラー・テーブルの作成 を参照してください。