|
|
|
|
|
|
| | | |
WebLogic Server のコンテナ管理による永続性サービス
以下の節では、WebLogic Server EJB コンテナで新しく導入されたコンテナ管理による永続性サービス（CMP）について説明します。
コンテナ管理による永続性サービスの概要
WebLogic Server のコンテナは、EJB とサーバ間の統一的なインタフェースを提供する役割を持っています。コンテナは、EJB の新しいインスタンスを作成し、これらの Bean リソースを管理し、トランザクション、セキュリティ、同時実行性、ネーミングなどの永続性サービスを実行時に提供します。ほとんどの場合、WebLogic Server 6.1 より前の EJB はコンテナで動作します。ただし、Bean のコードの移行が必要な場合について『WebLogic Server 6.1 リリース ノート』の『WebLogic Server 6.0 アプリケーションの WebLogic Server 6.1 への移行』を、変換ツールの使い方についてはDDConverterを参照してください。
WebLogic Server のコンテナ管理による永続性（CMP）モデルでは、EJB のインスタンス フィールドをデータベースのデータと同期することで、CMP エンティティ Bean の永続性を実行時に自動処理します。
EJB の永続性サービス
WebLogic Server は、エンティティ Bean に永続性サービスを提供します。エンティティ EJB が任意のトランザクション対応またはトランザクション非対応の永続ストレージにその状態を保存する（「Bean 管理による永続性」）ことも、コンテナが EJB の非 transient インスタンス変数を自動的に保存する（「コンテナ管理による永続性」）こともできます。WebLogic Server では、このどちらも選択可能であり、両者を併用することもできます。
EJB がコンテナ管理の永続性を使用する場合、 EJB が使用する永続性サービスのタイプを weblogic-ejb-jar.xml デプロイメント ファイルに指定します。自動永続性サービスのハイレベル定義は、persistence-type および persistence-use 要素に格納されます。persistence-type には、EJB が使用できる 1 つまたは複数の自動サービスが定義されます。persistence-use には、EJB がデプロイ時に使用するサービスが定義されます。
自動永続性サービスは、さらに別のデプロイメント ファイルを使用してそのデプロイメント記述子を指定し、エンティティ EJB ファインダ メソッドを定義します。たとえば、WebLogic Server RDBMS ベースの永続性サービスは、特定の Bean からデプロイメント記述子とファインダ定義を取得するときに、その Bean の weblogic-cmp-rdbms-jar.xml ファイルを使用します。詳細については、WebLogic Server RDBMS 永続性の使い方で説明します。
サードパーティの永続性サービスでは、他のファイル フォーマットを使用してデプロイメント記述子をコンフィグレーションします。しかし、ファイルのタイプに関係なく、コンフィグレーション ファイルは weblogic-ejb-jar.xml の persistence-type および persistence-use 要素で参照しなければなりません。
注意: コンテナ管理による永続性 Bean では、接続プールの最大接続数を 1 より大きい値にコンフィグレーションします。WebLogic Server のコンテナ管理による永続性サービスでは、同時に 2 つの接続を取得しなければならない場合があるからです。
WebLogic Server RDBMS ベースの永続性サービスを EJB に対して使用するには、専用の XML デプロイメント ファイルを作成して、コンテナ管理の永続性を使用する各 EJB に対して永続性要素を定義します。WebLogic Server のユーティリティ、DDConverter を使用してこのファイルを作成した場合、ファイルの名前は weblogic-cmp-rdbms-jar.xml となります。このファイルをまったく新しく作成する場合は、異なる名前でファイルを保存できます。ただし、weblogic-ejb-jar.xml の persistence-type および persistence-use 要素が適切なファイルを参照していることを確認する必要があります。
weblogic-cmp-rdbms-jar.xml ファイルは、WebLogic Server RDBMS ベースの永続性サービスを使用して EJB の永続性デプロイメント記述子を定義します。
各 weblogic-cmp-rdbms-jar.xml ファイルでは、以下の永続性オプションを定義します。
EJB 1.1 CMP の RDBMS 永続性用の記述
クライアントはファインダ メソッドを使用して、クエリを実行し、クエリ条件を満たすエンティティ Bean の参照を受け取ることができます。この節では、RDBMS 永続性を使用する WebLogic 固有の 1.1 EJB 用のファインダを作成する方法について説明します。コンテナ管理による永続性を利用する 2.0 EJB のファインダ クエリを定義するには、ポータブルなクエリ言語である EJB QL を使用します。EJB QL の詳細については、EJB 2.0 用 EJB QL の使い方を参照してください。
WebLogic Server では、ファインダを簡単に作成できます。EJB プロバイダは、EJBHome インタフェースにファインダのメソッド シグネチャを記述し、ejb-jar.xml デプロイメント ファイルにそのファインダのクエリ式を定義します。
ejbc は、ejb-jar.xml のクエリを使用して、デプロイメント時にファインダ メソッドの実装を作成します。
RDBMS 永続性用のファインダの主要コンポーネントは以下のとおりです。
以降の節では、WebLogic Server デプロイメント ファイルの XML 要素を使用して EJB ファインダを記述する方法について説明します。
ファインダ シグネチャ
EJB プロバイダは、findMethodName() というフォームを使用して、ファインダ メソッドのシグネチャを指定します。weblogic-cmp-rdbms-jar.xml に定義されるファインダ メソッドは、EJB オブジェクトの Java コレクションまたは単一オブジェクトを返す必要があります。
注意: EJB プロバイダは、関連付けられている EJB クラスの単一オブジェクトを返す findByPrimaryKey(primkey) メソッドも定義できます。
finder-list スタンザ
finder-list スタンザは、EJBHome 内の 1 つまたは複数のファインダ メソッド シグネチャを EJB オブジェクトを検索するためのクエリに関連付けます。次に、WebLogic Server RDBMS ベースの永続性を使用した単純な finder-list スタンザの例を示します。
<finder-list>
<finder>
<method-name>findBigAccounts</method-name>
<method-params>
<method-param>double</method-param>
</method-params>
<finder-query><![CDATA[(> balance $0)]]></finder-query>
</finder>
</finder-list>
注意: method-param 要素内に非プリミティブなタイプを使用する場合には、完全修飾名を指定する必要があります。たとえば、Timestamp ではなく java.sql.Timestamp を使用します。完全修飾名を使用しないと、デプロイメント ユニットのコンパイル時に ejbc でエラー メッセージが生成されます。
finder-query 要素
finder-query 要素は、RDBMS から EJB オブジェクトをクエリするための WebLogic クエリ言語（WLQL）式を定義します。WLQL は、ファインダ パラメータ、EJB 属性、および Java 言語の式に対して標準の演算子セットを使用します。WLQL の詳細については、EJB 1.1 CMP 用の WebLogic クエリ言語（WLQL）の使用を参照してください。
注意: finder-query 値のテキストは、常に、XML CDATA 属性を使用して定義してください。CDATA を使用すると、WLQL 文字列中に特殊文字が入っていても、ファインダをコンパイルしたときにエラーが発生しないようになります。
CMP ファインダでは、1 回のデータベース クエリですべての Bean をロードできます。そのため、100 の Bean もデータベースに一度アクセスするだけでロードできます。Bean 管理による永続性（BMP）ファインダは、データベースに一度アクセスして、ファインダで選択した Bean の主キー値を取得する必要があります。各 Bean にアクセスする場合、通常は Bean がキャッシュされていないとことを想定して、もう一度データベースにアクセスする必要があります。したがって、100 の Bean にアクセスするために、BMP はデータベースに 101 回アクセスします。
EJB 1.1 CMP 用の WebLogic クエリ言語（WLQL）の使用
EJB 1.1 CMP 用の WebLogic クエリ言語（WLQL）を使用すると、コンテナ管理による永続性を利用する 1.1 エンティティ EJB をクエリできます。weblogic-cmp-rdbms-jar.xml ファイルでは、各 finder-query スタンザには EJB を返すためのクエリを定義する WLQL 文字列が指定されていなければなりません。EJB 向けの WLQL とそれに対応するデプロイメント ファイル（EJB 1.1 仕様に基づいたもの）を使用します。
注意: 2.0 EJB のクエリについては、EJB 2.0 用 EJB QL の使い方を参照してください。weblogic-ql クエリを使用すると、elb-ql クエリが完全にオーバーライドされます。
構文
WLQL 文字列では、比較演算子用に次のプレフィックス表記法を使用します。
(operator operand1 operand2)
追加の WLQL 演算子は、単一のオペランド、テキスト文字列、またはキーワードを受け付けます。
演算子
次の表に、有効な WLQL 演算子を示します。
オペランド
有効な WLQL オペランドは以下のとおりです。
注意: RDBMS カラム名は WLQL のオペランドとして使用できません。代わりに、weblogic-cmp-rdbms-jar.xml の attribute-map に定義されているとおり、RDBMS カラムにマップされる EJB 属性（フィールド）を使用します。
WLQL 式の例
次のサンプル コードは、基本的な WLQL 式を使用する weblogic-cmp-rdbms-jar.xml ファイルからの引用です。
public Enumeration findBigAccounts(double balanceGreaterThan)
throws FinderException, RemoteException;
注意: finder-query 値のテキストは、常に、XML CDATA 属性を使用して定義してください。CDATA を使用すると、WLQL 文字列中に特殊文字が入っていても、ファインダをコンパイルしたときにエラーが発生しないようになります。
<finder-query><![CDATA[(& (> balance $0) (! (= accountType 'checking')))]]></finder-query>
public Enumeration findAllAccounts()
throws FinderException, RemoteException
<finder> スタンザのサンプルでは、空の WLQL 文字列が使用されています。
<finder>
<method-name>findAllAccounts</method-name>
<finder-query></finder-query>
</finder>
<finder-query><![CDATA[(like lastName M%)]]></finder-query>
<finder-query><![CDATA[(isNull firstName)]]></finder-query>
<finder-query><![CDATA[WHERE >5000 (orderBy 'id' (> balance 5000))]]></finder-query>
<finder-query><![CDATA[(orderBy 'id desc' (> ))]]></finder-query>
EJB クエリ言語（QL）は、コンテナ管理による永続性を利用する 2.0 エンティティ EJB のファインダ メソッドを定義する移植可能なクエリ言語です。SQL に似ており、クエリ内の 1 つまたは複数のエンティティ EJB オブジェクトまたはフィールドを選択する場合に使用します。CMP フィールドはデプロイメント記述子で宣言するので、findByPrimaryKey() 以外のすべてのファインダ メソッドのクエリをデプロイメント記述子で作成できます。findByPrimaryKey は、コンテナによって自動的に処理されます。EJB QL クエリの検索スペースは、ejb-jar.xml（コンテナ管理によるフィールドとその関連データベース カラムの Bean のコレクション）で定義された EJB のスキーマからなります。
EJB 2.0 Bean についての EJB QL の要件
デプロイメント記述子では、EJB QL クエリ文字列を使用して、EJB 2.0 のエンティティ Bean の各ファインダ クエリを定義する必要があります。WebLogic Query Language（WLQL）を EJB 2.0 エンティティ Bean で使用することはできません。WLQL は、EJB 1.1 CMP で使用することを想定しています。
WLQL から EJB QL への移行
以前のバージョンの WebLogic Server を使用したことがあれば、コンテナ管理によるエンティティ EJB ではファインダ メソッド用に WLQL を使用できます。この節では、WLQL の一般的な処理についてのクイック リファレンスを提供します。WLQL の構文と EJB QL の構文の対応については、次の表を参考にしてください。
EJB QL の EJB 2.0 WebLogic QL 拡張機能の使い方
WebLogic Server には、標準の EJB QL の拡張であり、SQL に似た WebLogic QL という言語が用意されています。この言語はファインダ式と連携し、RDBMS の EJB オブジェクトのクエリ用に使用されます。query は、weblogic-ql 要素を使用して、weblogic-cmp-rdbms-jar.xml デプロイメント記述子に定義します。
ejb-jar ファイルには、weblogic-cmp-rdbms-jar.xml ファイルの weblogic-ql 要素に対応するクエリ要素が必要です。ただし、weblogic-cmp-rdbms-jar.xml のクエリ要素は、ejb-jar.xml のクエリ要素をオーバーライドします。
SELECT DISTINCT
EJB WebLogic QL 拡張機能の SELECT DISTINCT では、重複したクエリをフィルタ処理するようデータベースに指示します。SELECT DISTINCT を EJB QL クエリで指定すると、重複した結果をソートするために EJB コンテナのリソースが使用されません。
EJB 2.0 CMP Bean の weblogic-ql 要素の XML スタンザで値を TRUE に設定して sql-select-distinct 要素を指定すると、作成されるデータベース クエリの SQL STATEMENT には DISTINCT 句が含まれます。
sql-select-distinct 要素は weblogic-cmp-rdbms-jar.xml ファイルで指定します。ただし、Oracle データベースでアイソレーション レベルを READ_C0MMITED_FOR_UPDATE に指定してある場合、sql-select-distinct を指定することはできません。Oracle 上では、クエリに sql-select-distinct と READ_C0MMITED_FOR_UPDATE の両方を指定することができないからです。このアイソレーション レベルをセッション Bean などで使用する可能性がある場合、sql-select-distinct 要素を使用しないでください。
ORDERBY
WebLogic クエリ言語（WL QL）の拡張機能である ORDERBY は、ファインダ メソッドと連携して、選択における CMP フィールドの選択順序を指定するキーワードです。
コード リスト 5-1 id による順序付けを指定する WebLogic QL ORDERBY 拡張機能
ORDERBY
SELECT OBJECT(A) from A for Account.Bean
ORDERBY A.id
注意: ORDERBY は、すべてのソート処理を DBMS に委ねます。このため、取得される結果の順序は、実行中の Bean の基盤となる特定の DBMS によって異なります。
Oracle の SELECT HINT の使用
WebLogic Server は、INDEX の使い方に関するヒントを Oracle Query オプティマイザに渡すことを可能にする EJB QL 拡張機能をサポートしています。この拡張機能を使用すると、データベース エンジンにヒントを提供できます。たとえば、検索先のデータベースが ORACLE_SELECT_HINT によって恩恵を受けることがわかっている場合は、ANY 文字列値を取り、その文字列値をデータベースに対するヒントとして SQL SELECT 文の後に挿入する ORACLE_SELECT_HINT 句を定義します。
このオプションを使用するには、この機能を使用するクエリを weblogic-ql 要素で宣言します。この要素は、weblogic-cmp-rdbms-jar.xml ファイルに入っています。weblogic-ql 要素では、EJB-QL に対する WebLogic 固有の拡張機能を含むクエリを指定します。
WebLogic QL のキーワードおよび使い方は次のとおりです。
SELECT OBJECT(a) FROM BeanA AS a WHERE a.field > 2 ORDERBY a.field SELECT_HINT '/*+ INDEX_ASC(myindex) */'
この文は、Oracle のオプティマイザ ヒントを使用して次の SQL を生成します。
SELECT /*+ INDEX_ASC(myindex) */ column1 FROM .... (etc)
WebLogic QL ORACLE_SELECT_HINT 句では、単一引用符で囲まれた部分（' '）が SQL SELECT の後に挿入されます。クエリ作成者は、引用符内のデータを Oracle データベースが確実に認識できるものにする必要があります。
「get」および「set」メソッドの制限
WebLogic Server では、一連のアクセサ メソッドを使用します。これらのメソッドの名前の先頭には、set と get が付いています。WebLogic Server では、コンテナ管理によるフィールドの読み出しおよび修正にこれらのメソッドを使用します。コンテナによって生成されるこれらのクラスは、「get」または「set」で始まり、ejb-jar.xml で定義されている永続フィールドの実際の名前を使用する必要があります。また、これらのメソッドは、public、protected、およびabstract として宣言します。
Oracle DBMS の BLOB および CLOB DBMS カラムのサポート
WebLogic Server は、Oracle Binary Large Object（BLOB）および Character Large Object（CLOB）DBMS カラムを EJB CMP でサポートしています。BLOB および CLOB は、大きなオブジェクトを効率的に保存したり、検索したりするためのデータ型です。CLOB は文字オブジェクトで、BLOB は大きなバイト配列に変換される画像などのバイナリまたはシリアライズ可能オブジェクトです。
BLOB および CLOB は、文字列変数である OracleBlob または OracleClob の値を BLOB または CLOB カラムにマップします。WebLogic Server は、CLOB をデータ型 java.lang.string にしかマップしません。現時点では、char 配列を CLOB カラムにマップすることはできません。
BLOB/CLOB サポートを有効にするには次の手順に従います。
BLOB/CLOB オブジェクトのサイズが大きいため、BLOB または CLOB を使用すると、パフォーマンスが低下する場合があります。
デプロイメント記述子による BLOB の指定
次の XML コードは、weblogic-cmp-rdbms-jar-xml ファイルの dbms-column 要素を使用して BLOB オブジェクトを指定する方法を示しています。
コード リスト 5-2 BLOB オブジェクトの指定
<field-map>
<cmp-field>photo</cmp-field>
<dbms-column>PICTURE</dbms-column>
<dbms_column-type>OracleBlob</dbms-column-type>
</field-map>
デプロイメント記述子による CLOB の指定
次の XML コードは、weblogic-cmp-rdbms-jar-xml ファイルの dbms-column 要素を使用して CLOB オブジェクトを指定する方法を示しています。
コード リスト 5-3 CLOB オブジェクトの指定
<field-map>
<cmp-field>description</cmp-field>
<dbms-column>product_description</dbms-column>
<dbms_column-type>OracleClob</dbms-column-type>
</field-map>
カスケード削除
カスケード削除メカニズムは、エンティティ Bean オブジェクトを削除する場合に使用します。カスケード削除を特定の関係に対して指定した場合、エンティティ オブジェクトの有効期間は他方のエンティティ オブジェクトに依存します。1 対 1 関係と 1 対多関係に対してはカスケード削除を指定できますが、多対多関係に対しては指定できません。cascade delete() メソッドは WebLogic Server の削除機能を使用し、database cascade delete() メソッドでは、基盤データベースに組み込まれているカスケード削除のサポートを使用するよう WebLogic Server に指示します。
この機能を有効にするには、Bean コードを再コンパイルしてデプロイメント記述子の変更を有効にする必要があります。
カスケード削除を有効にするには、以下の 2 つの方法のいずれかに従います。
カスケード削除メソッド
cascade delete() メソッドでは、WebLogic Server を使用してオブジェクトを削除します。削除したエンティティに関連するエンティティ Bean に対して cascade delete 要素が指定されている場合、カスケード削除が行われ、関連するエンティティ Bean もすべて削除されます。
カスケード削除を指定するには、ejb-jar.xml デプロイメント記述子要素の cascade-delete 要素を使用します。 これはデフォルト メソッドです。データベースの設定には変更を加えません。WebLogic Server は、カスケード削除が行われる場合に削除対象のエンティティ オブジェクトをキャッシュします。
カスケード削除を指定するには、ejb-jar.xml ファイルの cascade-delete 要素を使用します。
コード リスト 5-4 カスケード削除の指定
<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-relation 要素に含まれる一方の ejb-relationship-role 要素に対してのみ指定できます。この場合、同じ ejb-relation 要素の他方の ejb-relationship-role 要素に値が one の multiplicity 属性が指定されている必要があります。
データベース カスケード削除メソッド
database cascade delete() メソッドを使用すると、アプリケーションはデータベースに組み込まれているカスケード削除のサポートを利用できるので、パフォーマンスの向上を見込めます。db-cascade-delete 要素を weblogic-cmp-rdbms-jar.xml ファイルにまだ指定していない場合、データベースのカスケード削除機能を有効にしないでください。有効にすると、データベースで不正な結果が生成されます。
weblogic-cmp-rdbms-jar.xml ファイルのdb-cascade-delete 要素では、基盤となる DBMS の組み込みカスケード削除機能をカスケード削除処理で使用するよう指定します。この機能はデフォルトでは無効になっているので、EJB コンテナは Bean ごとに SQL DELETE 文を発行してカスケード削除に関連する Bean を削除します。
db-cascade-delete 要素を weblogic-cmp-rdbms-jar.xml に指定する場合、cascade-delete 要素を ejb-jar.xml に指定する必要があります。
db-cascade-delete を有効にすると、データベース テーブルの追加設定が必要になります。たとえば、dept がデータベースに削除された場合、Oracle データベース テーブルの次の設定によって、すべての従業員がカスケード削除されます。
コード リスト 5-5 カスケード削除用の Oracle テーブルの設定
CREATE TABLE dept
(deptno NUMBER(2) CONSTRAINT pk_dept PRIMARY KEY,
dname VARCHAR2(9) );
CREATE TABLE emp
(empno NUMBER(4) PRIMARY KEY,
ename VARCHAR2(10),
deptno NUMBER(2) CONSTRAINT fk_deptno
REFERENCES dept(deptno)
ON DELETE CASCADE );
WebLogic Server での EJB 1.1 CMP の調整更新
コンテナ管理 EJB が読み書きされるときに、コンテナは get および set コールバックを受け取るので、EJB のコンテナ管理による永続性（CMP）は、自動的に調整更新をサポートします。EJB 1.1 CMP Bean を調整すると、パフォーマンスの向上に役立ちます。
WebLogic Server は、EJB 1.1 CMP の調整更新をサポートするようになりました。ejbStore が呼び出されると、EJB コンテナはコンテナ管理フィールドがトランザクションで変更されたかどうかを自動的に判定します。変更されたフィールドだけがデータベースに書き込まれます。変更されたフィールドがない場合、データベースは更新されません。
以前のバージョンの WebLogic Server では、CMP 1.1 Bean が変更されたかどうかをコンテナに通知する isModified メソッドを記述することができました。isModified は現在も WebLogic Server でサポートされていますが、isModified メソッドを使用しないで、更新されたフィールドをコンテナに判定させることをお勧めします。
この機能は EJB 2.0 CMP に対してデフォルトで有効です。EJB CMP 1.1 の調整更新を有効にするには、weblogic-cmp-rdbms-jar.xml ファイルの次のデプロイメント記述子要素を true に設定します。
<enable-tuned-updates>true</enable-tuned-updates>
CMP の調整更新を無効にするには、このデプロイメント記述子要素を次のように設定します。
<enable-tuned-updates>false</enable-tuned-updates>
この場合、ejbStore は常にすべてのフィールドをデータベースに書き込みます。
CMP キャッシュのフラッシュ
トランザクションによる更新内容は、トランザクションで発行されたクエリ、ファインダ、および ejbSelect の結果に反映させる必要があります。この要件に従うとパフォーマンスが低下する場合があるので、新しいオプションにより、Bean に関するクエリを実行する前にキャッシュをフラッシュするように指定することができます。
このオプションが無効の場合（デフォルト設定）、現在のトランザクションの結果はクエリに反映されません。このオプションを有効にした場合、コンテナはキャッシュされているトランザクションの変更をすべてデータベースに書き込んでから新しいクエリを実行します。この方法により、変更が結果に表示されます。
このオプションを有効にするには、weblogic-cmp-rdbms-jar.xml ファイルで include-updates 要素を true に設定します。
コード リスト 5-6 トランザクションの結果をクエリに反映するための指定
<weblogic-query>
<query-method>
<method-name>findBigAccounts</method_name>
<method-params>
<method-param>double</method-param>
</method-params>
</query-method>
<weblogic-ql>WHERE BALANCE>10000 ORDERBY NAME</weblogic-ql>
<include-updates>true</include-updates>
</weblogic-query>
デフォルトは false で、この設定は最大限のパフォーマンスを実現します。キャッシュされているトランザクションに対して行われる更新はクエリの結果に反映され、変更はデータベースには書き込まれず、クエリの結果に変更は見られません。
この機能を使用するかどうかは、データを最新かつ一貫性のあるものにしておくことよりもパフォーマンスを重視するかどうかで判断します。
主キー
主キーとは、エンティティ Bean をそのホーム内で一意に識別するオブジェクトです。コンテナはエンティティ Bean の主キーを操作できる必要があります。個々のエンティティ Bean クラスは、その主キーに対して別のクラスを定義できますが、複数のエンティティ Bean クラスが同じ主キー クラスを使用できます。主キーはエンティティ Bean のデプロイメント記述子で指定されます。エンティティ Bean クラスで 1 つまたは複数のフィールドに主キーをマップすることにより、永続性がコンテナによって管理されるエンティティ Bean に対して主キー クラスを指定できます。
すべてのエンティティ オブジェクトはそのホーム内で一意な ID を持ちます。2 つのエンティティ オブジェクトのホームと主キーが共通する場合、両者は同一のものと見なされます。クライアントはエンティティ オブジェクトのリモート インタフェースへの参照に対して getPrimaryKey() メソッドを呼び出して、そのホーム内でのエンティティ オブジェクトの ID を調べることができます。参照と関連付けられたオブジェクト ID は、参照が有効な間は変化しません。したがって getPrimaryKey() メソッドは、同じエンティティ オブジェクトの参照に対して呼び出されたときは常に同じ値を返します。エンティティ オブジェクトの主キーを知っているクライアントは、Bean のホーム インタフェースの findByPrimaryKey(key) メソッドを呼び出すことによって、エンティティ オブジェクトへの参照を取得することができます。
1 つの CMP フィールドにマップされた主キー
エンティティ Bean クラスでは、主キーを 1 つの CMP フィールドにマップできます。ejb-jar.xml ファイルのデプロイメント記述子である primkey-field 要素を使用して、主キーであるコンテナ管理フィールドを指定します。prim-key-class 要素は主キー フィールドのクラスでなければなりません。
1 つまたは複数の CMP フィールドをラップする主キー クラス
主キー クラスを 1 つまたは複数のフィールドにマップすることができます。主キー クラスは public でなければならず、パラメータを取らない public コンストラクタを持たなければなりません。ejb-jar.xml ファイルのデプロイメント記述子である prim-key-class 要素を使用して、エンティティ Bean の主キー クラスの名前を指定します。このデプロイメント記述子要素にはクラス名だけを指定できます。主キー クラス内のすべてのフィールドは public として宣言する必要があります。クラス内のフィールドは、ejb-jar.xml ファイル内の主キー フィールドと同じ名前を持たなければなりません。
主キーの使用に関するヒント
WebLogic Server で主キーを使用する場合のヒントをいくつか挙げておきます。
データベース カラムへのマッピング
WebLogic Server では、データベース カラムを cmp-field と cmr-field に同時にマップすることができます。その場合、cmp-field は読み取り専用となります。cmp-field が主キー フィールドの場合、cmp-field に対して setXXX メソッドを使うことによって create() メソッドが呼び出されたときにフィールドの値が設定されるように指定します。
EJB 2.0 CMP に対する自動主キー生成
WebLogic Server は、コンテナ管理による永続性（CMP）用の自動主キー生成機能をサポートしています。
注意: この機能は EJB CMP 2.0 コンテナに対してのみサポートされており、EJB CMP 1.1 に対する自動主キー生成機能はサポートされていません。1.1 Bean の場合は、Bean 管理による永続性（BMP）を使用する必要があります。
生成されるキーのサポートは以下の 2 つの方法で提供されます。
このオプションでは、コンテナはすべてのキー生成を基底のデータベースに委ねます。この機能を有効にするには、サポートされている DBMS の名前と、データベースで必要な場合にはジェネレータ名を指定します。CMP コードは、この機能を実装するすべての細部を処理します。
この機能の詳細については、Oracle 用主キー サポートの指定と Microsoft SQL Server 用主キー サポートの指定を参照してください。
注意: Oracle のテーブルの作成手順については、Oracle データベースのマニュアルを参照してください。
weblogic-cmp-rdbms-jar.xml ファイルで key_cache_size 要素を設定して、データベースの SELECT および UPDATE によって一度に取得する主キー値の数を指定します。key_cache_size のデフォルト値は 1 です。データベース アクセスを最小限に抑えてパフォーマンスを向上するために、BEA ではこの要素には値 >1 を設定することを推奨しています。この機能の詳細については、主キーの命名済シーケンス テーブル サポートの指定を参照してください。
現時点では、WebLogic Server は、Oracle および Microsoft SQL Server 向けの DBMS 主キー生成サポートだけを提供します。ただし、命名済シーケンス テーブルは、サポートされている他のデータベースで使用できます。また、この機能は単純（非複合）主キーで使用することを想定したものです。
注意: キー フィールドは、Bean の抽象「get」および「set」メソッドで java.lang.Integer 型として宣言しなければなりません。
キー フィールドの有効値
Bean の抽象「get」および「set」メソッドでは、キー フィールドを以下のいずれかの型として宣言できます。
Oracle 用主キー サポートの指定
Oracle データベース用の主キー生成サポートでは、Oracle の SEQUENCE 機能が使用されます。この機能は、Oracle データベース内の Sequence エンティティと連携して一意の主キーを生成します。Oracle SEQUENCE は、新しい数値が必要な場合に呼び出されます。
SEQUENCE がデータベース内に作成されたら、XML デプロイメント記述子で自動キー生成を指定します。weblogic-cmp-rdbms-jar.xml ファイルで、次のように自動キー生成を指定します。
コード リスト 5-7 Oracle 用自動キー生成の指定
<automatic-key-generation>
<generator-type>ORACLE</generator-type>
<generator_name>test_sequence</generator-name>
<key-cache-size>10</key-cache-size>
</automatic-key-generation>
generator-name 要素で、使用する ORACLE SEQUENCE の名前を指定します。ORACLE SEQUENCE が SEQUENCE INCREMENT 値を付けて作成した場合は、key-cache-size を指定しなければなりません。この値は、Oracle SEQUENCE INCREMENT 値と一致する必要があります。これら 2 つの値が一致しない場合、重複キーの問題が発生する可能性が高くなります。
Microsoft SQL Server 用主キー サポートの指定
Microsoft SQL Server データベース用の主キー生成サポートでは、SQL Server の IDENTITY カラムが使用されます。Bean が作成され、新しい行がデータベース テーブルに挿入されると、SQL Server は、IDENTITY カラムとして指定されたカラムに、次の主キー値を自動的に挿入します。
注意: Microsoft SQL Server のテーブルの作成手順については、Microsoft SQL Server データベースのマニュアルを参照してください。
IDENTITY がデータベース テーブル内に作成されたら、XML デプロイメント記述子で自動キー生成を指定します。weblogic-cmp-rdbms-jar.xml ファイルで、次のように自動キー生成を指定します。
コード リスト 5-8 Microsoft SQL 用自動キー生成の指定
<automatic-key-generation>
<generator-type>SQL_SERVER</generator-type>
</automatic-key-generation>
generator-type 要素では、主キーの生成方法を指定します。
主キーの命名済シーケンス テーブル サポートの指定
サポートされていないデータベース向けの主キー生成サポートでは、Named SEQUENCE TABLE を使用してキー値を保持します。テーブルには、整数の SEQUENCE INT である単一カラムを持つ単一行を含める必要があります。このカラムは、現在のシーケンス値を保持します。
注意: テーブルの作成手順については、各データベース製品のマニュアルを参照してください。
NAMED_SEQUENCE_TABLE がデータベース内に作成されたら、次の例のように、weblogic-cmp-rdbms-jar.xml ファイル内の XML デプロイメント記述子を使用して自動キー生成を指定します。
コード リスト 5-9 命名済シーケンス テーブル用の自動キー生成サポートの指定
<automatic-key-generation>
<generator-type>NAMED_SEQUENCE_TABLE</generator-type>
<generator_name>MY_SEQUENCE_TABLE_NAME</generator-name>
<key-cache-size>100</key-cache-size>
</automatic-key-generation>
generator-name 要素によって、使用する SEQUENCE TABLE の名前を指定します。key-cache-size を使用すると、1 回の DBMS 呼び出しでコンテナが取得するキーの数を示すキー キャッシュのサイズをオプションで指定することもできます。
パフォーマンスを向上するために、BEA ではこの値を >1（1 より大きい）に設定することを推奨しています。この設定により、次のキー値を取得するためのデータベースの呼び出し回数を減らすことができます。
また、NAMED SEQUENCE テーブルは Bean のタイプごとに作成することをお勧めします。異なるタイプの Bean が NAMED SEQUENCE テーブルを共有しないようにしてください。こうすることで、キー テーブルの競合の発生を防ぎます。
自動テーブル作成
テーブルがまだ作成されていない場合には、XML デプロイメント記述子ファイルおよび Bean クラスの記述に基づいて、WebLogic Server がテーブルを自動的に作成するよう指定できます。JAR ファイル内の関係に結合が含まれている場合、テーブルはすべての Bean および関係の結合テーブルに対して作成されます。この機能を明示的に有効にするには、JAR ファイルのすべての Bean に対して、RDBMS のデプロイメントごとのデプロイメント記述子でこの機能を定義します。
WebLogic Server は、できる限り新しいテーブルを作成しようとします。しかし、デプロイメント ファイルの記述に基づいてフィールドをデータベース内の適切なカラム タイプにマップできない場合、TABLE CREATION は失敗し、エラーが送出されるので、テーブルを手動で作成する必要があります。
プロダクション環境では自動テーブル作成を使用しないことをお勧めします。この機能は、設計および試作品の開発段階での使用が適しています。プロダクション環境では、外部キーの制約の宣言など、より正確なテーブル スキーマ定義を使用する必要があります。
自動テーブル作成を定義するには、次の手順に従います。
自動テーブル作成機能ではすべての Java フィールド タイプを対象データベースに正しくマップできない場合もあるので、マッピングの内容を把握できるように次のリストが用意されています。
表5-1 Java フィールド タイプ
コンテナ管理による永続性関係
エンティティ Bean では、コンテナ管理による永続性を利用して、エンティティ Bean インスタンスで永続データ アクセスを実行するメソッドが生成されます。生成されたメソッドでは、エンティティ Bean インスタンスと基盤のリソース マネージャの間でデータが転送されます。永続性は実行時にコンテナによって処理されます。コンテナ管理の永続性を利用する利点は、エンティティが格納されるデータ ストアからエンティティ Bean が論理的に独立することです。コンテナでは、論理的な関係と物理的な関係のマッピングが実行時に管理されると同時に、それらの参照整合性が管理されます。
永続フィールドと関係によって、エンティティ Bean の抽象永続性スキーマが構成されます。デプロイメント記述子は、エンティティ Bean でコンテナ管理による永続性が使用されることを示します。また、デプロイメント記述子は、データにアクセスするコンテナへの入力としても使用されます。
エンティティ Bean は、他の Bean と関係を持つことができます。それらの関係は、双方向の場合と一方向の場合があります。
関係は、ejb-jar.xml ファイルと weblogic-cmp-rdbms-jar.xml ファイルで指定します。コンテナ管理フィールドのマッピングは、weblogic-cmp-rdbms-jar.xml ファイルで指定します。
WebLogic Server では、WebLogic のコンテナ管理による永続性（CMP）によって管理される以下の 3 種類の関係をマップできます。
1 対 1 の関係
WebLogic Server の 1 対 1 の関係では、一方の Bean の外部キーが他方の Bean の主キーに物理的にマップされます。主キーの詳細については、主キーを参照してください。
1 対多の関係
WebLogic Server の 1 対多の関係では、一方の Bean の外部キーが他方の Bean の主キーに物理的にマップされます。ただし 1 対多の関係では、外部キーが常に、関係の「多」サイドのロールに格納されます。
多対多の関係
WebLogic Server の多対多の関係には、結合テーブルの物理的なマッピングが伴います。結合テーブルの各行には、関係に関与するエンティティの主キーにマップする 2 つの外部キーが格納されます。
一方向の関係
一方向の関係では、一方向でのみナビゲートできます。これらの関係はリモート Bean との間に使用され、一方向の関係だけがリモートの関係になります。リモート Bean とは、同じ EJB-jar ファイルで関係を持つ Bean として定義されていない抽象的永続性スキーマを持つ Bean のことです。たとえば、エンティティ A とエンティティ B が 1 対 1 の関係にあり、その方向がエンティティ A からエンティティ B への一方向である場合、エンティティ A はエンティティ B の存在を認識していますが、エンティティ B はエンティティ A の存在を認識していません。このタイプの関係は、ナビゲーションが行われるエンティティ Bean に CMR-field があり、対象のエンティティ Bean に関連する CMR-field がない状態で実装されます。
双方向の関係
双方向の関係では、双方向でナビゲートできます。このタイプのコンテナ管理の関係は、抽象永続性スキーマが同じ EJB-jar ファイルで定義されており、したがって同じコンテナ マネージャによって管理される Bean の間だけで成立します。たとえば、エンティティ A とエンティティ B が 1 対 1 で双方向の関係にある場合、両者は互いに認識し合います。
関係内の Bean の削除
別の Bean と関係を持つ Bean が削除されると、コンテナはその関係を自動的に削除します。
ローカル インタフェース
WebLogic Server は、セッション Bean およびエンティティ Bean 用のローカル インタフェースをサポートしています。ローカル インタフェースを使用すると、エンタープライズ JavaBean は、同じ EJB コンテナ内で別のセマンティクスと実行コンテキストを使用して動作できます。通常、EJB は同じ EJB 内にあり、同じ Java 仮想マシン（JVM）内で動作します。このようにして、EJB は通信にネットワークを使用せず、Java Remote Method Invocation-Internet Inter-ORB Protocol（RMI-IIOP）接続によるオーバーヘッドの発生を防ぎます。
EJB とコンテナ管理による永続性の関係は、EJB のローカル インタフェースに基づいています。したがって、関係に関わる EJB には、ローカル インタフェースが必要です。ローカル インタフェース オブジェクトは、軽量の永続的オブジェクトです。これらのオブジェクトを使用すると、リモート オブジェクトを使用するよりも完成度の高いコーディングが可能になります。ローカル インタフェースも参照渡しです。ゲッターはローカル インタフェースに含まれています。
以前のバージョンの WebLogic Server では、リモート インタフェースに基づいて関係を指定できます。しかし、新しいコードでは、リモート インタフェースを使用する CMP の関係を使用しないことをお勧めします。
EJB コンテナを使用すると、ローカル クライアントが JNDI 経由でローカル ホーム インタフェースにアクセスできるようになります。ローカル インタフェースを参照するには、ローカルの JNDI 名が必要です。エンティティ Bean のローカル ホスト インタフェースを実装するオブジェクトは、EJBLocalHome オブジェクトと呼ばれます。
6.1 より前のバージョンの WebLogic Server では、リモート インタフェースを返すために ejbSelect メソッドが使用されていました。現在では、クエリの結果をローカルまたはリモートのどちらのオブジェクトにマップするかを示す ejb-jar.xml ファイルの result-type-mapping 要素を指定します。
ローカル クライアントの使用
セッション Bean またはエンティティ Bean のローカル クライアントは、セッション Bean、エンティティ Bean、メッセージ駆動型 Bean など別の EJB です。ローカル クライアントは、同じ EAR ファイルに含まれており、かつその EAR ファイルがリモートでない限り、サーブレットでもかまいません。ローカル Bean のクライアントは、EAR またはスタンドアロン JAR の一部でなければなりません。
ローカル クライアントは、Bean のローカル インタフェースとローカル ホーム インタフェースを介してセッション Bean またはエンティティ Bean にアクセスします。コンテナは、Bean のローカル インタフェースとローカル ホーム インタフェースを実装するクラスを提供します。これらのインタフェースを実装するオブジェクトは、ローカル Java オブジェクトです。次の図は、ローカル クライアントとローカル インタフェースを持つコンテナを示しています。
図5-1 ローカル クライアントとローカル インタフェース
WebLogic Server は、EJB 間でローカルの関係と一方向のリモート関係の両方をサポートしています。EJB が同じサーバ上にあり、同じ JAR ファイルを構成している場合、EJB はローカルの関係を持ちます。EJB が同じサーバ上にない場合、関係はリモートでなければなりません。ローカル Bean の関係では、その関係を実装するキーが複合キーである場合は複数カラムのマッピングを指定します。リモート Bean の場合は、リモート Bean の主キーが不明であるため、単一の column-map だけが指定されます。ロールが group-name だけを指定している場合、column-map は指定されません。関係がリモートの場合は group-name は指定されません。
ローカル インタフェースに関するコンテナの変更
ローカル インタフェースを格納するために、コンテナの構造が変更され、以下のものが追加されています。
グループ
コンテナ管理による永続性では、グループを使用して、エンティティ Bean の特定の永続的な属性を指定します。field-group は、Bean の cmp-field と CMR-field のサブセットを表します。Bean 内の関連フィールドを、障害のあったグループにまとめて 1 つのユニットとしてメモリ内に入れることができます。グループをクエリまたは関係に関連付けることができます。それによって、クエリを実行するか、または関係に従った結果として Bean がロードされたときに、グループ内の指定フィールドのみがロードされます。
指定したグループを持たないクエリと関係に対して、「default」という特殊なグループを使用します。デフォルトでは、default グループには、Bean のすべての CMP-field と、Bean の永続的な状態に外部キーを追加するすべての CMR-field が格納されます。
フィールドは複数のグループに関連付けられている場合があります。この場合、フィールドに対して getXXX() メソッドを実行すると、そのフィールドを含む最初のグループで障害が発生します。
フィールド グループの指定
フィールド グループは、weblogic-rdbms-cmp-jar.xml ファイルで次のように指定します。
<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 フィールドの Java データ型
次の表は、WebLogic Server で使用される CMP フィールドの Java データ型と、それに対応する標準 SQL データ型の Oracle 拡張を示しています。
表5-2 CMP フィールドの Java データ型
SQL CHAR データ型は、CMP フィールドにマップされるデータベース カラムには使用しないでください。このことは、主キーの一部であるフィールドで特に重要です。なぜなら、JDBC ドライバによって返されるパディングの空白は、等しいかどうかの比較を不適切に失敗させるからです。SQL CHAR の代わりに、SQL VARCHAR データ型を使用してください。
byte[] 型の CMP フィールドは、equals() メソッドと hashCode() メソッドを備えるユーザ定義の主キー クラスでラップされていない限り主キーとしては使用できません。なぜなら、byte[] クラスには実質的な equals および hashCode が備わっていないからです。
|
|
|