| Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング 11gリリース1(10.3.6) B61624-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング 11gリリース1(10.3.6) B61624-04 |
|
前 |
次 |
新規ユーザーは、分散ビジネス・アプリケーションの実装にEJB 2.0 Beanを使用することを強くお薦めします。しかし、既存のアプリケーションがEJB 1.1を実装している場合は、以下の節をお読みください。EJB 1.1に固有の設計および実装上の重要な情報を提供しています。ここには、EJB 1.1デプロイメント記述子の詳細なリファレンスを記載しています。
クライアントはファインダ・メソッドを使用して、問合せを実行し、問合せ条件を満たすエンティティ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ファインダ問合せを指定するには:
weblogic-cmp-jar.xmlファイルで、finder-sql要素を使って次のようにSQL問合せを記述します。
findBigAccounts(double cutoff)は次のようになります。
<finder-sql><![CDATA{balance >$0]]></finder-sql>
SQL文字列に含まれている「$0」や「$1」といった値は、ファインダ・メソッドへのパラメータを参照しています。WebLogic Server EJBコンテナは「$」をパラメータに置き換えますが、SQL問合せを解釈しようとはしません。
コンテナは次のようなSQLを発行します。
SELECT <columns> FROM table WHERE balance > ?
このSQLは、WHERE句のSQL文でなければなりません。コンテナがSELECT句とFROM句を付加します。WHERE句の中に任意の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です。
cache-strategy要素には、以下のいずれかを指定できます。
Read-Write
Read-Only
デフォルト値はRead-Writeです。
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の永続性のバージョンと正確に一致している必要があります。バージョンが一致していないと、次のエラーが発生します。
|
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-is-clusterableに似ていますが、ステートレス・セッションEJBにのみ適用できます。
このプロパティはhome-load-algorithmに似ていますが、ステートレス・セッションEJBにのみ適用できます。
このプロパティは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>
security-role-assignment要素は、ejb-jar.xmlファイル内のアプリケーション・ロールを、WebLogic Serverで使用可能なセキュリティ・プリンシパル名にマップします。
security-role-assignmentには、以下の要素を1つまたは複数、指定できます。
role-nameは、EJBプロバイダがejb-jar.xmlデプロイメント・ファイルに指定したアプリケーションのロール名。
principal-nameでは、実際のWebLogic Serverプリンシパルの名前を指定します。
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コンテナがコンテナ管理フィールドの変更の有無を自動的に判定し、変更されたフィールドだけをデータベースに書き込むように指定します。
pool-nameでは、EJBのデータベース接続に使用するWebLogic Server接続プールの名前を指定します。
schema-nameでは、データベースに置かれるソース表のスキーマを指定します。この要素は、EJBの接続プールで定義されたユーザーに対してデフォルト・スキーマではないスキーマを使用する場合にのみ必須です。
|
注意: 多くのSQL実装では大文字小文字が無視されますが、このフィールドは大文字小文字が区別されます。 |
table-nameでは、データベース内のソース表を指定します。この要素はすべての場合に必須です。
|
注意: EJBの接続プールで定義されたユーザーには、指定された表に対する読み書き権限が必要です。ただし、スキーマ変更権限は必ずしも必要ありません。多くのSQL実装では大文字小文字が無視されますが、このフィールドは大文字小文字が区別されます。 |
この節ではEJBフィールド・マッピング要素について説明します。
attribute-map要素では、EJBインスタンスの単一フィールドがデータベース表内の特定の列にリンクされます。attribute-mapには、WebLogic Server RDBMSベースの永続性を使用するEJBのフィールドごとに1つのエントリが必要です。
各attribute-mapエントリは、データベース内の列とEJBインスタンス内のフィールドとのリンクを表すobject-link要素から構成されます。
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-nameでは、ホーム・インタフェース内のファインダ・メソッドの名前を定義します。このタグには、メソッドの正確な名前を指定する必要があります。
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ファインダを作成してください。
