|
|
この章では、アプリケーションでエンティティ Bean をプログラミングおよび使用するための WebLogic Server の付加価値機能について説明し、関連する設計および開発上のガイドラインを示します。
この章は、Java のプログラミングおよびエンティティ Bean の機能に精通している読者を対象としています。エンティティ Bean の概要およびエンティティ Bean のアプリケーションでの典型的な使用方法については、「エンティティ EJB による永続データの保持」および「エンティティ Bean の機能」を参照してください。
Bean 開発の全体的なプロセスについては、「エンタープライズ JavaBean の実装」を参照してください。
WebLogic Server には、エンティティ EJB のパフォーマンスとスループットを向上させる以下の機能があります。
図 6-1 は、エンティティ Bean インスタンスのライフサイクルを示しています。この節では、プール処理について、およびコンテナがフリー プールとキャッシュにデータを格納して管理する仕組みについて説明します。
weblogic-ejb-jar.xml で initial-beans-in-free-pool 要素にゼロ以外の値を指定すると、WebLogic Server は起動時に指定された量の Bean インスタンスをプールに格納します。
initial-beans-in-free-pool のデフォルト値はゼロです。起動時に Bean インスタンスをフリー プールに格納しておくと、要求が来てから新しいインスタンスを生成せずに Bean に対する初期要求が可能になるため、EJB の初期応答時間が短縮されます。このリリースの WebLogic Server では、管理者は Administration Console を使用して EJB プールを必要に応じて初期化できます。初期化されたプールは、EJB がデプロイされた直後の状態にリセットされます。詳細については、Administration Console オンライン ヘルプの「EJB のアイドル状態の Bean のキャッシュおよびプールの初期化」を参照してください。
フリー プールからエンティティ Bean のインスタンスを取得しようとすると、その試みはプールが空の場合でも必ず成功します。プールが空の場合は、新しい Bean インスタンスが作成されて返されます。
プールされた Bean は匿名インスタンスであり、ファインダおよびホーム メソッドで使用されます。プールに格納できるインスタンスの最大数は、weblogic-ejb-jar.xml の max-beans-in-free-pool 要素で指定します (デフォルト設定は 1,000)。
WebLogic Server をコンフィグレーションすることによって、プール内のエンティティ Bean が pool 要素の idle-timeout-seconds 要素で指定した期間にわたって未使用であった場合にその Bean を削除できます。idle-timeout-seconds で指定する期間にわたってプール内の Bean が未使用である場合、そのプール内の Bean は initial-beans-in-free-pool で指定されている数まで削除されます。プール内の Bean の数は、initial-beans-in-free-pool で指定されている数より少なくなることはありません。
Bean でビジネス メソッドが呼び出されると、コンテナはプールからインスタンスを取得し、ejbActivate を呼び出して、そのインスタンスがメソッド呼び出しに対応します。
READY インスタンスはキャッシュにあり、ID (関連付けられた主キー) を持ちますが、現時点ではトランザクションに登録されていません。READY エンティティ EJB のインスタンスは、最長時間未使用 (LRU) の順で維持されます。
ACTIVE インスタンスは、現時点でトランザクションに登録されています。トランザクションの完了後、そのインスタンスは READY になり、他の Bean 用にスペースが必要になるまでキャッシュにとどまります。
Administration Console の [モニタ] タブの [現在のキャッシュ済み Bean 数] フィールドには、READY および ACTIVE Bean の数が表示されます。また、このリリースの WebLogic Server では、管理者は Administration Console を使用してキャッシュを必要に応じて初期化できます。初期化されたキャッシュは、EJB がデプロイされた直後の状態にリセットされます。詳細については、Administration Console オンライン ヘルプの「EJB のアイドル状態の Bean のキャッシュおよびプールの初期化」を参照してください。
max-beans-in-cache 要素の効果とキャッシュで許可される主キーが同じインスタンスの数は、同時方式によって異なります。表 6-1 は、同時方式ごとに、weblogic-ejb-jar.xml の max-beans-in-cache 要素の値がキャッシュ内のエンティティ Bean インスタンスの数をどのように制限するのか、および同じ主キーでエンティティ Bean インスタンスがいくつキャッシュ内で許可されるのかを示しています。
READY のエンティティ EJB インスタンスは、他の Bean でスペースが必要なときにキャッシュから削除されます。READY インスタンスがキャッシュから削除され、Bean で ejbPassivate が呼び出されて、コンテナがそのインスタンスをフリー プールに戻そうとします。
WebLogic Server をコンフィグレーションすることによって、キャッシュ内のエンティティ インスタンスが idle-timeout-seconds 要素で指定した期間にわたってアイドル状態である (トランザクションに参加していない) 場合にそのインスタンスを定期的に削除できます。
コンテナがインスタンスをフリー プールに戻そうとしたときに、プールがすでに max-beans-in-free-pool 数のインスタンスで満たされている場合、インスタンスは破棄されます。
ACTIVE のエンティティ EJB インスタンスは、そのインスタンスが参加しているトランザクションがコミットまたはロールバックされるまでキャッシュから削除されません。トランザクションがコミットまたはロールバックされた時点で、インスタンスは READY になり、キャッシュから削除できるようになります。
満杯であるキャッシュにエンティティ Bean が追加されようとしたときに、トランザクションに参加しているエンティティ Bean は、必要な場合、CacheFullException を回避するためにパッシブ化することができます。パッシベーションは EJB コンテナによって自動処理されるため、この機能を使用するために EJB のプログラミングを変更する必要はありません。しかし、必要な場合、EJB が現在のトランザクション内のすべての操作を実行したことをキャッシュに伝えるようにプログラミングできます。この場合、キャッシュは Bean のパッシベーションが可能かどうかを評価するときにこの情報を利用します。
EJB が現在のトランザクション内のすべての操作を実行したことをキャッシュに伝えるようにプログラミングするには、次のように operationsComplete Java API を使用します。
weblogic.ejb.interfaces.EJBLocalObject
public.void.operationsComplete()
weblogic.ejb.EJBObject
public.void.operationsComplete()
この節では、CMP 2.1 エンティティ Bean の永続データがいつどのようにしてキャッシュにロードされ、永続ストレージに書き込まれるのかを説明します。
findXXX() - デフォルトでは、CMP Bean でファインダ メソッドを呼び出すと、Bean の永続データがすぐにキャッシュにロードされる。この動作は、weblogic-ejb-jar.xml の persistence 要素の finders-load-bean 要素で制御します。ejbLoad() - CMP 2.1 エンティティ Bean の場合は、ejbLoad() を呼び出すと、Bean のデータに対して次に getXXX() が呼び出されたときに Bean の永続データがエンティティ キャッシュに「怠惰」にロードされる。したがって、CMP 2.0 エンティティ Bean のインスタンスでトランザクションが開始されるときは、Bean が最後にキャッシュにロードされてから ejbLoad() が呼び出されていない限り、WebLogic Server はデータベースからではなくエンティティ キャッシュから Bean のデータを読み込みます。
デフォルトでは、WebLogic Server はエンティティ Bean で新しいトランザクションが開始されるたびに ejbLoad() を呼び出します。
| 注意 : | CMP 1.1 のエンティティ Bean および Bean 管理による永続性を使用するエンティティ Bean で使用する場合、ejbLoad() は怠惰なロードを実行しません。それらの Bean タイプの場合、Bean の永続データは ejbLoad() の間にキャッシュにロードされます。 |
ejbStore() - WebLogic Server は、ejbStore() の呼び出しを使用してエンティティ EJB の永続フィールドをデータベースに書き込む。
デフォルトでは、WebLogic Server はトランザクションのコミット時に ejbStore() を呼び出します。
複数のクライアントが Bean の基底データにアクセスして修正できるアプリケーションの場合、「ejbLoad() と ejbStore() の動作について」で説明されている ejbLoad() と ejbStore() のデフォルトの動作では、以下のようにしてデータベースの整合性が確保されます。
ただし、要件によっては、ejbLoad() および ejbStore() の呼び出し回数を増やすか減らす必要があるかもしれません。たとえば、パフォーマンス上の理由から、データベースにアクセスする呼び出しを制限することが必要な場合もあります。アプリケーションが複数のトランザクションの EJB への同時アクセスを許可しない場合 (たとえば Bean が Exclusive 同時方式を使用している場合)、各トランザクションの開始時にデータをロードする必要はありません。他のクライアントやシステムが EJB の基底データを更新しないとすると、キャッシュされた EJB のデータは常に最新の状態であり、ejbLoad() を呼び出すことは余計なオーバーヘッドにつながります。そのような場合は、ejbLoad() の呼び出し回数を安全に減らすことができます (「cache-between-transactions によるデータベース読み込みの制限 (長期キャッシング)」を参照)。
あるいは、トランザクションの中間結果を利用するために、トランザクションのコミット前に呼び出して ejbStore() の標準動作から逸脱することが必要な場合もあるかもしれません。手順については、「トランザクション終了前のデータベースの更新」を参照してください。
EJB の仕様によると、トランザクションによる更新内容は、トランザクションで発行されたクエリ ファインダおよび ejbSelect の結果に反映させる必要があります。この要件に従うとパフォーマンスが低下する場合があります。クエリの実行前にキャッシュをフラッシュしたくない場合は、weblogic-cmp-jar.xml の include-updates 要素の値をデフォルト値の True から False に変更できます。
キャッシュのフラッシュを無効にするかどうかは、データが最新であることよりもパフォーマンスを重視するかどうかで判断します。include-updates を False に設定するとパフォーマンスは最高になりますが、現在のトランザクションの更新がクエリで反映されません。include-updates が True の場合、コンテナはトランザクションの変更をすべてデータベースにフラッシュしてから新しいクエリを実行します。
トランザクションが修正されたデータのクエリを再実行しない場合は (一般的なシナリオ) キャッシュのフラッシュを安全にオフにして、最高のパフォーマンスを得ることができます。
アプリケーションレベルのキャッシング (「組み合わせキャッシング」とも呼ばれる) では、同じ J2EE アプリケーションに属する複数のエンティティ Bean が 1 つの実行時キャッシュを共有できます。各キャッシュを何個のエンティティ Bean が参照するかについて制限はありません。
アプリケーションレベルのキャッシングには以下の利点があります。
ただし、アプリケーションレベルのキャッシングは、スループットの高いアプリケーションにとっては最適な選択肢ではありません。1 つのキャッシュにつき一度に 1 つの制御スレッドしかないので、スループットが高い場合は、複数のタスクがスレッドの制御を奪い合ってそれがボトルネックになることがあります。
アプリケーションレベルのキャッシュをコンフィグレーションするには、次の手順に従います。
weblogic-application.xml ファイルが EAR ファイルの META-INF ディレクトリ内にあるか確めます。weblogic-application.xml の entity-cache 要素でアプリケーションレベルのキャッシュを定義します。この要素とその子要素の定義については、『WebLogic Server アプリケーションの開発』の「entity-cache」を参照してください。weblogic-ejb-jar.xml の entity-descriptor 要素の entity-cache-ref 要素でアプリケーションレベルのキャッシュを参照します。 weblogic-application.xml で指定されているアプリケーション レベルのキャッシュの名前でなければならない。weblogic-application.xml の caching-strategy と一致していなければならない。読み込み専用エンティティは、マルチバージョンのアプリケーション レベル キャッシュのみを使用できます。詳細については、『WebLogic Server アプリケーションの開発』の「caching-strategy」を参照してください。
weblogic-application.xml デプロイメント記述子については、『WebLogic Server アプリケーションの開発』の「weblogic-application.xml デプロイメント記述子の要素」を参照してください。
すべてのエンティティ EJB には、そのホームでエンティティ Bean をユニークに識別する主キーが必要です。個々のエンティティ Bean インスタンスは、その主キーに対して別のクラスを定義できます (複数のエンティティ Bean が必要に応じて同じ主キー クラスを使用できる)。
2 つのエンティティ Bean インスタンスのホームと主キーが共通する場合、両者は同一のものと見なされます。クライアントはエンティティ Bean インスタンスのリモート インタフェースへの参照に対して getPrimaryKey() メソッドを呼び出して、そのホーム内でのインスタンスの ID を調べることができます。
参照と関連付けられたインスタンス ID は、参照が有効な間は変化しません。したがって getPrimaryKey() メソッドは、同じエンティティ オブジェクトの参照に対して呼び出されたときは常に同じ値を返します。エンティティ オブジェクトの主キーを知っているクライアントは、Bean のホーム インタフェースの findByPrimaryKey(key) メソッドを呼び出すことによって、エンティティ オブジェクトへの参照を取得することができます。
エンティティ Bean クラスでは、主キーを 1 つの CMP フィールドにマップできます。CMP フィールドは、ejb-jar.xml と weblogic-cmp-jar.xml の両方で指定する必要があります。両方の記述子ファイルで、CMP フィールドは cmp-field 要素で指定します。単純主キーの場合は、ejb-jar.xml の primkey-field 要素でも主キーを指定します。さらに、ejb-jar.xml の prim-key-class 要素で主キー フィールドのクラスを指定します。
1 つまたは複数のフィールドに対応する独自の主キー クラスを定義することができます。主キー クラスは public でなければならず、パラメータを付けない public コンストラクタを持たなければなりません。ejb-jar.xml の prim-key-class 要素で主キー クラスの名前を指定します。主キー クラスのすべてのフィールドは public でなければならず、ejb-jar.xml および weblogic-ejb-jar.xml の対応する cmp-field と同じで名前を持つ必要があります。複数の CMP フィールドに対応する複合主キーの場合は、ejb-jar.xml で primkey-field を指定しません。
エンティティ Bean が無名主キークラスを使用する場合、EJB をサブクラス化し java.lang.Integer 型の cmp-field をそのサブクラスに追加する必要があります。そのフィールドの自動主キー生成を有効にし、コンテナがフィールドの値を自動的に埋め、そのフィールドを weblogic-cmp-jar.xml デプロイメント記述子のデータベース カラムにマップできるようにします。
最終的に、ejb-jar.xml ファイルを更新して元の EJB クラスではなく EJB サブクラスを指定するようにし、その Bean を WebLogic Server にデプロイします。
| 注意 : | 元の EJB を無名主キー クラスとともに使用した場合、デプロイメント時に WebLogic Server から次のエラー メッセージが表示されます。 |
| 注意 : | In EJB ejb_name, an 'Unknown Primary Key Class' ( <prim-key-class> == java.lang.Object ) MUST be specified at Deployment time (as something other than java.lang.Object). |
WebLogic Server で主キーを使用するときには以下の提言に従ってください。
ejbCreate を使用して新しい主キー クラスを作成しないでください。その代わりに、「主キーの自動生成」の説明に従ってコンテナ内部で主キー クラスを作成できるようにしてください。String または Integer などの原子的な値 1 つで構成された単純主キーの場合は、その主キー クラスをコンテナ管理によるフィールドにします。ejbCreate メソッド内で setXXX メソッドを使用して、主キーの cmp-field の値を設定します。BigDecimal 型の cmp-field は、CMP Bean の主キー フィールドとして使用しないでください。boolean BigDecimal.equals (object x) メソッドでは、値とスケールが同じ場合に限り 2 つの BigDecimal が等しいと判断されます。なぜなら、Java 言語とさまざまなデータベースでは精度に違いがあるからです。たとえば、このメソッドでは 7.1 と 7.10 は等しいとは判断されません。したがって、このメソッドを使用すると、ほとんどの場合で False が返されるか、CMP Bean でエラーが発生します。
BigDecimal を主キーとして使用する必要がある場合は、次の操作を行ってください。
cmp-field が主キー フィールドである場合は、ejbCreate() メソッドが呼び出されたときに cmp-field の setXXX メソッドを使用して値を設定します。その場合、cmr-field は自動的に初期化され、cmr-field の setXXX メソッドは使用できません。逆に、cmp-field が主キー フィールドでない場合には、cmp-field が読み込み専用です。カラムは cmr-field を使用して更新され、cmp-field は外部キーの読み出し専用ビューを提供します。
WebLogic Server は、CMP エンティティ Bean での自動主キー生成機能をサポートしています。この機能は、単純 (非複合) 主キーでのみサポートされています。
WebLogic Server は、自動主キー生成の 2 通りの手法をサポートしています。
weblogic-cmp-jar.xml の <automatic-key-generation> 要素でデータベースとジェネレータ名を指定します。コンテナは、コンフィグレーションされた値に基づいてデータベースから主キーを取得するコードを生成します。この機能は、Oracle および Microsoft SQL Server データベースのみでサポートされています。「主キー フィールドの型の宣言」の手順も参照してください。
どちらの方法を使用する場合でも、「主キー フィールドの型の宣言」の手順を参照してください。
Oracle データベース用の主キー生成サポートでは、Oracle データベースの SEQUENCE エンティティを使用してユニークな主キーを生成します。Oracle SEQUENCE は、新しい数値が必要な場合に呼び出されます。自動キー生成は、weblogic-cmp-jar.xml の automatic-key-generation 要素で指定します。generator-name 要素で、Oracle SEQUENCE の名前を指定します。Oracle SEQUENCE が SEQUENCE INCREMENT で作成された場合は、key-cache-size を指定します。key-cache-size の値は、Oracle SEQUENCE INCREMENT の値と同じでなければなりません。2 つの値が違う場合は、キーが重複することがあります。
主キーの生成で Oracle SEQUENCE オブジェクトを使用する場合は、以下の点に注意してください。
USER_DESIGNATED_TABLE に設定しない。そのように設定すると TX ISOLATION LEVEL が SERIALIZABLE に設定され、次の例外が生じる場合があります。
javax.ejb.EJBException: nested exception is: java.sql.SQLException: Automatic Key Generation Error: attempted to UPDATE or QUERY NAMED SEQUENCE TABLE NamedSequenceTable, but encountered SQLException java.sql.SQLException: ORA-08177: can't serialize access for this transaction.
代わりに、Oracle では AutoKey オプションを使用します。
SEQUENCE スキーマ オブジェクトに対応する Oracle の同様の機能をサポートしていない。SEQUENCE と同様の機能を使用するアプリケーションを WebLogic Server 8.1 より前のリリースからこのリリースに移行すると、以下のエラーが生じます。
[EJB:011066]During EJB deployment, error(s) were encountered while setting up The ORACLE SEQUENCE named 'XXX' with INCREMENT value '1'
[EJB:011064]The ORACLE SEQUENCE named 'XXX' with INCREMENT '1' was not found in the database'
Microsoft SQL Server データベース用の主キー生成サポートでは、SQL Server の IDENTITY カラムが使用されます。Bean が作成され、新しい行がデータベース テーブルに挿入されると、SQL Server は、IDENTITY カラムとして指定されたカラムに、次の主キー値を自動的に挿入します。
| 注意 : | IDENTITY カラムの含まれる SQL Server テーブル作成の手順については、Microsoft のドキュメントを参照してください。 |
テーブルで IDENTITY カラムが作成されたら、次のように weblogic-cmp-jar.xml で自動キー生成を指定してください。
<automatic-key-generation>
<generator-type>SQLServer</generator-type>
</automatic-key-generation>
シーケンス テーブルは、データベースに依存しない主キーを生成する手段です。シーケンス テーブルは、Bean インスタンスの作成時にその主キー値として使用される、一定の割合で増加する整数のシーケンス値を保持します。
現在の主キー値を保持する SEQUENCE という名前のテーブルを作成します。このテーブルは、次の文で定義するように、1 行 1 カラムで構成されます。
CREATE table_name (SEQUENCE int)
INSERT into table_name VALUES (0)
この機能を使用するには、基底のデータベースがトランザクションのアイソレーション レベル Serializable をサポートしていなければなりません。Serializable 値は、このトランザクションを同時に複数回実行すると、トランザクションを順番に複数回実行するのと同じ結果になることを示します。これは、複数のサーバ インスタンスがシーケンス テーブルに同時にアクセスする WebLogic Server クラスタで重要です。データベースがサポートするアイソレーション レベルを確認するには、そのデータベースのドキュメントを参照してください。
自動キー生成は、weblogic-cmp-jar.xml ファイルで次のように指定します。「主キー フィールドの型の宣言」の手順も参照してください。
<automatic-key-generation>
<generator-type>NamedSequenceTable</generator-type>
<generator_name>MY_SEQUENCE_TABLE_NAME</generator-name>
<key-cache-size>100</key-cache-size>
</automatic-key-generation>
generator-name 要素で、シーケンス テーブルの名前を指定します。
キー キャッシュのサイズ (1 回の DBMS 呼び出しでコンテナが取得するキーの数) は、key-cache-size 要素で指定します。key-cache-size は、1 より大きく設定することをお勧めします。この設定により、次のキー値を取得するためのデータベースの呼び出し回数を減らすことができます。
NAMED SEQUENCE テーブルは Bean のタイプごとに定義することをお勧めします。異なるタイプの Bean が NAMED SEQUENCE テーブルを共有しないようにしてください。こうすることで、キー テーブルの競合の発生を防ぎます。
ネイティブの DBMS 主キー生成と、命名済シーケンス テーブルを使用したキー生成の両方について、関連付けられたエンティティ Bean の抽象 get メソッドおよび set メソッドで、主キー フィールドの型を以下のいずれかとして宣言します。
weblogic-cmp-jar.xml では、シーケンスの主キー値がデータベースから一度にいくつ取得されるのかを指定する key-cache-size 要素を設定します。たとえば key_cache_size を 10 に設定すると、Bean が 10 作成されるたびに一度データベース アクセスが実行されてシーケンスが更新されます。key_cache_size のデフォルト値は 1 です。データベース アクセスを最小限に抑えてパフォーマンスを向上させるために、key_cache_size には 1 より大きい値を設定することを推奨しています。
WebLogic Server は、Oracle SEQUENCE (呼び出されるたびにユニークな整数を生成する番号ジェネレータ) を自動的に作成できます。
Oracle SEQUENCE は、指定された「インクリメント値」を使用できます。インクリメント値とは、生成ごとに整数が大きくなる増加量のことです。たとえば、SEQUENCE で整数 24 が生成され、インクリメント値が 10 の場合、SEQUENCE で生成される次の整数は 34 になります。
このリリースの WebLogic Server では、デフォルトによって、EJB コンテナは文字列値 CMP フィールドがデータベースから取得されたときにその末尾のスペースを削除します。すべての文字列値 CMP フィールドのセット メソッドでも、末尾のスペースが削除されます。
主キー フィールド内のスペースを削除しない場合、比較演算子が正常に機能せず、移植できない動作を引き起こす場合があります。自動文字列削除の利点は、データベースから取得された文字列が、データベースに挿入された文字列と同じになることです。次に例を示します。
取得した「smith 」と元の「smith」の比較演算は、取得した値の末尾のスペースを事前に削除しない限り失敗します。このリリースの WebLogic Server では、末尾のスペースは自動的に削除されるため、比較演算が失敗することはありません。
このリリースでは、デフォルトによって自動文字列削除が有効になっています。DDConverter を使用して旧リリースの WebLogic Server のデプロイメント記述子を変換する場合、DDConverter は作成する新しいデプロイメント記述子で文字列削除を自動的に無効にします。
このリリースの WebLogic Server で新しく作成するデプロイメント記述子で文字列削除を無効にする場合、weblogic-cmp-jar.xml の disable-string-trimming を True に設定します。disable-string-trimming 要素の詳細については、「disable-string-trimming」を参照してください。
この節では、エンティティ EJB をデータベース テーブルにマップし、データベース アクセスの動作を制御する方法を示します。
CMP Bean は、1 つまたは複数のデータベース テーブルにマップできます。1 つの CMP Bean を複数のテーブルにマップする場合、各テーブルには、1 つの特定の Bean インスタンスに対応する 1 行が含まれます。このため、Bean がマップされる各テーブルにはいつでも同じ数の行が含まれ、同種の主キー値が同じように格納されます。したがって、各テーブルには同数の主キー カラムが含まれ、別々のテーブルの対応している主キー カラムどうしは名前は違うとしても同じタイプでなければなりません。同じ Bean にマップされる複数のテーブルの主キー間に、参照一貫性制約を課してはなりません。参照一貫性制約がある場合は、Bean インスタンスを削除すると実行時エラーが発生します。
Bean の cmp-field をテーブルのカラムにマップするには、weblogic-cmp-jar.xml の table-map 要素を使用します。その際、Bean がマップされるデータベース テーブルごとに 1 つの table-map 要素を指定します。各 table-map 要素は、テーブルの主キー カラムを Bean の主キー フィールドにマップします。主キー以外のフィールドは、1 つのテーブルにマップされるだけの場合もあります。
コード リスト 6-1 とコード リスト 6-2 は、1 つのテーブルにマップされる Bean と複数のテーブルにマップされる Bean の table-map 要素を示しています。
<table-map>
<table-name>TableName</table-name>
<field-map>
<cmp-field>name</cmp-field>
<dbms-column>name_in_tablename</dbms-column>
</field-map>
<field-map>
<cmp-field>street_address</cmp-field>
<dbms-column>street_address_in_tablename
</dbms_column>
</field-map>
<field-map>
<cmp-field>phone</cmp-field>
<dbms-column>phone_in_tablename</dbms-column>
</field-map><table-map>
<table-name>TableName_1</table-name>
<field-map>
<!-- 「name」はこの EJB の主キー フィールド -->
<cmp-field>name</cmp-field>
<dbms-column>name_in_tablename_1</dbms-column>
</field-map>
<field-map>
<cmp-field>street_address</cmp-field>
<dbms-column>street_address_in_tablename_1</dbms-column>
</field-map>
</table-map>
<table-map>
<table-name>TableName_2</table-name>
<field-map>
<!-- 「name」はこの EJB の主キー フィールド -->
<cmp-field>name</cmp-field>
<dbms-column>name_in_tablename_2</dbms-column>
</field-map>
<field-map>
<cmp-field>phone</cmp-field>
<dbms-column>phone_in_tablename_2</dbms-column>
</field-map>
</table-map>
WebLogic Server の EJB コンテナは、反復的な開発を容易にするために、エンティティ Bean が変更されたときに自動的に基底のテーブル スキーマを変更するようにコンフィグレーションできます。そのようにコンフィグレーションすると、テーブルはオブジェクトの関係の最新のマッピングを常に反映するようになります。
| 注意 : | この機能は、サーバ インスタンスがプロダクション モードで実行されている場合は無効です。プロダクション環境では、より正確なテーブル スキーマ定義を使用することが必要な場合があるからです。確実にコンテナによって作成されたテーブルだけが変更されるように、コンテナで作成されたテーブルには、wls_temp という追加カラムが含まれています。 |
テーブル作成文の構文 (DDL) はデータベースによって異なるので、テーブルの作成はフルサポートされていないデータベースでは失敗する場合があります。その場合、テーブルは手作業で作成します。
| 注意 : | シーケンス テーブル、結合テーブル、および Oracle SEQUENCE がサポートされています。 |
weblogic-cmp-jar.xml の create-default-dbms-table 要素を使用してこの機能を有効化します。この機能の動作は、次の表で説明するように、要素の値に応じて変わります。この表に示す EJB コンテナのアクションは、デプロイ中に発生します。
CMP Bean を作成するときに発生する場合のあるタイミングの問題のため、WebLogic Server では Bean の作成プロセスのどの時点で Bean がデータベースに挿入されるのかを指定することができます。
cmr-field は、Bean の主キー値 (ejbPostCreate が呼び出されて設定される) がアクセス可能になるまで設定できません。したがって、cmr-field は ejbPostCreate が呼び出されるまで設定できません。この要因が他の条件と重なると、以下の問題が生じることがあります。
データベースの行が ejbCreate の後 (つまり、ejbPostCreate の前) に挿入された場合、外部キーは null 値になります。その理由は、外部キー カラムが cmr-field の設定時に設定されるからです。
解決策 : weblogic-cmp-jar.xml の delay-insert-until を ejbCreate に設定し (この設定で、挿入は ejbCreate の直後に行われる)、ejbPostCreate の過程で関係を設定します。
ejbPostCreate の過程での Bean の作成
関連する Bean が作成されるときに、その Bean のデータベースの挿入が、作成の呼び出しが終了する前に行われます。関連する Bean のデータベース行に、現在の Bean を表す外部キーが含まれており、その外部キーで参照一貫性制約が定義されている場合、挿入は現在の Bean のデータベース行がまだ挿入されていない場合は失敗します。
解決策 : delay-insert-until を ejbCreate に設定し、現在の Bean の行が ejbPostCreate の間存在するようにします。
| 注意 : | 1 対 1 の関係では、親 Bean の主キーが子 Bean の CMR フィールドに埋め込まれている場合、EJB コンテナが Bean を作成するときに、パフォーマンス上の理由からその親 Bean に子があるかどうかが確認されません。duplicationKeyException データベース例外を防止するには、データベースの子テーブルで外部キー制約を設定する必要があります。 |
解決策 : ejbPostCreate の間に関連する Bean を作成しないようにします。現在の Bean を作成し、その作成が終了した後に、関連する Bean を作成して関係を設定します。
これが、アプリケーションで常に行われるようにすることをお勧めします。アプリケーションでは、別の Bean の作成時に関連する Bean を作成してはなりません。
weblogic-cmp-jar.xml の delay-database-insert-until 要素を使用すると、EJBCreate メソッドまたは ejbPostCreate メソッドが終了するまでデータベースの挿入を遅らせることができます。トランザクションの最後に更新を一括で順序付けして実行するには、weblogic-cmp-jar.xml で enable-batch-operations と order-database-operations の両方を「True」に設定します。
関連する Bean を更新するトランザクションでデータベースの更新を遅延させる場合は、weblogic-cmp-jar.xml の weblogic-rdbms-relation で Bean 間の関係を定義する必要があります。そのように定義しないと、EJB コンテナが更新を実行しようとしたときに、データベースの制約エラーが発生する場合があります。
「ejbLoad() と ejbStore() の動作について」で説明されているように、デフォルトでは、WebLogic Server はエンティティ Bean でトランザクションが開始されるたびに ejbLoad() を呼び出します。
クライアントが最初に Bean を参照するとき、またはトランザクションがロールバックされたときにのみ ejbLoad() を呼び出すように WebLogic Server をコンフィグレーションできます。この動作は、長期キャッシングと呼ばれます。長期キャッシングを有効化するには、weblogic-ejb-jar.xml の cache-between-transactions 要素を true に設定します。
長期キャッシングは、Bean の concurrency-strategy が Exclusive、ReadOnly、または Optimistic の場合のみ許可されます。長期キャッシングがコンフィグレーションされている場合の動作は以下のとおりです。
ReadOnly Bean の場合、WebLogic Server は cache-between-transactions の値を無視する。WebLogic Server は、cache-between-transactions の値に関係なく常に読み込み専用データの長期キャッシングを実行します。 Exclusive Bean の場合、EJB コンテナは基底データへの排他的な更新アクセスが可能である必要がある。データが、EJB コンテナ外の別のアプリケーションで更新されることはあってはなりません。 | 注意 : | 同時方式が Exclusive の Bean がクラスタにデプロイされた場合、長期キャッシングが自動的に無効になります。クラスタ内では、どのサーバ インスタンスも Bean データを更新できるからです。このため、トランザクション間のキャッシングは不可能になります。 |
Optimistic Bean の場合、EJB コンテナはクライアントが最初に Bean を参照した後に各トランザクションでキャッシュされたデータを再利用するが、各トランザクションの最後にオプティミスティックな衝突をチェックすることで更新がトランザクションとして一貫性を持つようにする。 | 注意 : | クラスタでは、同時方式が Optimistic の Bean が更新されると、オプティミスティックな衝突を防止するために他のクラスタ メンバーに通知がブロードキャストされます。 |
表 6-3 は、エンティティ Bean のタイプおよび同時方式別の cache-between-transactions 要素の有効値を示しています。
「ejbLoad() と ejbStore() の動作について」で説明されているように、デフォルトでは、WebLogic Server はトランザクションのコミット時にのみ ejbStore() を呼び出します。
未コミット トランザクションの中間結果を他のデータベース ユーザが利用できるようにするには、weblogic-ejb-jar.xml の persistence 要素の delay-updates-until-end-of-tx を False に設定します。この設定により、WebLogic Server は各メソッド呼び出しの後に ejbStore() を呼び出すようになります。
| 注意 : | delay-updates-until-end-of-tx を false に設定すると、各メソッド呼び出しの後にデータベースの更新が行われますが、その更新はトランザクションが終わるまでコミットされません。 |
動的クエリを使用すると、各自のアプリケーション コードで EJB-QL または SQL クエリをプログラム的に作成および実行できるようになります。
weblogic-ejb-jar.xml の enable-dynamic-queries 要素を True に設定します。
<enable-dynamic-queries>True</enable-dynamic-queries>
ejb-jar.xml デプロイメント記述子ファイルの method-permission 要素を指定することによって、標準メソッド権限を設定し、動的クエリへのアクセスを制御します。
weblogic.ejb.QueryHome インタフェースの createQuery() メソッドの method-permission を設定することによって、動的クエリを実行する weblogic.ejb.Query オブジェクトへのアクセスを制御します。
createQuery() メソッドの method-permission を指定した場合、method-permission の設定が Query クラスの実行と検索メソッドに適用されます。
次のサンプル コードでは、動的クエリをどのように実行するかを示します。
InitialContext ic=new InitialContext();
FooHome fh=(FooHome)ic.lookup("fooHome");
QueryHome qh=(QueryHome)fh;
String ejbql="SELECT OBJECT(e)FROM EmployeeBean e WHERE e.name='rob'"Query query=qh.createQuery();
query.setMaxElements(10)
Collection results=query.find(ejbql);
WebLogic Server は、Oracle および DB2 Binary Large Object (BLOB) および Character Large Object (CLOB) DBMS カラムを CMP エンティティ Bean でサポートしています。
WebLogic Server は、バイト配列またはシリアライズ可能な型を持つ cmp-field に BLOB をマップします。現時点では、char 配列を CLOB カラムにマップすることはできません。
BLOB/CLOB サポートを有効にするには次の手順に従います。
次の XML コードは、weblogic-cmp-jar-xml ファイルの dbms-column-type 要素を使用して BLOB オブジェクトを指定する方法を示しています。
<field-map>
<cmp-field>photo</cmp-field>
<dbms-column>PICTURE</dbms-column>
<dbms-column-type>Blob</dbms-column-type>
<dbms-default-value>DB2</dbms-default-value>
</field-map>
このリリースの WebLogic Server では、Blob にマップされる byte[] 型の cmp-field はデフォルトによってシリアライズされません。EJB コンテナは byte[] 型を直接保持し、シリアライズしません。
WebLogic Server が Oracle データベース内の Blob にマップされた byte[] 型の cmp-field をシリアライズするようにするには、WebLogic Server 8.1 SP02 で導入された serialize-byte-array-to-oracle-blob 互換性フラグを True に設定します。
次の XML コードは、weblogic-cmp-jar-xml ファイルの dbms-column 要素を使用して CLOB オブジェクトを指定する方法を示しています。
<field-map><dbms-default-value>Oracle</dbms-default-value>
<cmp-field>description</cmp-field>
<dbms-column>product_description</dbms-column>
<dbms_column-type>Clob</dbms-column-type></field-map>
Oracle 9i ドライバと 10g ドライバでは、CLOB カラムをデータベースに正常に挿入するための要件が異なっています。Oracle 9i ドライバでは、CLOB 値を挿入する前に、データベース行をロックする必要があります。したがって、Oracle 9i の場合、WebLogic Server は以下の手順で CLOB カラム値を含む行をテーブルに挿入しています。
Oracle 9i で CLOB 値を含む行を正常に挿入するにはこのような手順が必要ですが、Oracle 10g でこの手順を行うと、パフォーマンスに不要な影響を与えます。Oracle 10g ドライバでは CLOB の処理方法が改良されており、CLOB カラム値を挿入する前に行をロックする必要はありません。Oracle 10g の場合、WebLogic Server は単一の INSERT 文を使用して、CLOB カラム値を含む行をテーブルに挿入します。その結果、CMP EJB のパフォーマンスは向上します。
このような Oracle 10g に関する WebLogic Server の最適化を利用するために、追加のコンフィグレーションは必要ありません。データベースとして Oracle を指定すれば、WebLogic Server は Oracle のバージョンが Oracle 9i か Oracle 10g かを確認します。WebLogic Server がデータベースを Oracle 10g と識別した場合、CLOB 値を含む行は単一の INSERT 文でテーブルに挿入されます。WebLogic Server がデータベースを Oracle 9i と識別した場合、CLOB 値を含む行は前述の 3 つの手順でテーブルに挿入されます。
詳細については、「Handling CLOBs - Made easy with Oracle JDBC 10g」および Oracle 製品のドキュメントを参照してください。
フィールド グループは、Bean のコンテナ管理による永続性 (CMP) フィールドとコンテナ管理による関係 (CMR) フィールドのサブセットを表します。パフォーマンスを向上させるために、Bean 内の関連フィールドを、障害のあったグループにまとめて 1 つのユニットとしてメモリ内に入れることができます。
グループをクエリまたは関係に関連付けることができます。それによって、クエリを実行するか、または関係に従った結果として Bean がロードされたときに、グループ内の指定フィールドのみがロードされます。
指定したグループを持たないクエリと関係に対して、「default」という特殊なグループを使用します。デフォルトでは、default グループには、Bean のすべての CMP フィールドと、Bean テーブルに外部キーを追加するすべての CMR フィールドが格納されます。
フィールドは複数のグループに関連付けられている場合があります。この場合、フィールドに対して getXXX() メソッドを実行すると、そのフィールドを含む最初のグループで障害が発生します。
フィールド グループは、コード リスト 6-3 のように weblogic-cmp-jar.xml ファイルの field-group 要素で指定します。
<weblogic-rdbms-bean>
<ejb-name>XXXBean</ejb-name>
<field-group>
<group-name>medical-data</group-name>
<cmp-field>insurance</cmp-field>
<cmr-field>doctors</cmr-fields>
</field-group>
</weblogic-rdbms-bean>
同じコンテナ管理による永続性 (CMP) エンティティ Bean の複数のインスタンスは、多くの場合単一のトランザクションで変更されます。EJB コンテナが CMP エンティティ Bean のインスタンスごとに SQL を発行する場合、更新はパフォーマンスのボトルネックになります。
EJB バッチ処理機能は、1 まとまりの SQL 文でデータベース テーブル内の複数エントリを更新することにより、この問題を解決します。これにより、CMP Bean の複数のデータベース挿入、削除、または更新を一度のデータベース アクセスで実行することでパフォーマンスが大幅に向上します。
バッチ処理によるデータベース挿入、更新、または削除を許可するには、weblogic-cmp-jar.xml ファイルの enable-batch-operations 要素を True に設定します。
データベースの処理を順序付けすると、データベースの依存関係を考慮し、それに応じて挿入、更新、および削除を順序付けすることで制約エラーが起こらなくなります。
データベースの順序付けを有効化すると、EJB コンテナが次の 2 つの処理を行うようになります。
たとえば、販売員 A と関連する顧客 A を想定します。販売員 A が削除され、顧客 A が販売員 B に割り当てられる場合、コンテナは次のように処理を順序付けします。
これで、顧客 A は存在しない販売員を参照しなくなり、データベースの参照整合性エラーが発生しなくなります。
EJB コンテナが関連する Bean のデータベース処理を適切に順序付けするには、weblogic-cmp-jar.xml の weblogic-rdbms-relation で Bean 間の関係を定義する必要があります。そのように定義しないと、EJB コンテナが更新を実行しようとしたときに、データベースの制約エラーが発生する場合があります。
バッチ処理を使用する場合、トランザクションの開始からコミットまでの間にバッチ処理だけが挿入、更新または削除に適用されるように、トランザクションの境界を設定しなければなりません。
バッチ処理は、addBatch() と executeBatch() メソッドをサポートしているドライバのみに機能します。サポートされていないドライバを検出すると、EJB コンテナはバッチ処理がサポートされていないことを報告し、バッチ処理を無効化します。
sybase または sqlServer に設定されていると、バッチ処理で主キーの自動生成機能を使用できない。これらのタイプのいずれかで自動主キー生成を有効化していた場合、WebLogic Server は自動的にバッチ処理を無効化し、警告を発行します。 weblogic-ejb-jar.xml ファイルで指定した max-beans-in-cache の設定値を超えることはできない。 weblogic-cmp-jar.xml の dbms-column-type 要素で Blob か Clob を設定した場合、バッチ処理は自動的に無効になる。Blob または Clob カラムがデータベース テーブルに含まれている状況では、時間をあまり短縮できないからです。この場合、デフォルトでは WebLogic Server は Bean ごとに挿入を実行します。
読み込み専用エンティティ EJB をクエリ レベルでキャッシュできます。読み込み専用エンティティ Bean をクエリ レベルでキャッシュすると、パフォーマンスが向上します。これは、ファインダがキャッシュ内の EJB にアクセスできるようになり、データベースへのアクセスを回避できるからです。詳細については、「enable-query-caching」を参照してください。
このリリースの WebLogic Server では、コンテナ管理による永続性 (CMP) を使用するエンティティ Bean で EJB-QL、標準の SQL、またはデータベース固有の SQL を使用できます。ほとんどのクエリでは EJB-QL (WebLogic 拡張ありまたはなし) を使用し、SQL は必要な場合にのみ (たとえば、ベンダ固有の SQL を使用しないとアクセスできないベンダ固有機能を使用する場合に) 使用することをお勧めします。
SQL は、複数の関連オブジェクトをキャッシュするクエリでファインダおよび選択メソッドを実装するために使用したり、ストアド プロシージャと一緒に使用したりできます。
このリリースの WebLogic Server のクエリで EJB-QL を使用する場合、weblogic-cmp-jar.xml のマッピング情報を変更する必要はありません。9.0 より前のリリースの WebLogic Server での操作と同じように、各 CMP および CMR フィールドをデータベース カラムにマップするだけです。詳細については、「データベース操作に向けたエンティティ EJB のコンフィグレーション」および「コンテナ管理による関係 (CMR) の使用」を参照してください。SQL をクエリで使用するには、SQL の結果の形式を sql-shape 要素で定義する必要があります。SQL の形式は、主に返される SQL テーブルとカラムで構成されます。EJB コンテナは、SQL の形式と CMP および CMP フィールド マッピングを使用してクエリからオブジェクトを返します。詳細については、以下を参照してください。
コンテナ管理による関係 (CMR) は 2 つのエンティティ EJB 間で定義する関係であり、データベースのテーブル間の関係と似ています。同じ処理タスクに関わる 2 つの EJB 間で CMR を定義した場合、アプリケーションは以下の機能の恩恵を受けることができます。
以降の節では、WebLogic Server CMR の特徴と制限について説明します。CMR のコンフィグレーション手順については、「コンテナ管理による関係 (CMR) の定義」を参照してください。
同じ JAR にパッケージ化され、データが同じデータベースに格納される 2 つの WebLogic Server エンティティ Bean の間で関係を定義できます。同じ関係に属するエンティティは、同じデータソースにマップされていなければなりません。WebLogic Server は、データソースの異なるエンティティ Bean 間の関係をサポートしていません。コンテナ管理による関係に参加する各 Bean の抽象スキーマは、同じ ejb-jar.xml ファイルで定義されなければなりません。
| 注意 : | EJB 2.1 では、エンティティ Bean にローカル インタフェースがない場合、その Bean が参加できる唯一の CMR はそれ自体から別のエンティティ Bean への一方向の CMR であるとされています。 |
| 注意 : | ただし、WebLogic Server ではリモート インタフェースのみのエンティティ Bean に以下のことを許可しています。 |
| 注意 : | この機能は EJB 2.1 では規定されていないので、リモート インタフェースしか持たず、双方向の関係に参加するか、一方向の関係の対象となるエンティティ Bean は他のアプリケーション サーバには移行できない場合があります。 |
エンティティ Bean は、別のエンティティ Bean との間で 1 対 1、1 対多、または多対多の関係を持つことができます。
1 対 1、1 対多、多対多のどれであるかに関係なく、CMR は一方向か双方向のいずれかになります。CMR の方向は、関係の片側の Bean がもう片側の Bean からアクセスできるかどうかを決めます。
一方向の CMR は一方通行であり、「従属」Bean は関係のもう一方の Bean を意識しません。カスケード削除などの CMR 関連の機能は、従属 Bean にのみ適用できます。たとえば、EJB1 から EJB2 への一方向の CMR でカスケード削除がコンフィグレーションされている場合、EJB1 を削除すると EJB2 も削除されますが、EJB2 を削除しても EJB1 は削除されません。
| 注意 : | カスケード削除の機能には、関係のカーディナリティが影響します。関係が双方向だとしても、カスケード削除は関係の多サイドからはサポートされません。 |
双方向の関係は両側通行であり、関係の各 Bean は他方の Bean を意識しています。CMR 関連の機能は、両方向でサポートされます。たとえば、EJB1 と EJB2 の間の双方向 CMR でカスケード削除がコンフィグレーションされている場合、CMR のいずれかの Bean を削除するともう片方の Bean も削除されます。
関係に参加している Bean インスタンスが削除されると、コンテナは自動的にその関係を削除します。たとえば従業員と部署の間の関係があるとして、その従業員が削除されると、コンテナはその従業員と部署の間の関係も削除します。
CMR の定義では、その関係とカーディナリティおよび方向を ejb-jar.xml で指定します。weblogic-cmp-jar.xml では、関係のデータベース マッピング情報を定義し、リレーションシップ キャッシングを有効にします。手順については、以下を参照してください。
コンテナ管理による関係は、ejb-jar.xml の ejb-relation 要素で定義します。コード リスト 6-4 は、2 つのエンティティ EJB (TeacherEJB と StudentEJB) 間の関係の ejb-relation 要素を示しています。
ejb-relation 要素には、関係の各サイドの ejb-relationship-role があります。role 要素は、各 Bean の関係に対する見方を指定します。
<ejb-relation>
<ejb-relation-name>TeacherEJB-StudentEJB</ejb-relation-name>
<ejb-relationship-role>
<ejb-relationship-role-name>teacher-has-student
</ejb-relationship-role-name>
<multiplicity>One</multiplicity>
<relationship-role-source>
<ejb-name>TeacherEJB</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>teacher</cmr-field-name>
</cmr-field>
</ejb-relationship-role>
<ejb-relationship-role>
<ejb-relationship-role-name>student-has-teacher
</ejb-relationship-role-name>
<multiplicity>Many</multiplicity>
<relationship-role-source>
<ejb-name>StudentEJB</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>student</cmr-field-name>
<cmr-field-type>java.util.Collection</cmr-field-type>
<cmr-field>
</ejb-relationship-role>
関係の各サイドのカーディナリティは、ejb-relationship-role 要素の multiplicity 要素で示します。
コード リスト 6-5 では、関係 TeacherEJB-StudentEJB のカーディナリティは 1 対多です。このカーディナリティは、TeacherEJB 側で multiplicity を one に、StudentEJB 側では Many に設定することで指定します。
コード リスト 6-5 の CMR のカーディナリティは 1 対 1 です。関係の両方の role 要素で multiplicity が one に設定されています。
<ejb-relation>
<ejb-relation-name>MentorEJB-StudentEJB</ejb-relation-name>
<ejb-relationship-role>
<ejb-relationship-role-name>mentor-has-student
</ejb-relationship-role-name>
<multiplicity>One</multiplicity>
<relationship-role-source>
<ejb-name>MentorEJB</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>mentorID</cmr-field-name>
</cmr-field>
</ejb-relationship-role>
<ejb-relationship-role>
<ejb-relationship-role-name>student-has-mentor
</ejb-relationship-role-name>
<multiplicity>One</multiplicity>
<relationship-role-source>
<ejb-name>StudentEJB</ejb-name>
</relationship-role-source>
</ejb-relationship-role>
関係の片側の <multiplicity> が Many である場合、その <cmr-field> は集合であり、コード リスト 6-4 の関係の StudentEJB 側のように、<cmr-field-type> を java.util.Collection として指定する必要があります。cmr-field が単一値のオブジェクトである場合は、cmr-field-type を指定する必要はありません。
表 6-4 は、関係のカーディナリティに基づいて、関係の各 Bean の cmr-field の内容を示しています。
CMR の方向は、関係の各サイドの ejb-relationship-role 要素で cmr-field を含めるかどうかによってコンフィグレーションします。
双方向 CMR では、関係の両サイドの ejb-relationship-role 要素に cmr-field 要素があります (コード リスト 6-4 を参照)。
一方向の関係では、関係の role 要素の片方だけにしか cmr-field がありません。開始側 EJB の ejb-relationship-role には cmr-field がありますが、対象 Bean の role 要素にはありません。コード リスト 6-5 では、MentorEJB から StudentEJB への一方向の関係が指定されています。StudentEJB の ejb-relationship-role 要素には cmr-field 要素がありません。
ejb-jar.xml で定義される各 CMR は、weblogic-cmp-jar.xml の weblogic-rdbms-relation 要素でも定義する必要があります。 weblogic-rdbms-relation は関係を識別し、relationship-role-map 要素を格納します。この要素は、関係の片側または両側で、関係の参加者間のデータベースレベルの関係をマップします。
weblogic-rdbms-relation の relation-name は、ejb-jar.xml の CMR の ejb-relation-name と同じでなければなりません。
1 対 1 の関係と 1 対多の関係では、関係の片側だけで relationship-role-map が定義されます。
1 対 1 の関係の場合、マッピングは片方の Bean の外部キーからもう片方の Bean の主キーです。
コード リスト 6-6 は、MentorEJB と StudentEJB 間の 1 対 1 の関係の weblogic-rdbms-relation 要素です。<ejb-relation> は、コード リスト 6-5 に示してあります。
<weblogic-rdbms-relation><relationship-role-map>
<relation-name>MentorEJB-StudentEJB</relation-name>
<weblogic-relationship-role>
<relationship-role-name>
mentor-has-student
</relationship-role-name>
<column-map></relationship-role-map>
<foreign-key-column>student</foreign-key-column>
<key-column>StudentID/key-column>
</column-map>
</weblogic-relationship-role>
1 対多の関係の場合、マッピングは常に片方の Bean の外部キーから別の Bean の主キーです。1 対多の関係では、外部キーは常に関係の多サイドにある Bean と関連付けられます。
コード リスト 6-7 は、TeacherEJB と StudentEJB 間の 1 対多の関係の weblogic-rdbms-relation 要素です。<ejb-relation> は、コード リスト 6-4 に示してあります。
<weblogic-rdbms-relation><relationship-role-map>
<relation-name>TeacherEJB-StudentEJB</relation-name>
<weblogic-relationship-role>
<relationship-role-name>
teacher-has-student
</relationship-role-name>
<column-map></relationship-role-map>
<foreign-key-column>student</foreign-key-column>
<key-column>StudentID/key-column>
</column-map>
</weblogic-relationship-role>
多対多の関係では、関係の各サイドで weblogic-relationship-role 要素を指定します。そのマッピングには、結合テーブルが関わります。結合テーブルの各行には、関係に関与するエンティティの主キーに対応する 2 つの外部キーが格納されます。関係の方向は、関係のデータベース マッピングを指定する方法に影響しません。
コード リスト 6-8 は、2 人の従業員間の友人関係の weblogic-rdbms-relation 要素を示しています。
FRIENDS 結合テーブルには、first-friend-id と second-friend-id という 2 つのカラムがあります。各カラムには、別の従業員の友人である特定の従業員を示す外部キーが格納されます。従業員テーブルの主キー カラムは id です。例では、従業員 Bean が単一テーブルにマップされているものと想定しています。従業員 Bean が複数のテーブルにマップされている場合は、主キー カラムを格納するテーブルを relation-role-map で指定する必要があります。例については、「複数のテーブルにマップされる EJB の CMR の指定」を参照してください。
<weblogic-rdbms-relation>
<relation-name>friends</relation-name>
<table-name>FRIENDS</table-name>
<weblogic-relationship-role>
<relationship-role-name>first-friend
</relationship-role-name>
<relationship-role-map>
<column-map>
<foreign-key-column>first-friend-id</foreign-key-column>
<key-column>id</key-column>
</column-map
</relationship-role-map>
<weblogic-relationship-role>
<weblogic-relationship-role>
<relationship-role-name>second-friend</relationship-role-
name>
<relationship-role-map>
<column-map>
<foreign-key-column>second-friend-id</foreign-key-column>
<key-column>id</key-column>
</column-map>
</relationship-role-map>
</weblogic-relationship-role>
</weblogic-rdbms-relation>
関係に参加する CMP Bean は、複数の DBMS テーブルにマップできます。
関係のどちら側の Bean も複数のテーブルにマップされていない場合、foreign-key-table 要素と primary-key-table 要素は省略可能です (使用されるテーブルが暗黙的であるため)。
コード リスト 6-9 は、1 対 1 の関係の外部キー側の Bean (Fk_Bean) が 2 つのテーブル (Fk_BeanTable_1 と Fk_BeanTable_2) にマップされている CMR の relationship-role-map です。
関係の外部キー カラム (Fk_column_1 と Fk_column_2) は、Fk_BeanTable_2 に配置されています。主キー側の Bean (Pk_Bean) は、主キー カラム Pk_table_pkColumn_1 と Pk_table_pkColumn_2 を持つ 1 つのテーブルにマップされています。
外部キー カラムを持つテーブルは、<foreign-key-table> 要素で指定する必要があります。
<relationship-role-map
<foreign-key-table>Fk_BeanTable_2</foreign-key-table>
<column-map>
<foreign-key-column>Fk_column_1</foreign-key-column>
<key-column>Pk_table_pkColumn_1</key-column>
</column-map>
<column-map>
<foreign-key-column>Fk_column_2</foreign-key-column>
<key-column>Pk_table_pkColumn_2</key-column>
</column-map>
</relationship-role-map>
CMR フィールドは、実装クラスの属性としては格納されません。CMR フィールドは、記述した CMR フィールドのアクセサ メソッドを使用して Bean の中でアクセスできます。CMR フィールド アクセサ メソッドには、以下の条件があります。
リモート クライアントが CMR フィールドのアクセサ メソッドを使用できるようにするには、ゲッターおよびセッター メソッドのシグネチャをリモート インタフェースに配置します。ただし、Collection データ型の CMR フィールドはリモート インタフェースでエクスポーズできません。Collection データ型の CMR フィールドは、ローカル メソッドでのみアクセスできます。
カスケード削除が実行される場合、別の Bean インスタンスとの関係に参加している Bean インスタンスを削除すると、コンテナは従属するすべての Bean インスタンスも自動的に削除します。この機能では、データの整合性を効率的に維持できます。
たとえば、Employee Bean が Employee_Projects Bean との間で 1 対多の関係にある場合、Employee Bean のインスタンスを削除すると Employee_Projects Bean のインスタンスも削除されます。
指定できるカスケード削除は 1 対 1 関係と 1 対多関係についてであり、多対多関係については指定できません。
WebLogic Server は、2 通りのカスケード削除をサポートしています。
ejb-jar.xml で cascade-delete 要素を使用します。<ejb-relation>
<ejb-relation-name>Customer-Account</ejb-relation-name>
<ejb-relationship-role>
<ejb-relationship-role-name>Account-Has-Customer
</ejb-relationship-role-name>
<multiplicity>one</multiplicity>
<cascade-delete/>
</ejb-relationship-role>
</ejb-relation>| 注意 : | cascade-delete 要素は、関係のもう片方の ejb-relationship-role で multiplicity が one に設定されている場合にのみ ejb-relationship-role 要素で指定できます。 |
db-cascade-delete が有効になっている場合は、基底のデータベースをカスケード削除対応に設定する必要があります。WebLogic および Oracle でデータベースのカスケード削除を設定する手順と例については、「db-cascade-delete」を参照してください。
大規模なトランザクション環境では、カスケード削除を実行するトランザクションが、カスケード削除を実行しないトランザクションと同じ Bean にアクセスする必要がある場合に、排他的な同時方式を使用するトランザクションでデッドロックが発生する可能性があります。そのようなデッドロックを回避する方法については、「Exclusive 同時方式およびカスケード削除を使用するトランザクションのデッドロックの回避」を参照してください。
リレーションシップ キャッシング (「プリフェッチ」または「期待されるリレーションシップ キャッシング」とも呼ばれる) では、関係する複数 Bean をキャッシュにロードし、それらに結合クエリを発行してクエリの発行回数を削減することによって、エンティティ Bean のパフォーマンスが高められます。Bean の集合が同じ処理単位の中でアクセスされる場合、アプリケーションはそれらを同時にキャッシュにロードする必要があります。
アプリケーションに、次のような関係を持つエンティティ Bean が含まれているとします。
accountBean および addressBean の EJB コード (1 対 1 の関係を持つ) を検討します。
Account acct = acctHome.findByPrimaryKey("103243");
Address addr = acct.getAddress();
リレーションシップ キャッシングが行われなければ、コードの 1 行目で accountBean をロードする SQL クエリが発行され、2 行目で addressBean をロードする別の SQL クエリが発行されます。これにより、データベースには 2 つのクエリが生じます。
リレーションシップ キャッシングが行われると、accountBean と addressBean の双方をロードする 1 つのクエリがコードの 1 行目で発行されるため、パフォーマンスは向上するはずです。したがって、ある特定のファインダ メソッドの実行後に関連の Bean へのアクセスがあることが分かっている場合は、リレーションシップ キャッシング機能によってそれをファインダ メソッドに知らせることをお勧めします。
| 注意 : |
| 注意 : | ファインダ メソッドまたは選択メソッドでリレーションシップ キャッシングを有効にする場合、クエリの結果は、たとえ distinct キーワードを指定していなくても常に異なる集合になります。これは、EJB コンテナが基底の JDBC 結果セットで重複を区別できないようにする技術的な限界によるものです。 |
リレーションシップ キャッシングが有効な場合は、関係に変更を加えるとそれが自動的にキャッシュでも反映されます。たとえば、1 対多の関係の「多」サイドでインスタンスが追加されると、その変更はキャッシュ内の関係でも反映されます。関係の「1」サイドにある Bean に対してそれ以降クエリを行うと、新しいインスタンスがそのクエリから利用可能なように関係がキャッシュで更新されます。
リレーションシップ キャッシングを有効化するには、次の手順に従います。
weblogic-cmp-jar.xml の weblogic-query 要素で caching-name 要素を指定します。
weblogic-query 要素で caching-name 要素が指定されている場合、ファインダ クエリが実行されると、WebLogic Server は caching-name 要素が指定する relationship-caching 要素の指定に従って関連する Bean のデータをロードします。
finders-load-bean 要素 (weblogic-ejb-jar.xml) が、False に設定されていないようにします。False の場合は、リレーションシップ キャッシングが有効になりません。finder-load-bean のデフォルト値は True です。weblogic-cmp-jar.xml ファイルで database-type 要素を指定します。リレーションシップ キャッシングはクエリに外部結合を使用し、外部結合の構文はデータベースのタイプによって異なります。
リレーションシップ キャッシングは結合クエリを使用するので、relationship-caching 要素の caching-element 要素の数は結果セットの重複を増加させる場合があります。caching-element ごとに 1 つずつ 1 対多の関係を指定すると、結果セットで重複を回避できます。
次の例のように、weblogic-cmp-jar.xml で relationship-caching 要素を指定します。
<relationship-caching>
<caching-name>cacheMoreBeans</caching-name>
<caching-element>
<cmr-field>accounts</cmr-field>
<group-name>acct_group</group-name>
<caching-element>
<cmr-field>address</cmr-field>
<group-name>addr_group</group-name>
</caching-element>
</caching-element>
<caching-element>
<cmr-field>phone</cmr-field>
<group-name>phone_group</group-name>
</caching-element>
</relationship-caching>
accounts フィールドと phone フィールドは customerBean の cmr フィールド、address フィールドは accountBean の cmr フィールド、addr_group と phone_group は addressBean と phoneBean のグループです。
caching-element 要素をネストすることにより、関係する Bean を複数レベルでロードできるようになります。上記のサンプルでは、addressBean が accountBean 内でネストになっているので、第 2 レベルの関連 Bean にあたります。現在、指定できる caching-element の数に制限はありません。しかし、caching-element のレベルをあまり多く設定しすぎると、そのトランザクションのパフォーマンスに影響すると考えられます。
エンティティ Bean の同時方式は、EJB コンテナが Bean への同時アクセスをどのように管理するのかを指定します。つまり、WebLogic Server が、エンティティのキャッシュされたコピーとデータベースをいつどのように同期させるのかを指定します。
WebLogic Server でサポートされている同時方式については、以降の節で説明します。
Exclusive 同時方式の場合、コンテナは Bean がトランザクションに関連付けられている場合に、キャッシュされた EJB インスタンスを排他的にロックします。EJB インスタンスに対する要求は、トランザクションが完了するまでブロックされます。排他的なロックはサーバ インスタンスでローカルに行われるので、この方式は単一サーバ アーキテクチャに最も適しています。クラスタで使用した場合、Exclusive 同時方式はサーバ インスタンス内で Bean インスタンスに対する要求をすべてシリアライズしますが、同じ Bean に同時にアクセスするクラスタ内のサーバ間の同時方式はデータベースによって管理されます。
複数のクライアントが Exclusive 同時方式を使用して、エンティティ EJB に連続してアクセスできます。この排他的オプションを使用する場合、2 つのクライアントでエンティティ EJB の同じインスタンス (主キーが同じインスタンス) へのアクセスが同時に試行されると、2 番目のクライアントは EJB が利用可能になるまでブロックされます。
Database 同時方式を使用する場合、各トランザクションの EJB の同時方式の制御は基底のデータベースに委ねられます。WebLogic Server は、独立したエンティティ Bean インスタンスを各トランザクションに割り当て、同時方式の制御をデータベースで処理できるにようにします。これは現在のデフォルト オプションです。
Database メカニズムでは、EJB コンテナが継続してエンティティ Bean のインスタンスをキャッシュします。しかし、コンテナはトランザクション間の Bean インスタンスの中間状態をキャッシュしません。その代わりとして、WebLogic Server は、トランザクションの開始時に各インスタンスに対し SQL SELECT を発行して最新の EJB データを取得します。SQL UPDATE は、変更がある場合に発行されます。
続いて、データのコミット要求がデータベースに送られます。このためデータベースは、EJB のデータの同時方式の制御とデッドロックの検出をすべて処理します。
Database 同時方式の場合と同じように、Optimistic 同時方式では各トランザクションにそれ専用の Bean インスタンスが割り当てられます。Optimistic 同時方式は、トランザクションの実行中、EJB コンテナまたはデータベースでどのようなロックも行いません。
| 注意 : | 読み込みロックを行うデータベース (Oracle 以外のデータベース) では、オプティミスティックな Bean は独立したローカルのトランザクションでデータを読み込みます。そのローカル トランザクションは、読み込みが完了するとすぐコミットされます。この方式では読み込みロックが回避され、複数のトランザクションが同じデータを同時に更新しない場合にスケーラビリティを向上させることができます。 |
オプティミスティックなデータが古くなるのを防ぐために、コンテナはトランザクションごとに新しい Bean インスタンスをアクティブ化して、複数の要求を並行処理します。cache-between-transactions の値が True の場合、WebLogic Server は read-timeout-seconds の値に基づいてエンティティ Bean の ejbLoad() を呼び出します。
基底データが EJB コンテナの外部で更新された場合、オプティミスティックな Bean を明示的に無効にできます (「バックドア更新」とも呼ぶ)。詳細については、「エンティティ EJB の明示的な無効化」を参照してください。
デフォルトによって、concurrency-strategy が Optimistic である Bean がクラスタにデプロイされており、クラスタのメンバーがその Bean を更新した場合、EJB コンテナは、クラスタ内のすべてのサーバに存在するその Bean のすべてのコピーを無効にしようとします。この無効化の処理によって、オプティミスティックな同時方式の失敗を防ぐことができます。しかし、この処理はリソースを大量に消費するため、パフォーマンスが低下する可能性があります。必要な場合、weblogic-cmp-jar.xml の cluster-invalidation-disabled を True に設定して、EJB コンテナがクラスタ内の Bean のコピーを無効化しないようにできます。
トランザクションで読み込みまたは更新されたデータが別のトランザクションで変更されていないことを検証するために、トランザクションのコミットの前にオプティミスティックな Bean のトランザクション データを検証するように EJB コンテナをコンフィグレーションできます。データの変更が検出された場合、EJB コンテナはトランザクションをロールバックします。
| 注意 : | EJB コンテナは、Optimistic 同時方式では Bean の Blob または Clob フィールドを検証しません。これを回避するには、バージョン チェックまたはタイムスタンプ チェックを行います。 |
Optimistic 同時方式の Bean の有効性チェックをコンフィグレーションするには、weblogic-cmp-jar.xml ファイルのその Bean の table-map 要素で verify-columns 要素と verify-rows 要素を使用します。
verify-rows 要素は、オプティミスティックな同時実行性の使用時に EJB コンテナがチェックすべきである、テーブル内の行を指定します。verify-columns 要素は、Optimistic 同時方式を使用する場合に、テーブルのカラムの有効性がどのようにチェックされるのかを指定します。
Read - トランザクションの間に参照したテーブルのすべての行をチェックする。これには、単に読み込まれるだけの行と、読み込まれた後でトランザクションによって更新または削除される行の両方が含まれます。すべての行をチェックすると、通常は EJB コンテナで実行しなければならないオプティミスティック チェックの量が増えるのでオーバーヘッドが大きくなります。Read オプションを使用する場合、コミットされたトランザクションは、トランザクションがコミットされるまで別のトランザクションで修正されることのない行を読み込みます。その結果として、SERIALIZABLE の一貫性の ANSI 定義と非常に近い高度な一貫性が実現します。Modified - 現在のトランザクションで更新または削除した行だけをチェックする。この設定にすると、2 つのトランザクションが同時に同じ行を更新することがなく、更新が損失することはありませんが、異なるトランザクションで読み込みと更新を交互に行うことは可能です。その結果、得られる一貫性のレベルは、ANSI の READ_COMMITTED レベルと REPEATABLE_READ レベルの間になります。Read - トランザクションの間に参照したテーブルのすべてのカラムをチェックする。これには、単に読み込まれるだけの行と、読み込まれた後でトランザクションによって更新または削除される行の両方が含まれます。Modified - 現在のトランザクションで更新または削除したカラムだけをチェックする。| 注意 : | verify-rows が Read に設定されていると、verify-columns 要素では Modified を指定できません。この組み合わせでは、修正された行だけがチェックされることになるためです。 |
Version - テーブルにバージョン カラムが含まれ、このカラムがオプティミスティックな同時実行性を実施するのに使われていることをチェックする。
Version カラムは、初期値 0 または正の整数で作成し、行が変更される度に 1 ずつ加算されるようにしてください。詳細については、「version-column-initial-value」を参照してください。
また、データベース トリガを使用してデータベース内のバージョン カラムを更新し、trigger-updates-optimistic-column を True に設定した場合、データベース トリガは Bean の作成時にデータベース内のバージョン カラムを初期化する必要があります。
Timestamp - テーブルにタイムスタンプ カラムが含まれ、このカラムがオプティミスティックな同時実行性を実施するのに使われていることをチェックする。タイムスタンプ ベースの同時実行性では、このデータベース カラムの粒度を 1 秒にする必要があります。
デフォルトによって、EJB コンテナはバージョンおよびタイムスタンプ カラムを管理し、これらのカラムを常に最新の状態に保ちます。代わりに、データベース トリガによってバージョンおよびタイムスタンプ カラムが管理されるようにする場合、trigger-updates-optimistic-column の値を True に設定します。
| 注意 : | バージョンまたはタイムスタンプ カラムは、トランザクションが通常の CMP または CMR フィールドを修正しなかった場合は更新されません。トランザクションの過程で変更された唯一のデータがバージョンまたはタイムスタンプ カラムの値である場合 (トランザクションの開始の結果として)、オプティミスティック チェックで使用されるカラムはトランザクションの最後に更新されません。 |
verify-columns が Version または Timestamp に設定されている場合、以下のことを行います。weblogic-cmp-jar.xml ファイルの table-map 要素の optimistic-column を使用してバージョンまたはタイムスタンプ カラムを指定します。このカラムを cmp-field にマップするかどうかは任意です。
optimistic-column 要素は、オプティミスティックな同時実行性を実装するためのバージョン値またはタイムスタンプ値を格納するデータベース カラムを示します。この要素では、大文字と小文字がそのまま維持されます。ただし、すべてのデータベースで大文字と小文字が区別されるわけではありません。この要素の値は、verify-columns が Version または Timestamp に設定されていない場合は無視されます。
weblogic-cmp-jar.xml ファイルの version-column-initial-value 要素を使用してバージョン カラムの初期値を指定します。
EJB が複数のテーブルにマップされる場合、トランザクション中に更新したテーブルに対してのみオプティミスティックなチェックが実行されます。
Oracle データベースでは、CMP のキー以外のフィールドの型が java.util.Date で実装型が Oracle DATE であるエンティティ EJB で verify-columns を Modified に設定すると、キーではない DATE フィールドに対して単純な更新が行われたときに、たとえ 1 人のユーザしかレコードを更新していなくても WebLogic Server が Optimistic 同時方式の違反例外を送出します。
この問題は、Oracle DATE カラムと java.util.Date 型の日付値の精度が異なるために発生します。java.util.Date 型はミリ秒単位ですが、Oracle DATE カラムは違います。このエラーは、以下の 2 通りの方法で防止できます。
Bean が読み込み専用であることを示すために使用します。コンテナは、複数の要求が並行して処理されるように各トランザクションで新しい Bean インスタンスをアクティブ化します。WebLogic Server は、read-timeout-seconds パラメータに基づいて読み込み専用 Bean の ejbLoad() を呼び出します。
このリリースの WebLogic Server では、読み込み専用 Bean のコードを効率化するために、ReadOnly 同時方式を使用する EJB で作成と削除は許可されていません。
読み込み専用 Bean が作成および削除操作を使用できるようにするには、weblogic-cmp-jar.xml の allow-readonly-create-and-remove 要素を True に設定します。
同時方式は、パフォーマンスとデータの鮮度の間でトレードオフを生じさせます。アプリケーションでどの要素がより重要であるかに基づいて、同時方式を選択してください。トレードオフについては、表 6-5 を参照してください。
weblogic-cmp-jar.xml で use-select-for-update を設定する。そうすると、読み込みが行われるときにデータベースが排他的ロックを解除し、読み込みロックが排他的なロックにアップグレードされたときに発生するデッドロックが回避される。 |
|
||||
Bean で同時方式のメカニズムを指定するには、weblogic-ejb-jar.xml で entity-cache 要素の concurrency-strategy 要素を設定します。concurrency-strategy は Bean レベルで定義されるので、同じアプリケーションでも異なる Bean は必要に応じて別々の同時方式を使用できます。
concurrency-strategy を指定しない場合、WebLogic Server はデフォルトで Database 同時方式を使用します。
スループットが高い状況では、カスケード削除を実行するトランザクションが、カスケード削除を実行しないトランザクションと同じエンティティ Bean にアクセスする必要がある場合に、排他的な同時方式を使用するトランザクションでデッドロックが発生する可能性があります。
このようなデッドロックは、weblogic-cmp-jar.xml デプロイメント記述子ファイルの lock-order 要素を使用して回避できます。lock-order は、関連する Bean のカスケード削除の過程で Bean がロックされる順序を定義します。その値は、整数値です。lock-order の値が最低の Bean は最初に処理され、次に低い lock-order 値の Bean がその次に処理されます。
指定するロックの順序は、アプリケーションの他のトランザクションで使用されるロックの順序と同じでなければなりません。
lock-order を指定すると、他のトランザクションと同じ順序でカスケード削除が Bean インスタンスをロックします。通常のロック順序が BeanA、BeanB の順である場合に、この lock-order を指定すると、カスケード削除でもその順序が使用されます。
あまり更新されない永続データの場合は、読み込み専用エンティティ Bean と読み書き対応エンティティ Bean を同じデータにマップすることで WebLogic Server で「read-mostly パターン」を実装できます。読み込み専用エンティティ Bean は読み込みに、読み書き対応エンティティ Bean は書き込みに使用します。
読み込み専用エンティティ EJB は、weblogic-ejb-jar.xml でその Bean の entity-cache (または entity-cache-ref) 要素の read-timeout-seconds 要素に指定された間隔で Bean のデータをロードします。読み込み専用 Bean が常に最新のデータを返すようにするには、読み書き対応 Bean がエンティティ Bean のデータを変更するときに読み込み専用 Bean を無効にする必要があります。WebLogic Server が読み込み専用 Bean を自動的に無効化するようにコンフィグレーションするか、Bean コードで明示的に無効化することができます。詳細については、それぞれ「読み込み専用エンティティ EJB の暗黙的な無効化」および「エンティティ EJB の明示的な無効化」を参照してください。
WebLogic Server クラスタで read-mostly パターンを利用すると、読み込み専用 EJB のクライアントではキャッシュからの読み込みでパフォーマンスが向上し、読み書き対応 EJB のクライアントでは真のトランザクション動作が実現します (read-write EJB のキャッシュされた状態が常にデータベースの永続データと一致する)。
以下のプラクティスを行うと、read-mostly パターンでデータ一貫性の問題が発生する可能性が低下します。
weblogic-ejb-jar.xml での読み込み専用 Bean の read-timeout-seconds 要素のコンフィグレーション
EJB 2.x を実行する場合は、Optimistic 同時方式を使用する単一 Bean で read-mostly パターンを模倣することができます。オプティミスティックな Bean は、読み込みを実行するときに読み込み専用 Bean のように機能します (キャッシュから読み込み、古いデータを返すことがある)。ただし、オプティミスティックな Bean が書き込みを実行するときは、コンテナによって更新対象のデータが変更されていないようにします (Database 同時方式を使用する Bean と同じレベルの書き込みの一貫性が提供される)。「同時方式の選択」を参照してください。
weblogic-ejb-jar.xml の entity-descriptor 要素の invalidation-target 要素は、CMP エンティティ Bean が修正されたときに無効化すべき読み込み専用エンティティ EJB を特定します。
invalidation-target は、EJB 2.x CMP エンティティ Bean でのみ指定できます。対象の ejb-name は、読み込み専用エンティティ EJB でなければなりません。
このリリースの WebLogic Server では、cache-between-transactions が有効化されているオプティミスティックなエンティティ Bean を無効化できます。そのためには、CachingHome または CachingLocalHome インタフェースの次の invalidate() メソッドを呼び出します。
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 にキャストしてからメソッドを呼び出す方法を示したものです。
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() メソッドを呼び出すと、エンティティ Bean はローカル サーバ インスタンスで無効化されます。サーバ インスタンスがクラスタに属している場合は、Bean のキャッシュされたコピーを無効化するように他のクラスタ化されたサーバにメッセージがマルチキャストされます。無効化された読み込み専用エンティティ Bean に対して次に getXXX() が呼び出されたときには、コンテナは Bean の永続データの最新バージョンをデータベースからエンティティ キャッシュにロードします (「ejbLoad() と ejbStore() の動作について」を参照)。
WebLogic Server は、更新トランザクションの完了後に invalidate() を呼び出します。トランザクションの更新中に無効化処理が行われた場合、トランザクションの isolation-level でコミットされていないデータの読み出しが許可されていないと、更新前のデータが読み出される可能性があります。
以下の節では、CMP エンティティ Bean の WebLogic Server 固有のデプロイメントを簡単に参照できます。各節では、特定のタイプの機能または動作に関連する要素が取り上げられています。各節の表では、制御する動作、その要素が含まれる weblogic-cmp-jar.xml の親要素、および weblogic-cmp-jar.xml で明示的に指定しない場合に予想される動作に基づいて関連要素が定義されています。
|
|||
|
|||
  
|
