Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発 12c (12.2.1.1.0) E77277-02 |
|
![]() 前 |
![]() 次 |
この付録の内容は次のとおりです。
クライアントはファインダ・メソッドを使用して、問合せを実行し、問合せ条件を満たすエンティティBeanの参照を受け取ることができます。この節では、RDBMS永続性を使用するWebLogic固有の1.1 EJB用のファインダを作成する方法について説明します。コンテナ管理による永続性を利用する2.0 EJBのファインダ問合せを定義するには、ポータブルな問合せ言語であるEJB QLを使用します。
WebLogic Serverでは、ファインダを簡単に作成できます。
EJBHome
インタフェースでファインダのメソッド・シグネチャを記述します。
ejb-jar.xml
デプロイメント・ファイルでファインダの問合せ式を定義します。
appc
は、ejb-jar.xml
の問合せを使用して、デプロイメント時にファインダ・メソッドの実装を作成します。
RDBMS永続性用のファインダの主要コンポーネントは以下のとおりです。
EJBHome
内のファインダ・メソッド・シグネチャ
ejb-jar.xml
内で定義されるquery
要素
weblogic-cmp-jar.xml
内の省略可能なfinder-query
要素
以降の節では、WebLogic Serverデプロイメント・ファイルのXML要素を使用してEJBファインダを記述する方法について説明します。
findMethodName()
という形式で、ファインダ・メソッドのシグネチャを指定します。weblogic-cmp-jar.xml
に定義されるファインダ・メソッドは、EJBオブジェクトのJavaコレクションまたは単一オブジェクトを返す必要があります。
注意:
関連付けられているEJBクラスの単一オブジェクトを返すfindByPrimaryKey(primkey)
メソッドを定義することもできます。
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
を使用します。完全修飾名を使用しないと、デプロイメント・ユニットのコンパイル時にappc
でエラー・メッセージが生成されます。
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をロードできます。そのため、Beanが100あってもデータベースに一度アクセスするだけでロードできます。Bean管理による永続性(BMP)ファインダは、データベースに一度アクセスして、ファインダで選択したBeanの主キー値を取得する必要があります。各Beanにアクセスする場合、通常はBeanがキャッシュされていないとことを想定して、もう一度データベースにアクセスする必要があります。したがって、100のBeanにアクセスするために、BMPはデータベースに101回アクセスします。
EJB 1.1 CMP用のWebLogic問合せ言語(WLQL)を使用すると、コンテナ管理による永続性を利用する1.1エンティティEJBを問合せできます。weblogic-cmp-jar.xml
ファイルでは、各finder-query
要素に、EJBを返すための問合せを定義するWLQL文字列が指定されていなければなりません。EJB向けのWLQLとそれに対応するデプロイメント・ファイル(EJB 1.1仕様に基づいたもの)を使用します。
WLQL文字列では、比較演算子用に次の接頭辞表記法を使用します。
(operator operand1 operand2)
追加のWLQL演算子は、単一のオペランド、テキスト文字列、またはキーワードを受け付けます。
次の表に、有効なWLQL演算子を示します。
表F-1 WLQL演算子
演算子 | 説明 | サンプル構文 |
---|---|---|
|
等しい |
|
|
より小さい |
|
|
より大きい |
|
|
以下 |
|
|
以上 |
|
|
Boolean not |
|
|
Boolean and |
|
|
Boolean or |
|
|
指定された |
|
|
単一オペランドの値がNULL |
|
|
単一オペランドの値がNULL以外 |
|
|
指定されたデータベース列を基準に結果を並び替える 注意 : |
|
|
結果を降順に並び替える( |
|
有効なWLQLオペランドは以下のとおりです。
別のWLQL式
weblogic-cmp-jar.xml
ファイルの別の場所で定義されたコンテナ管理フィールド
注意:
RDBMS列名はWLQLのオペランドとして使用できません。代わりに、weblogic-cmp-jar.xml
のattribute-map
に定義されているとおり、RDBMS列にマップされるEJB属性(フィールド)を使用します。
$n
によって識別されるファインダ・パラメータまたはJava式。n
はパラメータまたは式の数です。デフォルトでは、$n
は、ファインダ・メソッド・シグネチャのn番目のパラメータにマップされます。Java式が組み込まれたより高度なWLQL式を記述するには、$n
をJava式にマップします。
注意:
$n
という表記法は、1ではなく0で始まる配列に基づいています。たとえば、ファインダの最初の3つのパラメータは、$0
、$1
、および$2
に対応しています。式は個々のパラメータにマップされる必要はありません。高度なファインダは、パラメータより多くの式を定義できます。
次のサンプル・コードは、weblogic-cmp-jar.xml
ファイルから基本的なWLQL式を使用する部分を抜粋したものです。
この例では、ファインダに指定されたbalanceGreaterThan
パラメータより大きいbalance
属性を持つすべてのEJBが返されます。EJBHome内のファインダ・メソッド・シグネチャは次のとおりです。
public Enumeration findBigAccounts(double balanceGreaterThan) throws FinderException, RemoteException;
<finder>
要素の例は次のとおりです。
<finder> <method-name>findBigAccounts</method-name> <method-params> <method-param>double</method-param> </method-params> <finder-query><![CDATA[(> balance $0)]]></finder-query> </finder>
balance
フィールドは、EJBの永続デプロイメント・ファイルの中の属性マップに定義する必要があります。
注意:
finder-query
値のテキストは、常に、XML CDATA
属性を使用して定義してください。CDATA
を使用すると、WLQL文字列中に特殊文字が入っていても、ファインダをコンパイルしたときにエラーが発生しないようになります。
次に、複雑なWLQL式の使用例を示します。文字列を区切る引用符(')の使い方にも注意してください。
<finder-query><![CDATA[(& (> balance $0) (! (= accountType 'checking')))]]></finder-query>
次の例では、表内のすべてのEJBが検索されます。この例では、次のファインダ・メソッド・シグネチャを使用しています。
public Enumeration findAllAccounts() throws FinderException, RemoteException
<finder>
要素の例では、空のWLQL文字列が使用されています。
<finder> <method-name>findAllAccounts</method-name> <finder-query></finder-query> </finder>
次の問合せでは、lastName
フィールドが「M」で始まるすべてのEJBが検索されます。
<finder-query><![CDATA[(like lastName M%)]]></finder-query>
次の問合せでは、nullのfirstName
フィールドを持つすべてのEJBが返されます。
<finder-query><![CDATA[(isNull firstName)]]></finder-query>
次の問合せでは、balanceフィールドが5000より大きいすべてのEJBが返され、それらのBeanがデータベース列idによってソートされます。
<finder-query><![CDATA[WHERE >5000 (orderBy 'id' (> balance 5000))]]></finder-query>
次の問合せは前の例とほぼ同じですが、EJBが降順で返されます。
<finder-query><![CDATA[(orderBy 'id desc' (> ))]]></finder-query>
WebLogic Serverでは、標準WLQL問合せの代わりにSQL文字列を使用し、CMP 1.1ファインダ問合せ用のSQLを記述することができます。SQL文がCMP 1.1ファインダ問合せとしてデータベースから値を取り出します。複雑なファインダ問合せが必要とされWLQLを使えない場合に、SQLを使ってCMP 1.1ファインダ問合せを記述します。
WLQLの詳細については、「EJB 1.1 CMP用のWebLogic問合せ言語(WLQL)の使用」を参照してください
SQLファインダ問合せを指定するには、次の手順に従います。
「より大きい(>)」や「より小さい(<)」のシンボルなど、SQL問合せ内でXMLパーサーを混乱させる可能性のある文字を使用する場合には、必ず、前述のSQL文の例のようにCDATA形式を使用してSQL問合せを宣言してください。
SQL問合せ内ではベンダー固有のSQLを際限なく使用できます。
コンテナ管理EJBが読み書きされるときに、コンテナはget
およびset
コールバックを受け取るので、EJBのコンテナ管理による永続性(CMP)は、自動的に調整更新をサポートします。EJB 1.1 CMP Beanを調整すると、パフォーマンスの向上に役立ちます。
WebLogic Serverは、EJB 1.1 CMPの調整更新をサポートするようになりました。ejbStore
が呼び出されると、EJBコンテナはコンテナ管理フィールドがトランザクションで変更されたかどうかを自動的に判定します。変更されたフィールドだけがデータベースに書き込まれます。変更されたフィールドがない場合、データベースは更新されません。
旧バージョンのWebLogic Serverでは、EJB 1.1 CMP Beanが変更されたかどうかをコンテナに通知するisModified
メソッドを記述することができました。isModified
は現在もWebLogic Serverでサポートされていますが、isModified
メソッドを使用しないで、更新されたフィールドをコンテナに判定させることをお薦めします。
この機能はEJB 2.0 CMPに対してデフォルトで有効です。EJB 1.1 CMPの調整更新を有効にするには、weblogic-cmp-jar.xml
ファイルの次のデプロイメント記述子要素をtrue
に設定します。
<enable-tuned-updates>true</enable-tuned-updates>
CMPの調整更新を無効にするには、このデプロイメント記述子要素を次のように設定します。
<enable-tuned-updates>false</enable-tuned-updates>
この場合、ejbStore
は常にすべてのフィールドをデータベースに書き込みます。
is-modified-method-name
デプロイメント記述子要素は、EJB 1.1のコンテナ管理永続性(CMP) Beanだけに適用されます。この要素は、weblogic-ejb-jar.xml
ファイルに入っています。WebLogic ServerのCMP実装では、CMPフィールドの変更が自動的に検出され、それらの変更だけが基底のデータ・ストアに書き込まれます。Bean管理の永続性(BMP)ではis-modified-method-name
を使用しないことをお薦めします。is-modified-method-name
要素とejbstore
メソッドの両方を作成する必要があるからです。
WebLogic Serverはデフォルトで、各トランザクションが正常に完了(コミット)したときにejbStore()
メソッドを呼び出します。ejbStore()
は、EJBの永続フィールドが実際に更新されたかどうかに関係なくコミット時に呼び出され、その結果としてDBMSが更新されます。WebLogic Serverは、ejbStore()
が不必要に呼び出されてパフォーマンスが低下する場合に備えてis-modified-method-name
要素を提供します。
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」を参照してください
WebLogic Server 5.1のweblogic-ejb-jar.xml
ファイルは、EJB 1.1 Beanで使用するEJB文書型定義(DTD)を定義します。これらのデプロイメント記述子要素はWebLogic固有です。WebLogic Server 5.1のweblogic-ejb-jar.xml
の最上位要素は次のとおりです。
description
weblogic-version
weblogic-enterprise-bean
ejb-name
caching-descriptor
persistence-descriptor
clustering-descriptor
transaction-descriptor
reference-descriptor
jndi-name
transaction-isolation
security-role-assignment
以下の節では、WebLogic Server 5.1のweblogic-ejb-jar.xml
デプロイメント記述子の要素について説明します。
caching-descriptor
要素は、WebLogic Serverキャッシュ内のEJBの数、およびEJBに対してパッシブ化が行われるか、またはEJBがプールされるまでの時間の長さに影響します。この要素は子要素を含む全体が省略可能です。要素が定義されていない場合はデフォルト値が使用されます。
以下のcaching-descriptor
要素の例は、この節で説明するキャッシング要素を示しています。
<caching-descriptor>
<max-beans-in-free-pool>500</max-beans-in-free-pool>
<initial-beans-in-free-pool>50</initial-beans-in-free-pool>
<max-beans-in-cache>1000</max-beans-in-cache>
<idle-timeout-seconds>20</idle-timeout-seconds>
<cache-strategy>Read-Write</cache-strategy>
<read-timeout-seconds
>0</read-timeout-seconds>
</caching-descriptor>
注意:
この要素は、ステートレス・セッションEJBに対してのみ有効です。
WebLogic Serverでは、すべてのBeanクラスに対してEJBのフリー・プールが維持管理されています。この省略可能な要素では、フリー・プールのサイズを定義します。デフォルトでは、max-beans-in-free-pool
は無制限です。フリー・プール内のBeanの最大数はメモリーによってのみ制限されます。
注意:
この要素は、ステートレス・セッションEJBに対してのみ有効です。
initial-bean-in-free-pool
の値を指定すると、WebLogic Serverでは、起動時に、指定した数のBeanインスタンスがフリー・プールに生成されます。この方法でBeanインスタンスをフリー・プールに格納しておくと、要求が来てから新しいインスタンスを生成せずにBeanに対する初期要求が可能になるため、EJBの初期応答時間が短縮されます。
initial-bean-in-free-pool
が定義されていない場合のデフォルト値は0です。
注意:
この要素は、ステートフル・セッションEJBおよびエンティティEJBに対してのみ有効です。
この要素では、メモリーの許容範囲内で、このクラスのオブジェクトの最大数を指定します。max-beans-in-cache
の値に達すると、WebLogic Serverでは、最近クライアントに使用されていないEJBの一部に対してパッシブ化が行われます。また、max-beans-in-cache
の値は、EJBをWebLogic Serverのキャッシュからいつ削除するかにも影響を与えます。
max-beans-in-cache
のデフォルト値は100です。
idle-timeout-seconds
では、ステートフルEJBがキャッシュに保持される最長時間を定義します。この時間を過ぎると、キャッシュ内のBeanの数がmax-beans-in-cache
で指定した値を超えている場合、WebLogic ServerではBeanインスタンスが削除されます。
定義されていない場合、idle-timeout-seconds
のデフォルト値は600です。
read-timeout-seconds
要素では、Read-Only
エンティティBeanでの各ejbLoad()
呼出しの間隔を秒数で指定します。デフォルトでは、read-timeout-seconds
は600秒に設定されています。この値を0に設定すると、WebLogic Serverでは、そのBeanがキャッシュされた場合にのみ、ejbLoad
が呼び出されます。
persistence-descriptor
要素では、エンティティEJBに対する永続性オプションを指定します。以下に、persistence-descriptor
要素に含まれるすべての要素を示します。
<persistence-descriptor> <is-modified-method-name>. . .</is-modified-method-name> <delay-updates-until-end-of-tx>. . .</delay-updates-until-end-of-tx> <persistence-type> <type-identifier>. . .</type-identifier> <type-version>. . .</type-version> <type-storage>. . .</type-storage> </persistence-type> <db-is-shared>. . .</db-is-shared> <stateful-session-persistent-store-dir> . . . </stateful-session-persistent-store-dir> <persistence-use>. . .</persistence-use> </persistence-descriptor>
is-modified-method-name
では、EJBの保存時にWebLogic Serverによって呼び出されるメソッドを指定します。指定したメソッドはブール
値を返す必要があります。メソッドを指定しない場合、WebLogic Serverでは、EJBは常に変更されていると見なされて保存されます。
メソッドを指定して適切な値を設定すると、パフォーマンスが向上する場合があります。ただし、メソッドの戻り値にエラーがあると、データに矛盾が発生する場合があります。
トランザクションの完了時にトランザクションですべてのBeanの永続ストレージを更新するには、このプロパティをtrue
(デフォルト)に設定します。通常、これによって不要な更新を防ぐことができるため、パフォーマンスが向上します。ただし、データベース・トランザクション内のデータベース更新の順序は保持されません。
データベースがアイソレーション・レベルとしてTransactionReadCommittedUncommitted
を使用している場合は、進行中のトランザクションに関する中間結果を他のデータベースのユーザーに表示することもできます。この場合、delay-updates-until-end-of-tx
をfalse
に設定して、各メソッド呼出しの完了時にBeanの永続ストレージを更新するように指定します。
注意:
delay-updates-until-end-of-tx
をfalseに設定しても、各メソッド呼出しの後にデータベース更新が「コミットされた」状態になるわけではありません。更新はデータベースに送信されるのみです。更新は、トランザクションの完了時にのみデータベースにコミットまたはロールバックされます。
persistence-type
では、EJBで使用可能な永続性サービスを定義します。複数の永続性サービスを持つEJBをテストするために、weblogic-ejb-jar.xml
で複数のpersistence-type
エントリを定義できます。デプロイメントでは、persistence-useで定義した永続性タイプのみが実際に使用されます。
persistence-type
には、サービスのプロパティを定義する要素が含まれます。
type-identifier
では、指定した永続性タイプを示すテキストが含まれます。たとえば、WebLogic Server RDBMSベースの永続性ではWebLogic_CMP_RDBMS
という識別子が使用されます。
type-version
では、指定した永続性タイプのバージョンを指定します。
注意:
指定したバージョンは、WebLogic ServerのRDBMSの永続性のバージョンと正確に一致している必要があります。バージョンが一致していないと、次のエラーが発生します。
weblogic.ejb.persistence.PersistenceSetupException: Error initializing the CMP Persistence Type for your bean: No installed Persistence Type matches the signature of (identifier 'Weblogic_CMP_RDBMS', version 'version_number').
type-storage
では、この永続性タイプのデータを格納するファイルの絶対パスを定義します。パスは、EJBのデプロイメントJARファイルまたはデプロイメント・ディレクトリの最上位を基準にしたファイルの場所を指定する必要があります。
WebLogic Server RDBMSベースの永続性では通常、Beanの永続性データを格納するのにweblogic-cmp-jar.xml
というXMLファイルを使用します。このファイルは、JARファイルのMETA-INF
サブディレクトリにあります。
以下は、WebLogic Server RDBMSの永続性について適切な値が指定されているpersistence-type
要素の例です。
<persistence-type> <type-identifier>WebLogic_CMP_RDBMS</type-identifier> <type-version>5.1.0</type-version> <type-storage>META-INF\weblogic-cmp-jar.xml</type-storage> </persistence-type>
db-is-shared
要素はエンティティBeanに対してのみ有効です。true
(デフォルト値)に設定すると、WebLogic Serverでは、EJBデータがトランザクション間で変更されると見なされ、各トランザクションの開始時にデータが再ロードされます。false
に設定すると、WebLogic Serverでは、永続ストレージのEJBデータに排他的にアクセスすると見なされます。
stateful-session-persistent-store-dir
要素では、WebLogic Serverで、パッシブ化が行われたステートフル・セッションBeanインスタンスの状態が格納されるファイル・システム・ディレクトリを指定します。
persistence-use
プロパティはpersistence-type
とほぼ同じですが、このプロパティはデプロイ中に実際に使用される永続性サービスを定義します。persistence-use
では、persistence-type
で定義されているtype-identifier
要素とtype-version
要素を使用してサービスを指定します。
たとえば、persistence-type
で定義されているWebLogic Server RDBMSベースの永続性サービスを使用して実際にEJBをデプロイする場合、persistence-use
要素は次のようになります。
<persistence-use> <type-identifier>WebLogic_CMP_RDBMS</type-identifier> <type-version>5.1.0</type-version> </persistence-use>
clustering-descriptor
要素では、WebLogic ServerクラスタにデプロイされたEJBのレプリケーション・プロパティと動作を定義します。clustering-descriptor
要素とその各子要素は省略可能であり、単一サーバー・システムには適用できません。
以下に、clustering-descriptor
要素に含まれるすべての要素を示します。
<clustering-descriptor> <home-is-clusterable>. . .</home-is-clusterable> <home-load-algorithm>. . .</home-load-algorithm> <home-call-router-class-name>. . .</home-call-router-class-name> <stateless-bean-is-clusterable>. . .</stateless-bean-is-clusterable> <stateless-bean-load-algorithm>. . .</stateless-bean-load-algorithm> <stateless-bean-call-router-class-name>. . . </stateless-bean-call-router-class-name> <stateless-bean-methods-are-idempotent>. . . </stateless-bean-methods-are-idempotent> </clustering-descriptor>
この要素は、true
またはfalse
に設定できます。home-is-clusterable
が「true」の場合、クラスタ内の複数のWebLogic ServerからEJBをデプロイできます。ホーム・スタブの呼出しは、Beanがデプロイされるサーバー間で負荷が分散されます。Beanのホスト・サーバーにアクセスできなかった場合、呼出しは、Beanを提供する他のサーバーに自動的にフェイルオーバーします。
home-load-algorithm
では、EJBホームのレプリカ間でのロード・バランシングに使用するアルゴリズムを指定します。このプロパティを定義しない場合、WebLogic Serverはサーバー・プロパティ、weblogic.cluster.defaultLoadAlgorithm
で指定されたアルゴリズムを使用します。
home-load-algorithm
は以下のいずれかの値に定義できます。
round-robin
- Beanのホスト・サーバー間で順番にロード・バランシングを実行します。
random
- Beanのホスト・サーバー間でEJBホームのレプリカがランダムにデプロイされます。
weight-based
- ホスト・サーバーの現在の負荷に従って、EJBホームのレプリカをデプロイするサーバーが決まります。
home-call-router-class-name
では、Beanメソッド呼出しのルーティングに使用するカスタム・クラスを指定します。このクラスはweblogic.rmi.extensions.CallRouter()
を実装する必要があります。指定すると、このクラスのインスタンスは各メソッド呼出しの前に呼び出されます。ルーター・クラスでは、メソッドのパラメータを基に、ルーティングするサーバーを選択できます。このクラスは、サーバー名を返すか、または現在のロード・アルゴリズムがサーバーを選択する必要があることを示すnullを返します。
このプロパティはhome-call-router-class-name
に似ていますが、ステートレス・セッションEJBにのみ適用できます。
この要素は、true
またはfalse
に設定できます。同一引数での同一メソッドの多重呼出しが1回だけの呼出しとまったく同じになるように設計されているBeanに対してのみ、stateless-bean-methods-are-idempotent
をtrue
に設定します。これによって、フェイルオーバー・ハンドラは、失敗した呼出しが失敗したサーバーで実際に完了していたかどうかがわからなくても失敗した呼出しを再試行できます。このプロパティをtrue
に設定すると、Beanを提供する他のサーバーが使用できるようになっている限り、Beanスタブは障害から自動的に回復できます。
注意:
このプロパティは、ステートレス・セッションEJBにのみ適用できます。
transaction-descriptor
要素には、WebLogic Serverのトランザクション動作を定義する要素があります。現在、この要素の子要素は1つだけです。
<transaction-descriptor> <trans-timeout-seconds>20</trans-timeout-seconds> </transaction-descriptor>
trans-timeout-seconds
要素は、EJBのコンテナで初期化されたトランザクションの最長継続時間を指定します。トランザクションの継続時間がtrans-timeout-seconds
の値を超えると、WebLogic Serverによってトランザクションがロールバックされます。
trans-timeout-seconds
に値を指定しなかった場合、コンテナで初期化されたトランザクションはデフォルトで300秒後にタイムアウトになります。
reference-descriptor
要素では、ejb-jar.xml
ファイル内の参照が、WebLogic Serverで実際に使用可能なリソース・ファクトリとEJBのJNDI名にマップされます。
reference-descriptor
要素には、リソース・ファクトリ参照およびEJB参照を定義するために1つまたは複数の要素が追加されます。次の例に、これらの要素の構造を示します。
<reference-descriptor> <resource-description> <res-ref-name>. . .</res-ref-name> <jndi-name>. . .</jndi-name> </resource-description> <ejb-reference-description> <ejb-ref-name>. . .</ejb-ref-name> <jndi-name>. . .</jndi-name> </ejb-reference-description> </reference-descriptor>
以下の要素で、各resource-description
を定義します。
res-ref-name
ではリソース参照名を指定します。これは、EJBプロバイダによってejb-jar.xml
デプロイメント記述子ファイル内に記載される参照です。
jndi-name
では、WebLogic Serverに用意されている実際のリソース・ファクトリのJNDI名を指定します。
以下の要素で、各ejb-reference-description
を定義します。
ejb-ref-name
はEJB参照名を指定します。これは、EJBプロバイダによってejb-jar.xml
デプロイメント記述子ファイル内に記載される参照です。
jndi-name
では、WebLogic Serverに用意されている実際のEJBのJNDI名を指定します。
デフォルトでは、同じEARから呼び出されたEJBメソッドは引数を参照で渡します。パラメータはコピーされないので、これによってメソッド呼出しのパフォーマンスが向上します。
enable-call-by-reference
をfalse
に設定すると、EJB 1.1の仕様に従ってEJBメソッドへのパラメータがコピーされ(値で渡され)ます。EJBがリモートで(同じアプリケーション以外から)呼び出される場合は、常に値で渡す必要があります。
transaction-isolation
要素では、EJBメソッドに対するトランザクションのアイソレーション・レベルを指定します。この要素は、EJBメソッドの範囲に適用される1つまたは複数のisolation-level
要素で構成されます。例:
<transaction-isolation> <isolation-level>Serializable</isolation-level> <method> <description>...</description> <ejb-name>...</ejb-name> <method-intf>...</method-intf> <method-name>...</method-name> <method-params>...</method-params> </method> </transaction-isolation>
以降の節では、transaction-isolation
内の各要素について説明します。
transaction-isolation
は、EJBのメソッド・レベルのトランザクション・アイソレーション設定を定義します。有効な値は以下のとおりです。
TransactionSerializable
- このトランザクションを同時に複数回実行すると、トランザクションを順番に複数回実行することと同じことになります。
注意:
Oracleデータベースの場合は、TransactionSerializable
アイソレーション・レベルの代わりにTransactionReadCommittedForUpdate
アイソレーション・レベルを使用することをお薦めします。Oracleデータベースは、TransactionSerializable
アイソレーション・レベルではデータの読取りをロックしないためです。また、TransactionSerializable
アイソレーション・レベルでは、Oracleデータベースに対する現在のトランザクションが、Oracle例外ORA-08177「このトランザクションのアクセスをシリアル化できません」
を送出せずに続行することが可能です。TransactionReadCommittedForUpdate
アイソレーション・レベルの詳細については、「Oracleのみのアイソレーション・レベル」を参照してください
TransactionReadCommitted
- コミットした他のトランザクションの更新のみをトランザクションで表示できます。
TransactionReadUncommitted
- コミットしていない他のトランザクションの更新をトランザクションで表示できます。
TransactionRepeatableRead
- トランザクションでデータの一部を読み取ると、そのデータが他のトランザクションで変更されても、最初の読取り時と同じ値が返されます。
以下の追加の値は、Oracleデータベース、およびコンテナ管理による永続性(CMP) EJBでのみサポートされています。
TransactionReadCommittedForUpdate
- Oracleデータベース、およびコンテナ管理による永続性(CMP) EJBでのみサポートされます。この値を使用すると、アイソレーション・レベルはTransactionReadCommitted
に設定され、トランザクションの間、メソッドで実行されるSQL SELECT
文はすべてFOR UPDATE
が付加されて実行されます。この結果、選択された行が更新用にロックされます。Oracleで問合せの影響を受ける行をすぐにロックできない場合は、それらの行が解放されるまで待ちます。この状況は、トランザクションでCOMMIT
またはROLLBACK
が実行されるまで続きます。
このアイソレーション・レベルを使用すると、次のエラーを防止できます。
java.sql.SQLException: ORA-08177: can't serialize access for this transaction
このエラーは、OracleデータベースでTransactionSerializable
アイソレーション・レベルを使用したときに発生することがあります。
注意:
Oracleデータベースの場合は、TransactionSerializable
アイソレーション・レベルの代わりにこのアイソレーション・レベル(TransactionReadCommittedForUpdate
)を使用することをお薦めします。Oracleデータベースは、TransactionSerializable
アイソレーション・レベルではデータの読取りをロックしないためです。
TransactionReadCommittedNoWait
- Oracleデータベース、およびコンテナ管理による永続性(CMP) EJBでのみサポートされます。
この値を使用すると、アイソレーション・レベルはTransactionReadCommitted
に設定され、トランザクションの間、メソッドで実行されるSQL SELECT
文はすべてFOR UPDATE NO WAIT
が付加されて実行されます。この結果、選択された行が更新用にロックされます。
TransactionReadCommittedForUpdate
設定とは異なり、必要なときロックがすぐに達成されない場合、TransactionReadCommittedForUpdateNoWait
ではOracle DBMSがNOT WAIT
になります。このため、影響を受けるSELECT
問合せは失敗し、コンテナから例外が送出されます。
異なるアイソレーション・レベルのサポートの詳細については、各データベースのマニュアルを参照してください。
method
要素は、アイソレーション・レベルを適用するEJBメソッドを定義します。method
では、以下の要素を使用してメソッドの範囲を定義します。
description
は、メソッドを説明する省略可能な要素。
ejb-name
では、WebLogic Serverによってアイソレーション・レベル・プロパティが適用されるEJBを指定します。
method-intf
は、指定したメソッドがEJBのホームまたはリモートのいずれのインタフェースに存在するかを示す、省略可能な要素。この要素の値は、「Home」または「Remote」でなければなりません。method-intf
を指定しない場合は、どちらのインタフェースにあるメソッドにもアイソレーションを適用できます。
method-name
では、EJBメソッドの名前、またはすべてのEJBメソッドを示すアスタリスク(*)を指定します。
method-params
は、各メソッドのパラメータのJavaクラスのタイプを示す、省略可能な要素。各パラメータのタイプは、method-params
要素内のmethod-param
要素を使用して順番に示す必要があります。
たとえば、次のmethod要素は、「AccountBean」EJB内のすべてのメソッドを示しています。
<method> <ejb-name>AccountBean</ejb-name> <method-name>*</method-name> </method>
次のmethod要素は、「AccountBean」のリモート・インタフェース内のすべてのメソッドを示しています。
<method> <ejb-name>AccountBean</ejb-name> <method-intf>Remote</method-intf> <method-name>*</method-name> </method>
weblogic-cmp-jar.xml
では、WebLogic Server RDBMSベースの永続性サービスを使用するエンティティEJBのデプロイメント要素を定義します。
WebLogic Server 1.1のweblogic-cmp-jar.xml
の最上位要素は、weblogic-enterprise-bean
要素で構成されます。
description weblogic-version <weblogic-enterprise-bean> <pool-name>finance_pool</pool-name> <schema-name>FINANCE_APP</schema-name> <table-name>ACCOUNT</table-name> <attribute-map> <object-link> <bean-field>accountID</bean-field> <dbms-column>ACCOUNT_NUMBER</dbms-column> </object-link> <object-link> <bean-field>balance</bean-field> <dbms-column>BALANCE</dbms-column> </object-link> </attribute-map> <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-expression>. . .</finder-expression> </finder> </finder-list> </weblogic-enterprise-bean>
ここでは、weblogic-cmp-jar.xml
デプロイメント記述子の要素について説明します。
enable-tuned-updates
は、ejbStore
が呼び出された場合に、EJBコンテナがコンテナ管理フィールドの変更の有無を自動的に判定し、変更されたフィールドだけをデータベースに書き込むように指定します。
schema-name
では、データベースに置かれるソース表のスキーマを指定します。この要素は、EJBの接続プールで定義されたユーザーに対してデフォルト・スキーマではないスキーマを使用する場合にのみ必須です。
注意:
多くのSQL実装では大文字小文字が無視されますが、このフィールドは大文字小文字が区別されます。
table-name
では、データベース内のソース表を指定します。この要素はすべての場合に必須です。
注意:
EJBの接続プールで定義されたユーザーには、指定された表に対する読み書き権限が必要です。ただし、スキーマ変更権限は必ずしも必要ありません。多くのSQL実装では大文字小文字が無視されますが、このフィールドは大文字小文字が区別されます。
attribute-map
要素では、EJBインスタンスの単一フィールドがデータベース表内の特定の列にリンクされます。attribute-map
には、WebLogic Server RDBMSベースの永続性を使用するEJBのフィールドごとに1つのエントリが必要です。
bean-field
では、データベースからの移行が必要なEJBインスタンスのフィールドを指定します。この要素では大文字小文字が区別されます。この要素は、Beanインスタンスのフィールド名に正確に一致している必要があります。
また、このタグで参照されるフィールドは、Beanのejb-jar.xml
ファイル内に定義されているcmp-field
要素も持っている必要があります。
dbms-column
では、EJBフィールドがマップされるデータベース列を指定します。多くのデータベースでは大文字小文字が無視されますが、このフィールドでは大文字小文字が区別されます。
注意:
WebLogic Serverでは、引用符で囲まれたRDBMSキーワードはdbms-column
のエントリとしてはサポートされていません。たとえば、基底のデータ・ストアで「create」や「select」が予約語になっている場合、それらを列名にして属性マップを作成することができません。
finder-list
要素では、Beanの集合を見つけるために生成されるすべてのファインダの集合を定義します。
findByPrimaryKey
の場合を除いて、finder-list
には、ホーム・インタフェース内に定義されているファインダ・メソッドにごとに1つのエントリが必要です。findByPrimaryKey
にエントリが指定されなくても、コンパイル時に生成されます。
注意:
findByPrimaryKey
に対してエントリを指定すると、WebLogic Serverでは、正当性が検証されずにそのエントリが使用されます。ほとんどの場合では、findByPrimaryKey
に対するエントリを定義せずに、デフォルトで生成されるメソッドを受け入れることをお薦めします。
finder
要素では、ホーム・インタフェース内に定義されるファインダ・メソッドを記述します。finder
要素に含まれる要素によって、WebLogic Serverでは、ホーム・インタフェース内に記述されているメソッドが識別され、必要なデータベース操作を実行できるようになります。
method-params
要素では、method-name
で指定されるファインダ・メソッドに対するパラメータのリストを定義します。
注意:
WebLogic Serverでは、このリストはEJBのホーム・インタフェース内のファインダ・メソッドのパラメータ・タイプと比較されます。パラメータ・リストの順序とパラメータ・タイプは、ホーム・インタフェースで定義されている順序とパラメータ・タイプに正確に一致している必要があります。
method-param
では、パラメータ・タイプの完全修飾名を定義します。このタイプ名はjava.lang.Class
オブジェクトで評価され、その結果のオブジェクトはEJBのファインダ・メソッド内の各パラメータに正確に一致している必要があります。
「double」や「int」のようなプリミティブ名を使用してプリミティブ・パラメータを指定できます。method-param
要素内に非プリミティブなデータ型を使用する場合には、完全修飾名を指定する必要があります。たとえば、Timestamp
ではなくjava.sql.Timestamp
を使用します。完全修飾名を使用しないと、デプロイメント・ユニットのコンパイル時にappc
でエラー・メッセージが生成されます。
finder-query
では、このファインダ用にデータベースから値を取り出す場合に使用するWebLogic問合せ言語(WLQL)文字列を指定します。
注意:
finder-query
値のテキストは、常に、XML CDATA
属性を使用して定義してください。CDATA
を使用すると、WLQL文字列中に特殊文字が入っていても、ファインダをコンパイルしたときにエラーが発生しないようになります。
finder-expression
では、このファインダ用のデータベース問合せ中で変数として使用されるJava言語の式を指定します。
WebLogic Server EJBコンテナの今後のバージョンでは、EJB QL問合せ言語が使用される予定です。この問合せ言語はEJB 2.0仕様(http://java.sun.com/products/ejb/docs.html
)では必須です。EJB QLでは、埋め込まれたJava式はサポートされていません。そのため、今後のEJBコンテナに簡単にアップグレードできるよう、WLQLでもJava式を埋め込まずにエンティティEJBファインダを作成してください。