|
|
新規ユーザは、分散ビジネス アプリケーションの実装に 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 では、ファインダを簡単に作成できます。
appc は、ejb-jar.xml のクエリを使用して、デプロイメント時にファインダ メソッドの実装を作成します。
RDBMS 永続性用のファインダの主要コンポーネントは以下のとおりです。
以降の節では、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 演算子は、単一のオペランド、テキスト文字列、またはキーワードを受け付けます。
|
||||
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>
<method-name>findBigAccounts</method-name>
<method-params>
<method-param>double</method-param>
</method-params>
<finder-query><![CDATA[(> balance $0)]]></finder-query>
</finder>
| 注意 : | 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>
firstName フィールドを持つすべての EJB が返されます。<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>
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 クエリを解釈しようとはしません。
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 の最上位要素は次のとおりです。
descriptionweblogic-versionweblogic-enterprise-beanejb-namecaching-descriptorpersistence-descriptorclustering-descriptortransaction-descriptorreference-descriptorjndi-nametransaction-isolationsecurity-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-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>
<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>
< 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 には、サービスのプロパティを定義する要素が含まれます。
| 注意 : | 指定したバージョンは、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’).
以下は、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 は以下のいずれかの値に定義できます。
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>
<res-ref-name>. . .</res-ref-name>
<jndi-name>. . .</jndi-name>
</resource-description>
<ejb-ref-name>. . .</ejb-ref-name>
<jndi-name>. . .</jndi-name>
</ejb-reference-description>
</reference-descriptor>
以下の要素で、各 resource-description を定義します。
以下の要素で、各 ejb-reference-description を定義します。
デフォルトでは、同じ EAR から呼び出された EJB メソッドは引数を参照で渡します。パラメータはコピーされないので、これによってメソッド呼び出しのパフォーマンスが向上します。
enable-call-by-reference を false に設定すると、EJB 1.1 の仕様に従って EJB メソッドへのパラメータがコピーされ (値で渡され) ます。EJB がリモートで (同じアプリケーション以外から) 呼び出される場合は、常に値で渡す必要があります。
jndi-name 要素は、Bean、リソース、または参照の JNDI 名を指定します。
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 つまたは複数、指定できます。
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>
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 仕様では必須です)。EJB QL では、埋め込まれた Java 式はサポートされていません。そのため、今後の EJB コンテナに簡単にアップグレードできるよう、WLQL でも Java 式を埋め込まずにエンティティ EJB ファインダを作成してください。
  
|