|
|
|
|
|
|
| | | |
WebLogic Server EJB コンテナとサポートされるサービス
以下の節では、WebLogic Server の EJB コンテナについて説明します。また、EJB の動作のさまざまな側面について、コンテナが提供する機能およびサービスとの関連から説明します。コンテナ管理による永続性（CMP）の詳細については、WebLogic Server のコンテナ管理による永続性サービス,を参照してください。
EJB コンテナ
EJB コンテナは、WebLogic Server の起動時に自動的に作成されるデプロイ済み EJB を収容する実行時コンテナです。エンティティ オブジェクトのライフサイクル全体（作成から削除まで）を通じて、オブジェクトはコンテナ内で動作します。EJB コンテナは、キャッシュ、同時実行性、永続性、セキュリティ、トランザクション管理、ロック、環境、メモリ レプリケーション、コンテナ内の全オブジェクトのクラスタ化などの標準のサービス集合を提供します。
1 つのコンテナに複数のエンティティ Bean をデプロイできます。コンテナにデプロイされる個々の エンティティ Bean に対して、コンテナはホーム インタフェースを提供します。クライアントはホーム インタフェースを通じて、エンティティ Bean に属するエンティティ オブジェクトを作成、検索、および削除したり、特定のエンティティ Bean オブジェクトに固有でないホームのビジネス メソッドを実行することができます。クライアントは JNDI を通じてエンティティ Bean のホーム インタフェースをルックアップできます。JNDI のネームスペース内でエンティティ Bean のホーム インタフェースを見つけられるようにするのはコンテナの役割です。JNDI を通じたホーム インタフェースのルックアップについて、詳しくは「WebLogic JNDI プログラマーズ ガイド」を参照してください。
WebLogic Server における EJB のライフサイクル
以降の節では、コンテナによるキャッシュ サービスのサポートに関する情報を示します。また、WebLogic Server での EJB インスタンスのライフサイクルを、WebLogic Server の視点から説明します。これらの節では EJB インスタンスという用語を使用しますが、これは EJB クラスの実際のインスタンスという意味です。EJB インスタンスは、クライアント側から見た EJB の論理インスタンスを意味するものではありません。
ステートレス セッション EJB のライフサイクル
WebLogic Server は、フリー プールを使用してステートレス セッション EJB とメッセージ駆動型 Bean のパフォーマンスおよびスループットを高めます。フリー プールには、非バインド ステートレス セッション EJB が格納されます。非バインド EJB はステートレス セッション EJB クラスのインスタンスで、メソッド呼び出しを処理しません。
次の図に、WebLogic Server のフリー プールと、ステートレス EJB がフリー プールに出入りするプロセスを示します。点線は、WebLogic Server 側から見た EJB の「状態」を表しています。
図4-1 ステートレス セッション EJB のライフサイクルを示す WebLogic Server フリー プール
ステートレス セッション EJB インスタンスの初期化
デフォルトでは、WebLogic Server には起動時にステートレス セッション EJB インスタンスは存在しません。クライアントが個々の Bean にアクセスすると、WebLogic Server は EJB クラスの新しいインスタンスを初期化します。ただし、WebLogic Server の起動時に非アクティブな EJB インスタンスを作成する場合、initial-beans-in-free-pool デプロイメント記述子要素を weblogic-ejb-jar.xml ファイルで指定します。
weblogic-ejb-jar.xml の initial-beans-in-free-pool 要素をオプションで設定すると、起動時に非アクティブな EJB インスタンスをフリー プールに自動的に作成できます。このようにしておけば、クライアントが EJB にアクセスしたときの初期応答時間を短縮できます。これは、Bean を初期化してからアクティブ化するのではなく、フリー プールから Bean をアクティブ化することによって、最初のクライアント リクエストを満足させることができるからです。デフォルトでは、initial-beans-in-free-pool は 0 に設定されています。
注意: フリー プールの最大サイズは、使用可能メモリ、または max-beans-in-free-pool デプロイメント要素の値のいずれかによって制限されます。
ステートレス セッション EJB のアクティブ化とプーリング
ステートレス EJB に対するメソッドを呼び出すと、WebLogic Server はフリー プールからインスタンスを取得します。EJB は、クライアントのメソッド呼び出しの間アクティブ状態になります。メソッドが完了すると、EJB のインスタンスはフリー プールに戻されます。WebLogic Server は各メソッドの呼び出し後にクライアントからステートレス セッション Bean を非バインドするので、クライアントが使用する実際の Bean クラスは呼び出しごとに異なります。
EJB クラスのすべてのインスタンスがアクティブで、max-beans-in-free-pool に達した場合、EJB クラスを要求する新しいクライアントは、アクティブ EJB がメソッド呼び出しを完了するまでブロックされます。トランザクションがタイムアウトになった場合（トランザクション非対応の呼び出しでは、5 分経過した場合）、WebLogic Server は RemoteException を送出します。
WebLogic Server は、Bean インスタンスのキャッシュを使用してステートフル セッション EJB のパフォーマンスを高めます。キャッシュはメモリ内にアクティブな EJB インスタンスを格納することで、それらをクライアント リクエストに即座に使用できるようにしています。アクティブ EJB は、以下の節で示すように、クライアントが現在使用しているインスタンスと最近使用したインスタンスから構成されます。キャッシュ内のステートフル セッション Bean が特定のクライアントにバインドされるのに対し、フリープール内のステートレス セッション Bean はクライアントに関連付けられないという点で、キャッシュはフリープールとは異なります。
次の図に、WebLogic Server のキャッシュと、ステートフル EJB がキャッシュに出入りするプロセスを示します。点線は、WebLogic Server 側から見た EJB の状態を表しています。
図4-2 ステートフル セッション EJB のライフサイクルを示す WebLogic Server キャッシュ
ステートフル セッション EJB インスタンスのアクティブ化と使用
WebLogic Server には起動時にステートフル セッション EJB インスタンスは存在しません。クライアントが個々の Bean への参照をルックアップして取得すると、WebLogic Server は EJB クラスの新しいインスタンスを初期化してキャッシュに格納します。
ステートフル セッション EJB のパッシブ化
ハイ パフォーマンスを実現するために、WebLogic Server はクライアントが現在使用している EJB と最近使用した EJB をキャッシュに保存します。EJB がこれらの基準を満たさなくなると、それらはパッシベーションの対象となります。パッシベーションは、EJB の状態をディスク上で保持しつつキャッシュからその EJB を削除するために WebLogic Server が使用するプロセスです。パッシブ化されている EJB は最小限の WebLogic Server リソースしか使用せず、キャッシュに格納されているときのようにクライアント リクエストのために即座に使用することはできません。
注意: ステートフル セッション EJB は、一定のルールに従わなければなりません。これにより、Bean フィールドを永続ストレージにシリアライズできます。詳細については、ステートフル セッション EJB の要件を参照してください。
weblogic-ejb-jar.xml ファイルの max-beans-in-cache デプロイメント要素を使用すると、いつ EJB のパッシベーションを行うかを指定できます。
max-beans-in-cache 制限に達し、使用されていない EJB がキャッシュに存在する場合、WebLogic Server はそれらの一部のパッシベーションを行います。パッシベーションは、使用されていない Bean がその idle-timeout-seconds 制限に達していない場合でも行われます。max-beans-in-cache に達し、キャッシュ内のすべての EJB がクライアントによって使用されている場合、WebLogic Server は CacheFullException を送出します。
注意: EJB がパッシベーションの対象になっても、WebLogic Server がその Bean のパッシベーションを即座に行うとは限りません。実際には、その Bean のパッシベーションがまったく行われない場合もあります。パッシベーションが行われるのは、EJB がパッシベーションの対象となり、かつサーバ リソースが不足している場合か、または WebLogic Server が通常のキャッシュ メンテナンスを実行した場合だけです。
weblogic-ejb-jar.xml ファイルで cache-type 要素を設定することにより、idle-timeout-seconds に達したステートフル EJB の明示的パッシベーションを指定することができます。この設定には、最長時間未使用（least recently used : LRU）と最近未使用（not recently used :NRU）の 2 つの値があります。EJB をより活発にアクティブにする必要があるときは LRU を指定します。キャッシュ内のメモリの制約があり、クライアントによる使用頻度が最も高い Bean をメモリに保持するときは NRU を指定します。
ステートフル セッション EJB インスタンスの削除
max-beans-in-cache および idle-timeout-seconds デプロイメント要素を使用すると、ステートフル セッション EJB をいつキャッシュまたはディスクから削除するかを指定することもできます。
注意: idle-timeout-seconds を 0 に設定すると、WebLogic Server は通常のキャッシュ メンテナンスで EJB を削除しません。しかし、キャッシュ リソースが不足状態になった場合、EJB のパッシベーションが行われる可能性は依然としてあります。
ステートフル セッション EJB の要件
EJB 開発者は、ejbPassivate() メソッドが呼び出されたときに、ステートフル セッション Bean が、WebLogic Server によってそのデータがシリアライズされてそのインスタンスのパッシベーションが行われるような状態に置かれるようにしなければなりません。パッシベーションの間、WebLogic Server はtransientであると宣言されていないフィールドをシリアライズしようとします。このため、すべての非 transient フィールドがシリアライズ可能オブジェクト（Bean のリモートおよびホーム インタフェースなど）を表すようにしなければなりません。
ステートレス セッション Bean と BMP EJB のパフォーマンス比較
パフォーマンスを向上させるために、データの取得には BMP（Bean 管理の永続性）エンティティ Bean ではなくステートレス セッション Bean または CMP（コンテナ管理の永続性）エンティティ Bean を使用することをお勧めします。BMP エンティティ Bean がファインダ クエリの間にデータをキャッシュできないことにより、ステートレス セッション Bean のパフォーマンスは BMP エンティティ Bean よりも 90% 程度高速な場合がある、ということが各種のテストで実証されています。たとえば、ファインダ クエリからの 100 個の Bean を返す BMP エンティティ Bean は、ファインダ クエリの実行時に 1 回の JDBC 呼び出しを行って Bean 参照を作成し、その後、クライアントが各 Bean にアクセスするたびに JDBC 呼び出しを行って Bean をロードします。つまり、BMP エンティティ Bean のファインダ クエリは合計でデータベースに対して 101 回の呼び出しを行います。比較すると、ステートレス セッション Bean は JDBC 呼び出しを 1 回しか行わないため、そのパフォーマンスはずっと高速です。
BMP エンティティ Bean がスケーラビリティの面で不利であるという事実は、パフォーマンス上の既知の制限事項です。
加えて、CMP エンティティ Bean はファインダ クエリの間にデータをキャッシュできます。そのため、ステートレス セッション Bean の場合と同様にクエリの実行は 1 回で済みます。
通常は、max-beans-in-free-pool 要素を指定しないでください。max-beans-in-free-pool を設定するのは、基底のリソースへのアクセスを制限する場合です。たとえば、ステートレス セッション EJB を使用して従来の接続プールを実装する場合、従来のシステムがサポートする接続数を超える数の Bean インスタンスを割り当てる必要はありません。フリー プールの Bean インスタンスを要求する場合、次の 3 つのシナリオが考えられます。
デフォルトでは、max-beans-in-free-pool は最大を表す Int.max に設定されています。しかし、20 億のインスタンスを使用できるということではありません。新しい Bean インスタンスを 1 つ割り当てるだけなので、オプション 3 の状況は基本的に発生しません。ただし、実行スレッドの数による制限があります。ほとんどの場合、各スレッドに必要な Bean インスタンスは最大でも 1 つです。
max-beans-in-free-pool の特殊な使い方
以下のオプションでは、max-beans-in-free-pool を 0 に設定した場合の特殊なケースについて説明します。
エンティティ EJB に対する ejbLoad() と ejbStore() の動作
WebLogic Server は、ejbLoad() および ejbStore() への呼び出しを使用して、エンティティ EJB の永続フィールドを読み書きします。デフォルトでは、WebLogic Server は ejbLoad() と ejbStore() を次の手順で呼び出します。
こうした ejbLoad() と ejbStore() の呼び出しという単純なプロセスにより、新しいトランザクションは常に EJB の最新の永続的データを使用し、コミット時には常にそのデータをデータベースに書き込むようになります。しかし、環境によっては、パフォーマンス上の理由から ejbLoad() と ejbStore() の呼び出しを制限することができます。この場合、代わりに ejbStore() の呼び出しをより頻繁に行って、コミットされていないトランザクションの中間結果を参照することができます。
WebLogic Server には、ejbLoad() と ejbStore() の動作をコンフィグレーションするためのデプロイメント記述子要素が weblogic-ejb-jar.xml および weblogic cmp-rdbms-jar.xml ファイルに用意されています。
db-is-shared を使用した ejbLoad() の呼び出しの制限
デフォルトによって、WebLogic Server は各トランザクションの開始時に ejbLoad() を呼び出します。この動作は、複数のソースがデータベースを更新するような環境に適しています。複数のクライアント（WebLogic Server を含む）が EJB の基盤データを変更する可能性があるため、ejbLoad() の最初の呼び出しは、キャッシュ済みデータを更新する必要があることを Bean に通知し、確実に最新のデータが処理対象になるようにします。
単一の WebLogic Server インスタンスのみが特定の EJB にアクセスするような特殊な環境では、ejbLoad() をデフォルトで呼び出す必要はありません。EJB の基盤データを更新するクライアントまたはシステムは他に存在しないので、WebLogic Server の EJB データのキャッシュは常に最新のものとなります。こうしたケースでは、ejbLoad() を呼び出しても、Bean にアクセスする WebLogic Server クライアントに対して余計なオーバーヘッドが発生するだけです。
単一の WebLogic Server インスタンスが特定の EJB にアクセスする場合、ejbLoad() の不要な呼び出しを避けるために、WebLogic Server には db-is-shared デプロイメント パラメータが用意されています。デフォルトでは、db-is-shared は各 EJB に対して Bean の weblogic-ejb-jar.xml ファイルで true に設定されています。このため、ejbLoad() は各トランザクションの開始時に必ず呼び出されます。単一の WebLogic Server インスタンスだけが EJB の基盤データにアクセスするようなケースでは、同時実行性オプションが [Exclusive] に設定されている場合に、その Bean の weblogic-ejb-jar.xml ファイルの db-is-shared を「false」に設定できます。db-is-shared を false に設定して EJB をデプロイすると、WebLogic Server の単一のインスタンスが以下の場合に、その Bean の ejbLoad() を呼び出します。
db-is-shared に関する制限と警告
db-is-shared を「false」に設定すると、EJB の基盤データが 1 つの WebLogic Server インスタンスによって更新されるか、複数のクライアントによって更新されるかにかかわらず、WebLogic Server のデフォルト ejbLoad() 動作（コンテナ管理による永続性）がオーバーライドされます。間違って db-is-shared を「false」に設定し、複数のクライアント（データベース クライアント、別の WebLogic Server インスタンスなど）が Bean データを更新する場合、データの完全性が失われる恐れがあります。
エンティティ Bean の concurrency strategy を「Database」オプションに設定する場合は、db-is-shared を「false」に設定しないでください。このように設定しても、WebLogic Server は db-is-shared の設定を無視します。
データベース ロックが指定されていると、EJB コンテナは、エンティティ Bean クラスのインスタンスのキャッシュを引き続き行います。ただし、コンテナは、トランザクション間の EJB インスタンスの中間状態はキャッシュしません。代わりに、WebLogic Server がトランザクションの開始時に各インスタンスに対して ejbLoad() を呼び出し、最新の EJB データを取得します。つまり、db-is-shared を「false」に設定して WebLogic Server が各トランザクションの開始時に ejbload() を呼び出さないようにするのは無意味です。
また、キャッシュの制限のために、WebLogic Server クラスタでは db-is-shared を「false」に設定できません。
is-modified-method-name を使用した ejbStore() の呼び出しの制限（EJB 1.1 のみ）
このメソッドは現在のバージョンでは必須ではありません。
注意: is-modified-method-name デプロイメント記述子要素は、EJB 1.1 のコンテナ管理永続性（CMP）Bean だけに適用されます。この要素は、 weblogic-ejb-jar.xml ファイルに入っています。ただし、この要素は EJB 2.0 では必須ではなくなりました。WebLogic Server の CMP 実装では、CMP フィールドの変更が自動的に検出され、それらの変更だけが基盤のデータストアに書き込まれます。Bean 管理の永続性（BMP）では is-modified-method-name を使用しないことをお勧めします。なぜなら、is-modified-method-name 要素と ejbstore メソッドの両方を作成しなければならないからです。
デフォルトでは、WebLogic Server は各トランザクションが正常に完了（コミット）したときに ejbStore() を呼び出します。ejbStore() は、EJB の永続フィールドが実際に更新されたかどうかに関係なく、コミット時に呼び出されます。WebLogic Server の is-modified-method-name デプロイメント要素は、ejbStore() の不必要な呼び出しによってパフォーマンスが低下するような場合に使用します。
is-modified-method-name を使用するには、EJB プロバイダは最初に、永続データが更新されたときに WebLogic Server に「合図」を送る EJB メソッドを開発する必要があります。このメソッドは、EJB フィールドが 1 つも更新されなかった場合は「false」を、フィールドが更新された場合は「true」を返さなければなりません。
EJB プロバイダまたは EJB デプロイメント記述子は、次に is-modified-method-name 要素の値を使用して、このメソッドの名前を識別します。WebLogic Server は、トランザクションがコミットされると指定されたメソッド名を呼び出し、そのメソッドが「true」を返した場合にだけ ejbStore() を呼び出します。この要素の詳細については、is-modified-method-nameを参照してください。
is-modified-method-name に関する警告
is-modified-method-name 要素を使用すると、ejbStore() の不必要な呼び出しを避けることによってパフォーマンスを高めることができます。しかし、いつ更新が行われたかを正確に識別することは、EJB 開発者にとっては負担が大きい作業です。指定された is-modified-method-name が不正確なフラグを WebLogic Server に返した場合、データの完全性に関する問題が起こりかねず、多くの場合、こうした問題を追跡するのは困難です。
エンティティ EJB の更新内容がシステム内で失われたと思われる場合、まずどのような状況でもすべての is-modified-method-name 要素の値が「true」を返すように設定してください。これにより、WebLogic Server のデフォルト ejbStore() 動作に戻すことができ、問題が解決する場合があります。
delay-updates-until-end-of-tx を使用した ejbStore() 動作の変更
デフォルトでは、WebLogic Server はトランザクションのすべての Bean の永続ストレージをトランザクションの完了（コミット）時にだけ格納します。これにより、不必要な更新と ejbStore() の呼び出しの反復が回避され、一般にパフォーマンスが向上します。
データベースがアイソレーション レベルの READ_UNCOMMITTED を使用する場合、他のデータベース ユーザが継続中のトランザクションの中間結果を参照できるようにすることができます。こうしたケースでは、トランザクションの完了時にだけデータストアを更新するという WebLogic Server のデフォルト動作は不適切な場合があります。 これを行うには、delay-updates-until-end-of-tx を「false」に設定します。
デフォルト動作を無効にするには、delay-updates-until-end-of-tx デプロイメント記述子要素を使用します。この要素は、weblogic-ejb-jar.xml ファイルで設定します。この要素を「false」に設定すると、WebLogic Server はトランザクションの完了時ではなく各メソッド呼び出しの後に ejbStore() を呼び出します。
注意: delay-updates-until-end-of-tx を false に設定しても、各メソッド呼び出しの後にデータベース更新が「コミットされた」状態になるわけではありません。更新はデータベースに送信されるだけです。更新は、トランザクションの完了時にのみデータベースにコミットまたはロールバックされる。
エンティティ EJB は、read-only 同時方式を使用して ejbLoad() と ejbStore() の基本動作を変更することもできます。以降の各項では、EJB コンテナによる同時方式サービスのサポートについて説明します。
read-only キャッシュ方式を設定するには、weblogic-ejb-jar.xml デプロイメント ファイルの concurrency-strategy 要素を編集します。デプロイメント記述子の編集方法の詳細については、EJB デプロイメント記述子の指定と編集を参照してください。
read-only 同時方式
read-only 同時方式は、EJB クライアントによって変更されないが、外部リソースによって定期的に更新されるエンティティ EJB に対して使用できます。たとえば、read-only エンティティ EJB を使用すると、WebLogic Server システムの外部で更新される、特定の企業の株価を表すことができます。
WebLogic Server では、read-only エンティティ EJB に対して ejbStore() は呼び出されません。ejbLoad() は、EJB が最初に作成されたときに呼び出されます。それ以後 WebLogic Server は、read-timeout-seconds デプロイメント パラメータによって定義されている間隔で ejbLoad() を呼び出します。
read-only 同時方式の制限
read-only 同時方式を使用するエンティティ EJB は、以下の制限に従わなければなりません。
read-only マルチキャストの無効化
read-only マルチキャストを無効化すると、キャッシュされたデータを効率的に無効にできます。
read-only エンティティ Bean を無効にするには、CachingHome または CachingLocalHome インタフェースの次の invalidate() メソッドを呼び出します。
Figure 4-3 CachingHome およびCachingLocalHome インタフェースを示すサンプル コード
package weblogic.ejb;
public interface CachingHome {public void invalidate(Object pk) throws RemoteException;
public void invalidate (Collection pks) throws RemoteException;
public void invalidateAll() throws RemoteException;
public interface CachingLocalHome {public void invalidate(Object pk) throws RemoteException;
public void invalidate (Collection pks) throws RemoteException;
public void invalidateAll() throws RemoteException
}
次のサンプル コードは、ホームを CachingHome にキャストし、続いてメソッドを呼び出す方法を示しています。
Figure 4-4 ホームをキャストしてメソッドを呼び出す方法を示すサンプル コード
import javax.naming.InitialContext;
import weblogic.ejb.CachingHome;
Context initial = new InitialContext();
Object o = initial.lookup("CustomerEJB_CustomerHome");
CustomerHome customerHome = (CustomerHome)o;
CachingHome customerCaching = (CachingHome)customerHome;
customerCaching.invalidateAll();
}
invalidate() メソッドを呼び出すと、read-only エンティティ Bean はローカル サーバで無効化され、マルチキャスト メッセージがクラスタ内の他のサーバに送信されてキャッシュされているその Bean のコピーが無効化されます。無効化された read-only エンティティ Bean を次に呼び出すと、ejbLoad が呼び出されます。ejbLoad() は、最新の永続的データを基盤となるデータストアから読み出します。
WebLogic Server は、トランザクションの更新が完了してから invalidate() メソッドを呼び出します。トランザクションの更新中に無効化処理が行われた場合、アイソレーション レベルでコミットされていないデータの読み出しが許可されていないと、更新前のデータが読み出される可能性があります。
標準の read-only エンティティ Bean
WebLogic Server は、デプロイメント記述子で設定する read-timeout 要素によって、標準の read-only エンティティ Bean を引き続きサポートします。ReadOnly オプションが concurrency strategy 要素で選択され、read-timeout-seconds 要素が weblogic-ejb-jar.xml ファイルで設定されている場合、read-only エンティティ Bean が呼び出されると、WebLogic Server はキャッシュされているデータが read-timeout 設定よりも古いかどうかを確認します。古い場合は、Bean の ejbLoad が呼び出されます。それ以外の場合は、キャッシュされているデータが使用されます。したがって、以前のバージョンの read-only エンティティ Bean はこのバージョンの WebLogic Server で機能します。
read-mostly パターン
WebLogic Server は、weblogic-ejb-jar.xml に設定される read-mostly キャッシュ方式をサポートしていません。しかし、頻繁に更新されない EJB データがある場合、read-only EJB と read-write EJB を組み合わせることによって、「read-mostly パターン」を作成できます。
詳細については、WebLogic Server の配布キットの次の場所にある read-mostly のサンプルを参照してください。
wlserver6.1\samples\examples\ejb\extensions\readMostly
WebLogic Server は、read-mostly パターンの自動 invalidate() メソッドを提供します。このパターンでは、read-only エンティティ Bean と read-write エンティティ Bean が同じデータにマップされます。データを読み出すには read-only エンティティ Bean を使用し、データを更新するには read-write エンティティ Bean を使用します。read-mostly パターンの詳細については、read-mostly パターンを参照してください。
read-mostly パターンでは、read-only エンティティ EJB は、weblogic-ejb-jar.xml ファイルの read-timeout-seconds デプロイメント記述子要素によって指定されている間隔で Bean データを取得します。別の read-write エンティティ EJB は、その read-only EJB と同じデータをモデル化し、必要な間隔でそのデータを更新します。
read-mostly パターンを作成する場合、以下の注意に従って、データの一貫性に関する問題が発生しないようにしてください。
注意: WebLogic Server クラスタでは、read-only EJB のクライアントは、キャッシュされた EJB データを使用することで恩恵を受けることができます。read-write EJB のクライアントは、真のトランザクション動作から恩恵を受けることができます。これは、read-write EJB の状態が常に基盤データベース上のそのデータの状態と一致するからです。詳細については、クラスタ内のエンティティ EJBを参照してください。
read-write キャッシュ方式
read-write 方式では、WebLogic Server のエンティティ EJB のデフォルト キャッシング動作を定義します。
read-write EJB の場合、WebLogic Server は各トランザクションの開始時、または db-is-shared を使用した ejbLoad() の呼び出しの制限で説明したとおり、EJB データをキャッシュにロードします。WebLogic Server は、トランザクションが正常にコミットされたとき、またはis-modified-method-name を使用した ejbStore() の呼び出しの制限（EJB 1.1 のみ）で説明したとおり、ejbStore() を呼び出します。
この節では、EJB コンテナによるクラスタ化サービスのサポートについての情報を示します。また、WebLogic Server クラスタでの EJB とそれに関連付けられるトランザクションについて説明し、クラスタでの EJB の動作に影響を与えるデプロイメント記述子について解説します。
WebLogic Server クラスタ内の EJB は、ホーム オブジェクトと EJB オブジェクトという 2 つの主要構造を修正したものを使用します。単一サーバ（非クラスタ化）環境では、クライアントは EJB のホーム インタフェースを通じて EJB をルックアップします。ホーム インタフェースの背後には、対応するホーム オブジェクトがサーバ上に存在します。Bean の参照後、クライアントはリモート インタフェースを通じてその Bean のメソッドと対話します。リモート インタフェースの背後には、EJB オブジェクトがサーバ上に存在します。
次の図は、単一サーバ環境での EJB の動作を示しています。
図4-5 単一サーバの動作
注意: EJB のフェイルオーバは、リモートクライアント と EJB との間でのみ機能します。
クラスタ化された EJBHome オブジェクト
WebLogic Server クラスタでは、ホーム オブジェクトのサーバサイド表現は、クラスタ対応の「スタブ」によって置き換えることができます。クラスタ対応のホーム スタブは、クラスタ内のすべての WebLogic Server に存在する EJB ホーム オブジェクトの知識を備えています。クラスタ化されたホーム スタブは、EJB ルックアップ リクエストを使用可能なサーバに分散することでロード バランシングを実現します。また、他のサーバに障害が発生したときにルックアップ リクエストを使用可能なサーバに転送することで、それらのリクエストのフェイルオーバもサポートします。
すべての EJB タイプ（ステートレス セッション EJB、ステートフル セッション EJB、およびエンティティ EJB）は、クラスタ対応のホーム スタブを持つことができます。クラスタ対応のホーム スタブを作成するかどうかは、weblogic-ejb-jar.xml の home-is-clusterable デプロイメント記述子要素によって決定されます。この要素を「true」（デフォルト）に設定すると、ejbc は適切なオプションを使用して rmic コンパイラを呼び出し、EJB に対してクラスタ対応のホーム スタブを作成します。
次の図は、WebLogic Server クラスタ環境での EJB の動作を示しています。クラスタ化されたサーバ環境での EJB の動作についての図解は、図 4-6 を参照してください。
図4-6 クラスタ化されたサーバ環境
クラスタ化された EJBObject
WebLogic Server クラスタでは、EJBObject のサーバサイド表現は、レプリカ対応の EJBObject スタブによって置き換えることができます。このスタブは、クラスタ内のサーバに存在する EJBObject のすべてのコピーに関する知識を保持します。EJBObject スタブは、EJB メソッド呼び出しに対するロード バランシングおよびフェイルオーバ サービスを提供します。たとえば、クライアントが特定の WebLogic Server に対して EJB メソッドを呼び出したが、そのサーバがダウンしている場合、EJBObject スタブはそのメソッド呼び出しを稼働中の別のサーバにフェイルオーバします。
EJB がレプリカ対応 EJBObject スタブを利用するかどうかは、デプロイされている EJB のタイプと、エンティティ EJB の場合、デプロイメント時に選択したキャッシュ方式によって決まります。
この節では、ステートフル セッション EJB とステートレス セッション EJB のそれぞれについて、クラスタの機能と制限を説明します。
ステートレス セッション EJB
ステートレス セッション EJB は、クラスタ対応のホーム スタブとレプリカ対応の EJBObject スタブの両方を持つことができます。デフォルトによって、WebLogic Server は EJB メソッド呼び出しに対するフェイルオーバ サービスを提供しますが、これは障害がメソッド呼び出しの合間に発生した場合に限ります。たとえば、メソッドの完了後に障害が発生した場合や、メソッドがサーバに接続されなかった場合などには、フェイルオーバが自動的にサポートされます。しかし、EJB メソッドの実行中に障害が発生した場合、WebLogic Server は別のサーバにそのメソッドを自動的にフェイルオーバしません。
このデフォルト動作では、EJB メソッド内のデータベース更新がフェイルオーバによって「重複」することはありません。たとえば、データストア内のある値をインクリメントするメソッドをクライアントが呼び出し、そのメソッドが完了する前に WebLogic Server が別のサーバにフェイルオーバした場合、クライアントの 1 度のメソッド呼び出しによってデータベースが 2 度更新されることになります。
繰り返し呼び出しても更新が重複しないように記述されたメソッドを、「多重呼び出し不変」と呼びます。WebLogic Server には、多重呼び出し不変のメソッド用に stateless-bean-methods-are-idempotent デプロイメント プロパティが用意されています。weblogic-ejb-jar.xml でこのプロパティを「true」に設定した場合、WebLogic Server はメソッドが多重呼び出し不変であると見なして、メソッド呼び出し中に障害が発生した場合でも、EJB メソッドに対するフェイルオーバ サービスを提供します。
次の図は、WebLogic Server クラスタ環境でのステートレス セッション EJB の動作を示しています。
図4-7 クラスタ化されたサーバ環境でのステートレス セッション EJB
ステートフル セッション EJB
ステートフル セッション EJB でクラスタ対応のホーム スタブを利用できるようにするには、home-is-clusterable を「true」に設定します。これにより、ステートフル EJB ルックアップに対するフェイルオーバとロード バランシングが提供されます。このようにコンフィグレーションされたステートフル セッション EJB は、レプリカ対応の EJBObject スタブを利用できます。ステートフル セッション EJB のインメモリ レプリケーションの詳細については、ステートフル セッション EJB のインメモリ レプリケーションを参照してください。
ステートフル セッション EJB のインメモリ レプリケーション
以降の節では、EJB コンテナによるレプリケーション サービスのサポートについて説明します。WebLogic Server EJB コンテナは、ステートフル セッション EJB に対するクラスタ化をサポートします。WebLogic Server 5.1 では、EJBHome オブジェクトだけがステートフル セッション EJB 用にクラスタ化されましたが、EJB コンテナでは、EJB の状態もクラスタ化された WebLogic Server インスタンス間でレプリケートできます。
ステートフル セッション EJB に対するレプリケーション サポートは、EJB クライアントには見えません。ステートフル セッション EJB がデプロイされると、WebLogic Server はステートフル セッション EJB 用にクラスタ対応の EJBHome スタブとレプリカ対応の EJBObject スタブを作成します。EJBObject スタブは、EJB インスタンスが動作するプライマリ WebLogic Server インスタンスのリストと、その Bean の状態をレプリケートするために使われるセカンダリ WebLogic Server の名前を保持します。
EJB のクライアントが EJB の状態を変更するトランザクションをコミットするたびに、WebLogic Server は EJB の状態をセカンダリ サーバ インスタンスにレプリケートします。Bean の状態のレプリケーションは直接メモリ内で行われるため、クラスタ環境で最高のパフォーマンスを得られます。
プライマリ サーバ インスタンスがダウンした場合、クライアントの次のメソッド呼び出しはセカンダリ サーバの EJB インスタンスに自動的に転送されます。セカンダリ サーバはその EJB インスタンスのプライマリ WebLogic Server となり、新しいセカンダリ サーバが別のフェイルオーバに対応します。EJB のセカンダリ サーバがダウンした場合には、WebLogic Server はクラスタから新しいセカンダリ サーバ インスタンスを確保します。
このため、ステートフル セッション EJB のクライアントは、EJB の最後にコミットされた状態に迅速にアクセスできます。ただし、後述のインメモリ レプリケーションの制限事項で挙げる特殊な環境は除きます。
インメモリ レプリケーションの要件とコンフィグレーション
WebLogic Server クラスタでステートフル セッション EJB の状態をレプリケートするには、クラスタの EJB クラスを同種にする必要があります。つまり、同じデプロイメント プロパティを使用して、クラスタ内のすべての WebLogic Server インスタンスに同じ EJB クラスをデプロイしなければなりません。異種クラスタに対するインメモリ レプリケーションはサポートされていません。
デフォルトでは、WebLogic Server はクラスタ内でステートフル セッション EJB インスタンスをレプリケートしません。これは、WebLogic Server バージョン 6.0 でリリースされた動作が基になっています。レプリケーションを有効にするには、weblogic-ejb-jar.xml デプロイメント ファイルの replication-type デプロイメント パラメータを InMemory に設定します。
図4-8 レプリケーションを有効にする XML の例
<stateful-session-clustering>
...
<replication-type>InMemory</replication-type>
</stateful-session-clustering>
インメモリ レプリケーションの制限事項
ステートフル セッション EJB の状態をレプリケートすることによって、プライマリ WebLogic Server インスタンスがダウンした場合でも、一般にクライアントは EJB の最後にコミットされた状態を取得できます。ただし、まれに発生する次のようなフェイルオーバのシナリオでは、最後にコミットされた状態を取得できない場合があります。
すべての EJB タイプの場合と同じように、エンティティ EJB は、home-is-clusterable を「true」に設定することによって、クラスタ対応のホーム スタブを利用できます。EJBObject スタブの動作は、weblogic-ejb-jar.xml の cache-strategy デプロイメント要素によって決まります。
read-write クラスタ内のエンティティ EJB
クラスタ内の read-write エンティティ EJB は、以下のとおり、非クラスタ化システム内のエンティティ EJB と同じように動作します。
図 4-9 は、WebLogic Server クラスタ環境での read-write エンティティ EJB の動作を示しています。ホーム スタブ上の 3 つの矢印は 3 つのサーバすべてを指し、複数のクライアント アクセスを示しています。
図4-9 クラスタ化されたサーバ環境の read-write エンティティ EJB
注意: 上の図では、ホーム スタブを起点とする矢印はいずれも各サーバの EJBHome を指しています。
read-write エンティティ EJB は、home-is-clusterable が true に設定されている場合に、安全な例外に関して自動フェイルオーバをサポートします。たとえば、メソッドの完了後に障害が発生した場合や、メソッドがサーバに接続されなかった場合などには、フェイルオーバが自動的にサポートされます。
クラスタ アドレス
クラスタをコンフィグレーションするとき、クラスタ内の管理対象サーバを識別するクラスタ アドレスを指定します。クラスタ アドレスはエンティティ Bean とステートレス Bean で、URL のホスト名部分を構成するために使用されます。クラスタ アドレスが設定されていない場合、EJB による処理が正しく機能しない場合があります。クラスタ アドレスの詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。
以降の節では、EJB コンテナによるトランザクション管理サービスのサポートについての情報を示します。いくつかのトランザクション シナリオを通して EJB を説明していきます。分散トランザクション（複数のデータストアで更新を行うトランザクション）に関与する EJB は、トランザクションのすべてのブランチが論理単位としてコミットまたはロールバックされることを保証します。
WebLogic Server の現行バージョンは、Java Transaction API（JTA）をサポートしています。JTA は、分散トランザクション対応アプリケーションの実装に使用できます。
また、1.1 と 2.0 のどちらの EJB の場合でも 2 フェーズ コミットがサポートされています。 2 フェーズ コミット プロトコルは、複数のリソース マネージャにまたがって 1 つのトランザクションを調整する手段です。これにより、トランザクションによる更新を関連データベースのすべてにコミットするか、またはすべてのデータベースから完全にロールバックし、トランザクションによる状態の前の状態に戻すことで、データの完全性が保証されます。トランザクションと 2 フェーズ コミット プロトコルの使い方については、「トランザクションについて」を参照してください。
セッション EJB は、自身のコード、そのクライアントのコード、または WebLogic Server コンテナに基づいてトランザクション境界を定義できます。EJB は、コンテナまたはクライアントによって定められたトランザクション境界を使用できます。しかし、一定の制限に従わない限り、独自のトランザクション境界を定義することはできません。
注意: EJB プロバイダが ejb-jar.xml ファイルにメソッドのトランザクション属性を指定しない場合、WebLogic Server はデフォルトによって supports 属性を使用します。
トランザクション イベントの順序は、コンテナ管理トランザクションの場合と Bean 管理トランザクションの場合で異なります。
javax.transaction.UserTransaction の使い方
EJB またはクライアント コードにトランザクション境界を定義するには、Java Transaction Service（JTS）または JDBC データベース接続を取得する前に、UserTransaction オブジェクトを取得してトランザクションを開始しなければなりません。データベース接続を取得してからトランザクションを開始した場合、その接続は新しいトランザクションと何の関連性も持たず、以後のトランザクション コンテキストにその接続を「入れる」ためのセマンティクスも存在しません。JTS 接続がトランザクション コンテキストに関連付けられていない場合、JTS 接続は自動コミットを true に設定した標準の JDBC 接続と同じように動作し、更新はデータストアに自動的にコミットされます。
いったんトランザクション コンテキスト内にデータベース接続を作成すれば、その接続はトランザクションがコミットまたはロールバックされるまで「予約」状態になります。アプリケーションのパフォーマンスとスループットを維持するには、常にトランザクションを迅速に完了させることによって、データベース接続を解放し、他のクライアント リクエストが使用できるようにする必要があります。詳細については、トランザクション リソースの保持を参照してください。
注意: アクティブなトランザクション コンテキストには単一のデータベース接続しか関連付けることができません。
コンテナ管理 EJB に対する制限
コンテナ管理によるトランザクションを使用する EJB 内で javax.transaction.UserTransaction メソッドを使用することはできません。
トランザクションのアイソレーション レベル
トランザクションのアイソレーション レベルを設定する方法は、アプリケーションで Bean 管理またはコンテナ管理のどちらによるトランザクション活性化を使用するかによって異なります。以下の節では、これらの両方のシナリオについて検討します。
ユーザ トランザクションのアイソレーション レベルの設定
ユーザ トランザクションのアイソレーション レベルは、Bean の Java コードで設定します。アプリケーションが実行されると、トランザクションが明示的に開始されます。レベルの設定方法を示すコードの例については、図 4-10 を参照してください。
図4-10 ユーザ トランザクションのアイソレーション レベルを設定するサンプルの Java コード
import javax.transaction.Transaction;
import java.sql.Connection
import weblogic.transaction.TxHelper:
import weblogic.transaction.Transaction;
import weblogic.transaction.TxConstants;
User Transaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");//ユーザ トランザクションを開始する
tx.begin();
//トランザクションのアイソレーション レベルを TRANSACTION_READ_COMMITED に設定する
Transaction tx = TxHelper.getTransaction();
tx.setProperty (TxConstants.ISOLATION_LEVEL, new Integer
(Connection.TRANSACTION_READ_COMMITED));
//トランザクションの処理を実行する
tx.commit();
コンテナ管理トランザクションのアイソレーション レベルの設定
コンテナ管理トランザクションのアイソレーション レベルは、weblogic-ejb-jar.xml デプロイメント ファイルの transaction-isolation 要素で設定します。WebLogic Server はこの値を基盤データベースに渡します。トランザクションの動作は、EJB のアイソレーション レベルの設定と、基盤の永続ストレージの同時実行性制御の両方によって決まります。コンテナ管理トランザクションのアイソレーション レベルの設定について、詳しくは『WebLogic JTA プログラマーズ ガイド』を参照してください。
TRANSACTION_SERIALIZABLE の制限
多くのデータストアでは、単一のユーザ接続が対象の場合でも、シリアライゼーションに関する問題の検出は限定的にしかサポートされていません。したがって、transaction-isolation を TRANSACTION_SERIALIZABLE に設定する場合でも、データストアの制限が原因でシリアライゼーションの問題に遭遇する場合があります。
アイソレーション レベルのサポートの詳細については、使用している RDBMS のマニュアルを参照してください。
Oracle データベースに関する特別な注意
Oracle ではオプティミスティックな同時実行性が採用されています。その結果として、TRANSACTION_SERIALIZABLE に設定したとしても、Oracle ではコミット時までシリアライゼーションの問題が検出されません。返されるメッセージは次のとおりです。
java.sql.SQLException: ORA-08177: can't serialize access for this transaction
EJB に対して TRANSACTION_SERIALIZABLE 設定を使用する場合でも、同じ行に対してクライアント間で競合が起きると、その EJB クライアントで例外またはロールバックを受け取ることがあります。こうした問題を避けるには、クライアント アプリケーションのコードが SQL 例外を検出および調査して、例外を解決するためにトランザクションをやり直すなどの適切なアクションを取るようにしなければなりません。
WebLogic Server では、メソッドに対してトランザクションのアイソレーション レベルを TRANSACTION_READ_COMMITTED_FOR_UPDATE に設定できます。設定されると、その時点から各 SELECT クエリには、選択したデータのロックを必要とする FOR_UPDATE が追加されます。この状態は、トランザクションが COMMIT または ROLLBACK を行うまで有効となります。
WebLogic Server は、複数のデータストアに分散されるトランザクションをサポートしています。このため、単一のデータベース トランザクションを複数のサーバの複数の EJB に分散できます。これらのタイプのトランザクションを明示的にサポートするには、トランザクションを開始し、複数の EJB を呼び出します。また、単一の EJB が、同じトランザクション コンテキスト内で暗黙的に動作する他の EJB を呼び出す場合もあります。以降の節では、これらのシナリオについて説明します。
単一トランザクション コンテキストからの複数の EJB の呼び出し
次のコードでは、クライアント アプリケーションは UserTransaction オブジェクトを取得し、それを使ってトランザクションを開始してコミットします。クライアントは、トランザクションのコンテキストの中で 2 つの EJB を呼び出します。各 EJB のトランザクション属性は、Required に設定されています。
コード リスト 4-1 トランザクションの開始とコミット
import javax.transaction.*;
...
u = (UserTransaction) jndiContext.lookup("javax.transaction.UserTransaction");u.begin();
account1.withdraw(100);
account2.deposit(100);
u.commit();
...
上のコードでは、「account1」および「account2」 EJB によって行われる更新は、単一の UserTransaction のコンテキスト内で発生します。EJB は、1 つの論理単位としてコミットまたはロールバックされます。このことは、「account1」と「account2」が同じ WebLogic Server、複数の WebLogic Server、または WebLogic Server クラスタのどれに存在している場合にも当てはまります。
EJB 呼び出しをこのようにラップするための条件は、「account1」と「account2」のどちらもクライアント トランザクションをサポートしなければならないということだけです。これを満たすには、Bean の trans-attribute 要素を Required、Supports、または Mandatory に設定します。
複数操作トランザクションのカプセル化
また、トランザクションをカプセル化する「ラッパー」 EJB を使用することもできます。クライアントは、ラッパー EJB を呼び出して銀行振替などのアクションを実行します。ラッパー EJB は、新しいトランザクションを開始し、1 つまたは複数の EJB を呼び出してトランザクションの作業を実行することで、それに応答します。
「ラッパー」EJB は、他の EJB を呼び出す前にトランザクション コンテキストを明示的に取得することもできます。また、EJB の trans-attribute 要素が Required または RequiresNew に設定されている場合、WebLogic Server は新しいトランザクション コンテキストを自動的に作成できます。trans-attribute 要素は、weblogic-ejb-jar.xml ファイルで設定します。ラッパー EJB によって呼び出されるすべての EJB は、トランザクション コンテキストをサポートできなければなりません（その trans-attribute 要素が Required、Supports、または Mandatory に設定されていなければなりません）。
WebLogic Server クラスタにおける EJB 間のトランザクションの分散
WebLogic Server は、WebLogic Server クラスタ内の EJB を使用するトランザクションのパフォーマンスを向上します。単一のトランザクションが複数の EJB を使用する場合、WebLogic Server は異なるサーバの EJB ではなく、単一のWebLogic Server インスタンスに存在する EJB インスタンスを使おうとします。この方法を使用すると、トランザクションのネットワーク トラフィックを最小限に抑えることができます。
場合によっては、トランザクションはクラスタ内の複数の WebLogic Server インスタンスに存在する EJB を使用します。これは、すべての EJB がすべての WebLogic Server インスタンスにデプロイされていない異種クラスタで起こる場合があります。このような場合、WebLogic Server は複数の直接接続ではなく 1 つの多層接続を使用してデータベースにアクセスします。この方法を使うと、リソースの使用量が減り、トランザクションのパフォーマンスが向上します。
しかし、最高のパフォーマンスを得るには、クラスタを同種にする必要があります。つまり、すべての EJB が使用可能なすべての WebLogic Server インスタンスに存在する必要があります。
Delay-Database-Insert-Until
デフォルトでは、データベースへの挿入はクライアントが ejbPostCreate メソッドを呼び出した後に行われます。WebLogic Server による新しい Bean の挿入を遅らせるには、weblogic-cmp-rdbms-jar.xml ファイルのdelay-database-insert-until 要素で、RDBMS CMP を使用する新しい Bean をいつデータベースに挿入するかを正確に指定します。
cmr-field が null 値を許可しない foreign-key column にマップされている場合、データベースの挿入を ejbPostCreate の後に遅らせる必要があります。この場合、 cmr-field を ejbPostCreate で null でない値に設定してから Bean をデータベースに挿入します。
注意: Bean の主キーが不明な段階で、cmr-fields を ejbCreate メソッド呼び出しの中で設定することはできません。
BEA では、ejbPostCreate メソッドが Bean の永続フィールドを変更した場合には、データベースの挿入を ejbPostCreate の後に遅らせるよう指定することを推奨しています。これにより、不要な保存操作を行わずに済むので、パフォーマンスが向上します。
最大限の柔軟性を実現するため、関連 Bean を ejbPostCreate メソッドで作成することは避けてください。こうしたインスタンスを追加作成すると、データベースの制約によって関連 Bean が未作成の Bean を参照できない場合、データベースの挿入を遅らせることができなくなる可能性があります。
delay-database-insert-until 要素には、以下の値を指定できます。
コード リスト 4-2 delay-database-insert until 要素を指定する XML の例
<delay-database-insert-until>ejbPostCreate</delay-database-insert-until> -->
以降の節では、EJB コンテナによるリソース サービスのサポートについての情報を示します。WebLogic Server では、EJB は JDBC ドライバを直接インスタンス化することによって JDBC 接続プールにアクセスできます。しかし、その代わりに、JDBC データソース リソースをリソース ファクトリとして WebLogic Server JNDI ツリーにバインドすることをお勧めします。
リソース ファクトリを使用すると、EJB はEJB デプロイメント記述子内のリソース ファクトリ参照を稼働中の WebLogic Server で使用可能なリソース ファクトリにマップできます。リソース ファクトリ参照は使用するリソース ファクトリ タイプを定義しなければなりませんが、リソースの実際の名前は、Bean がデプロイされるまで指定されません。
以降の節では、JDBC データソース および URL リソースを WebLogic Server の JDNI 名にマップする方法について説明します。
注意: WebLogic Server は、JMS 接続ファクトリもサポートしています。
JDBC データソース ファクトリの設定
次の手順に従って、javax.sql.DataSource リソース ファクトリを WebLogic Server 内の JNDI 名にバインドします。必要に応じて、トランザクション対応か非対応の JDBC データソースを設定できます。
トランザクション対応およびトランザクション非対応のデータソースをコンフィグレーションする方法の詳細については、「JDBC 接続の管理」を参照してください。
テキスト エディタを使用して、weblogic.ejb-jar.xml デプロイメント ファイルの resource-description 要素を直接編集して、既存の EJB リソース ファクトリ参照を JNDI 名にマップします。デプロイメント記述子の編集についての説明は、EJB デプロイメント記述子の指定と編集を参照してください。
URL 接続ファクトリの設定
WebLogic Server で URL 接続ファクトリを設定するには、次の手順で URL 文字列を JNDI 名にバインドします。
<WebServer URLResource="weblogic.httpd.url.testURL=http://
localhost:7701/testfile.txt" DefaultWebApp="default-tests"/>
<VirtualHostName=guestserver" targets="myserver,test_web_server
"URLResource="weblogic.httpd.url.testURL=http://
localhost:7701/testfile.txt" VirtualHostNames="guest.com"/>
以降の節では、EJB コンテナによるロック サービスのサポートについて説明します。WebLogic Server コンテナでは、データベース ロックと排他的ロック メカニズムの両方がサポートされています。EJB 1.1 および EJB 2.0 の Bean に対しては、デフォルト メカニズムであるデータベース ロックを使用することをお勧めします。
WebLogic Server 5.1 および 4.5.1 では、排他的ロックがデフォルトでした。ペシミスティック ロック方式は、EJB データへのアクセスの信頼性を高め、ejbLoad() を不必要に呼び出して EJB インスタンスの永続フィールドをリフレッシュするのを防ぎます。しかし、排他的ロック メカニズムは、EJB のデータへの同時アクセスに対しては最良のモデルとはなりません。いったんクライアントが EJB インスタンスをロックすると、他のクライアントは、永続フィールドを読もうとしているだけであっても、EJB のデータからブロックされてしまうからです。
WebLogic Server の EJB コンテナは、エンティティ EJB インスタンスに対して排他的ロック メカニズムを使用します。クライアントが EJB または EJB メソッドをトランザクションに関与させると、WebLogic Server はそのトランザクションの間そのインスタンスを排他的にロックします。同じ EJB またはメソッドを要求する他のクライアントは、現在のトランザクションが完了するまでブロックされます。
WebLogic Server 6.x では、データベース ロックがデフォルトとなっています。データベース ロックによって、エンティティ EJB の同時アクセスの処理速度が向上します。WebLogic Server コンテナでは、ロック サービスを基盤となるデータベースに任せます。排他的ロックとは異なり、基盤データ ストアはより高い粒度で EJB データをロックでき、またデッドロックを検出することができます。
データベース ロック メカニズムでは、EJB コンテナが引き続きエンティティ EJB クラスのインスタンスをキャッシュします。しかし、コンテナはトランザクション間の EJB インスタンスの中間状態をキャッシュしません。代わりに、WebLogic Server は、トランザクションの開始時に各インスタンスに対して ejbLoad() を呼び出して、最新の EJB データを取得します。続いて、データのコミット リクエストがデータベースに送られます。このためデータベースは、EJB データのロック管理とデッドロック検出をすべて処理します。
基盤となるデータベースにロックを任せることで、エンティティ EJB データへの同時アクセスのスループットを上げつつ、デッドロックの検出も実行できます。しかし、データベース ロックを使用するには、基盤となるデータベースのロック方式に関するより詳細な知識が必要となります。この結果、EJB の異なるシステム間での移植性が低下する可能性があります。
weblogic-ejb-jar.xml の concurrency-strategy デプロイメント パラメータを設定することによって、EJB 用に使用するロック メカニズムを指定します。concurrency-strategy は個々の EJB レベルで設定するので、EJB コンテナ内でロック メカニズムが混在することがあります。
次の weblogic-ejb-jar.xml からの引用に、データベース ロックを使用する EJB を示します。
コード リスト 4-3 データベース ロックの例
<entity-descriptor>
<entity-cache>
...
<concurrency-strategy>Database</concurrency-strategy>
</entity-cache>
...
</entity-descriptor>
concurrency-strategy を指定しない場合、データベース ロック サービスで説明したとおり、WebLogic Server はエンティティ EJB インスタンスに対してデータベース ロックを実行します。
|
|
|