Oracle® Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド 11g リリース 1 (10.3.1) B55528-01 |
|
戻る |
次へ |
新規ユーザは、分散ビジネス アプリケーションの実装に 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
の場合は、エントリを指定しなくても、コンパイル時に finder-list が生成されます。
注意 : 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 ファインダを作成してください。