BEA ホーム | 製品 | dev2dev | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > WebLogic ServerTM > WebLogic エンタープライズ JavaBeans プログラマーズ ガイド > weblogic-ejb-jar.xml 文書型定義 |
WebLogic エンタープライズ JavaBeans プログラマーズ ガイド
|
以下の節では、weblogic 固有の XML 文書型定義 (DTD) ファイル、weblogic-ejb-jar.xml ファイルの EJB 1.1 および EJB 2.0 デプロイメント記述子要素について説明します。これらの定義を使用して、EJB デプロイメントを構成する WebLogic 固有の weblogic-ejb-jar.xml ファイルを作成します。
EJB デプロイメント記述子は、エンタープライズ Bean の構造およびアセンブリ情報を格納します。この情報を指定するには、3 つの EJB XML DTD ファイルのデプロイメント記述子に値を指定します。ファイルは次のとおりです。
この 3 つの XML ファイルを EJB および他のクラスと一緒にデプロイ可能なコンポーネント、通常は ejb.jar という JAR ファイルにパッケージ化します。
ejb-jar.xml ファイルは、Sun Microsystems の ejb.jar.xml ファイルのデプロイメント記述子に基づいています。その他の 2 つの XML ファイルは weblogic 固有のファイルで、weblogic-ejb-jar.xml と weblogic-cmp-rdbms-jar.xml のデプロイメント記述子に基づいています。
XML デプロイメント ファイルの編集、作成時に、デプロイメント ファイルに合わせて正しい DOCTYPE ヘッダを指定することが重要です。特に、DOCTYPE ヘッダ内部に不正な PUBLIC 要素を使用すると、原因究明が困難なパーサ エラーになることがあります。
WebLogic では、WebLogic 固有の DTD ファイル、weblogic-ejb-jar.xml の正確なテキストにアクセスできる場所を公開しています。一方で、この DTD ファイルと同一のバージョンが WebLogic Server に組み込まれ内部で使用されています。weblogic.ejbc では、XML パーサがデプロイメント記述子ファイルの並びをチェックする際にこれを使用します。
WebLogic Server 固有の weblogic-ejb-jar.xml ファイルの PUBLIC 要素には、次のようにテキストを指定する必要があります。
Sun Microsystems 固有の ejb-jar.xml ファイルの PUBLIC 要素には、次のようにテキストを指定する必要があります。
'-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' |
|
'-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN' |
たとえば、weblogic-ejb-jar.xml ファイルの DOCTYPE ヘッダは次のようになります。
<!DOCTYPE weblogic-ejb-jar PUBLIC
'-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN' 'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'>
XML の解析ユーティリティ (ejbc など) でヘッダ情報が不正な XML ファイルを解析すると、次のようなエラー メッセージが表示されることがあります。
SAXException: This document may not have the identifier 'identifier_name'
identifier_name には通常、PUBLIC 要素内の不正な文字列が表示されます。
検証用 DTD (Document Type Definitions : 文書型定義)
XML ファイルの内容および要素の配置は、使用する各ファイルの文書型定義 (DTD) に従っている必要があります。WebLogic Server では、XML デプロイメント ファイルの DOCTYPE ヘッダ内部に埋めこまれた DTD は無視され、代わりにサーバと一緒にインストールされた DTD の場所が使用されます。ただし、DOCTYPE ヘッダ情報には、パーサ エラーを避けるために、有効な URL 構文を指定する必要があります。
注意: ほとんどのブラウザでは、.dtd ファイルの内容は表示されません。DTD ファイルの内容をブラウザで見るには、リンクをテキスト ファイルとして保存し、テキスト エディタで開いて表示します。
以下のリンクでは、WebLogic Server で使用される weblogic-ejb-jar.xml デプロイメント ファイル用のパブリック DTD の場所が示されています。
以下のリンクでは、WebLogic Server で使用される ejb-jar.xml デプロイメント ファイル用のパブリック DTD の場所が示されています。
http://www.java.sun.com/dtd/ejb-jar_2_0.dtd には、すべての EJB で必要な標準 ejb-jar.xml デプロイメント ファイル用の DTD が含まれています。この DTD は、JavaSoft EJB 2.0 仕様の一部として維持管理されています。ejb-jar.dtd で使用される要素の詳細については JavaSoft 仕様を参照してください。
注意: ejb-jar.xml デプロイメント記述子の説明については、該当する JavaSoft EJB 仕様を参照してください。
WebLogic Server 7.0 EJB で変更されたデプロイメント要素
WebLogic Server 7.0 では、weblogic-ejb-jar.xml に以下の変更がありました。
2.0 の weblogic-ejb-jar.xml デプロイメント記述子ファイルの構造
WebLogic Server 7.0 の weblogic-ejb-jar.xml デプロイメント記述子ファイルには、WebLogic Server 固有の要素を記述します。WebLogic Server 7.0 と WebLogic Server 6.0 の両バージョンのデプロイメント記述子を EJB コンテナで使用できますが、weblogic-ejb-jar.xml には、WebLogic Server バージョン 7.0 と WebLogic Server バージョン 6.0 の間で違いがあります。
WebLogic Server 7.0 の weblogic-ejb-jar.xml の最上位要素は次のとおりです。
2.0 の weblogic-ejb-jar.xml デプロイメント記述子要素
allow-concurrent-calls 要素は、ステートフル セッション Bean インスタンスがメソッドの同時呼び出しを許可するかどうかを指定します。デフォルトでは、allows-concurrent-calls は false です。ただし true に設定すると、EJB コンテナはメソッドの同時呼び出しをブロックするため、前の呼び出しが完了してから次のメソッドが呼び出されるようになります。
stateful-session-descriptorを参照してください。
allow-remove-during-transaction
allow-remove-during-transaction 要素は、ステートフル セッション Bean の削除メソッドがトランザクション コンテキストで呼び出せることを指定します。
Synchronization インタフェースを実装するステートフル セッション Bean ではこのタグを使用しないで、トランザクションが終了する前に削除メソッドを呼び出す必要があります。このタグを使用すると、EJB コンテナは同期コールバックを呼び出しません。
stateful-session-descriptorを参照してください。
cache-between-transactions 要素は、以前の db-is-shared 要素に相当し、EJB コンテナがあるエンティティの永続データをトランザクション間でキャッシュするかどうかを指定します。
cache-between-transactions 要素は、エンティティ Bean に対してのみ有効です。EJB コンテナによるデータの長期キャッシングの実行を有効にする場合、True を指定します。EJB コンテナによるデータの短期キャッシングの実行を有効にする場合、False を指定します。これはデフォルト設定です。
読み込み専用 Bean の場合、WebLogic Server はこれの長期キャッシングを常に実行するので、cache-between-transactions 要素の値は無視されます。
詳細については、トランザクション間のキャッシングを参照してください。
persistenceを参照してください。
cache-type 要素は、EJB をキャッシュから削除する順序を指定します。値は次のとおりです。
NRU の最小キャッシュ サイズは 8 です。 max-beans-in-cache が 3 より小さい場合、WebLogic Server では cache-type の値に 8 が使用されます。
<stateful-session-cache>
<cache-type>NRU</cache-type>
</stateful-session-cache>
client-authentication 要素は、EJB がクライアント認証をサポートするか、または、必要とするかを指定します。
iiop-security-descriptorを参照してください。
client-cert-authentication 要素は、EJB が転送レベルでのクライアント証明書認証をサポートするか、または、必要とするかを指定します。
transport-requirementsを参照してください。
clients-on-same-server 要素によって、 EJB がデプロイされた際、WebLogic Server がこの EJB に JNDI の通知を送るかどうかが指定されます。この属性が「false」(デフォルト) の場合、WebLogic Server クラスタでは、ある特定のサーバ上にあるこの EJB の場所を示すために、自動的に JNDI ツリーを更新します。これにより、そのクライアントが同じサーバ上で連結されてなくても、すべてのクライアントがこの EJB にアクセスできることが保証されます。
EJB にアクセスするクライアントのすべてが、その Bean がデプロイされているのと同じサーバ上からアクセスすることが分かっている場合には、clients-on-same-server を true に設定できます。この場合、EJB がデプロイされる際、WebLogic Server クラスタは JNDI の通知をこのEJB に送信しません。クラスタ内の JNDI の更新ではマルチキャスト トラフィックが利用されるため、clients-on-same-server を true に設定することにより大容量のクラスタでの起動時間を短縮できます。
連結された EJB の詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「連結されたオブジェクトの最適化」を参照してください。
次の例では、EJB メソッドが値で渡すことができるようになります。
<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
...
<clients-on-same-server>true</clients-on-same-server>
</weblogic-enterprise-bean>
concurrency-strategy 要素は、コンテナがエンティティ Bean への同時アクセスを管理する方法を指定します。以下の 4 つの値のいずれかに設定します。
Exclusive および Database のロック動作の詳細については、EJB の同時方式を参照してください。 read-only エンティティ EJB の詳細については、読み込み専用マルチキャストの無効化を参照してください。
次の例では、AccountBean クラスを読み込み専用エンティティ EJB として指定します。
<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
<entity-descriptor>
<entity-cache>
<concurrency-strategy>ReadOnly</concurrency-strategy>
</entity-cache>
</entity-descriptor>
</weblogic-enterprise-bean>
confidentiality 要素は、その EJB における転送の機密性の要件を指定します。confidentiality 要素を使用すると、他のエンティティに内容を見られることなく、クライアントとサーバ間でデータが送信されることを保証します。
transport-requirementsを参照してください。
config.xml の weblogic.jms.MessageDrivenBeanConnectionFactory |
|
ステートフル セッション Bean インスタンスによるメソッド呼び出しの処理中に、同時に他のメソッド呼び出しがサーバに送信されたときに、サーバが RemoteException を送出すること。 |
|
connection-factory-jndi-name 要素は、キューおよびトピックを作成するためにメッセージ駆動型 Bean がルックアップする JMS 接続ファクトリの JNDI 名を指定します。この要素を指定しなかった場合、config.xml の weblogic.jms.MessageDrivenBeanConnectionFactory がデフォルトになります。
次の例では、connection-factory-jndi-name 要素の構造を示します。
<message-driven-descriptor>
<connection-factory-jndi-name>weblogic.jms.MessageDrivenBean
ConnectionFactory</connection-factory-jndi-name>
</message-driven-descriptor>
トランザクションの完了時にトランザクションですべての Bean の永続ストレージを更新するには、delay-updates-until-end-of-tx 要素を true (デフォルト) に設定します。通常、この設定によって不要な更新を防ぐことができるため、パフォーマンスが向上します。ただし、データベース トランザクション内のデータベース更新の順序は保持されません。
データベースがアイソレーション レベルとして TRANSACTION_READ_UNCOMMITTED を使用している場合は、進行中のトランザクションに関する中間結果を他のデータベースのユーザに表示することもできます。この場合、delay-updates-until-end-of-tx を false に設定して、各メソッド呼び出しの完了時に Bean の永続ストレージを更新するように指定します。 詳細については、エンティティ EJB に対する ejbLoad() と ejbStore() の動作を参照してください。
注意: delay-updates-until-end-of-tx を false に設定しても、各メソッド呼び出しの後にデータベース更新が「コミットされた」状態になるわけではありません。更新はデータベースに送信されるだけです。更新は、トランザクションの完了時にのみデータベースにコミットまたはロールバックされます。
次の例では、delay-updates-until-end-of-tx スタンザを示します。
<entity-descriptor>
<persistence>
<delay-updates-until-end-of-tx>false</delay-updates-until-end-of-tx>
</persistence>
</entity-descriptor>
description 要素は、親要素を示すテキストの指定に使用します。
<description>Contains a description of parent element</description>
destination-jndi-name 要素は、WebLogic Server JNDI ツリーにデプロイされている実際の JMS キューまたはトピックにメッセージ駆動型 Bean を関連付けるために使用する JNDI 名を指定します。
message-driven-descriptorを参照してください。
method スタンザで必須。この名前は、NMTOKEN の命名規則に準拠しなければならない。 |
|
ejb-name は、WebLogic Server がアイソレーション レベルのプロパティに適用する EJB の名前を指定します。この名前は、ejb-jar ファイルのデプロイメント記述子で割り当てます。名前は、同じ ejb.jar ファイル内のエンタープライズ Bean の名前の中でユニークでなければなりません。エンタープライズ Bean のコードは名前に左右されないので、アプリケーション アセンブリ処理中に名前を変更してもエンタープライズ Bean の機能には影響しません。デプロイメント記述子の ejb-name と、デプロイヤがエンタープライズ Bean のホームに割り当てる JNDI 名との間には、組み込みの関係はありません。
methodを参照してください。
ejb-reference-description 要素は、Bean によって参照される、WebLogic Server における EJB の JNDI 名を ejb-reference 要素にマップします。
ejb-reference-description スタンザを次に示します。
<ejb-reference-description>
<ejb-ref-name>AdminBean</ejb-ref-name>
<jndi-name>payroll.AdminBean</jndi-name>
</ejb-reference-description>
ejb-ref-name 要素はリソース参照名を指定します。この要素は、EJB プロバイダが ejb-jar.xml デプロイメント ファイル内に配置する参照です。
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>AdminBean</ejb-ref-name>
<jndi-name>payroll.AdminBean</jndi-name>
</ejb-reference-description>
</reference-descriptor>
ejb-local-reference-description
ejb-local-reference-description 要素は、Bean が ejb-local ref で参照する WebLogic Server の EJB の JNDI 名をマップします。
次の例では、ejb-local-reference-description 要素を示します。
<ejb-local-reference-description>
<ejb-ref-name>AdminBean</ejb-ref-name>
<jndi-name>payroll.AdminBean</jndi-name>
</ejb-local-reference-description>
デフォルトでは、同じアプリケーション (EAR) から呼び出された EJB メソッドは引数を参照で渡します。パラメータはコピーされないので、これによってメソッド呼び出しのパフォーマンスが向上します。
enable-call-by-reference を false に設定すると、EJBE 1.1 の仕様に従って EJB メソッドへのパラメータがコピーされ (値で渡され) ます。 EJB がリモートで (同じアプリケーション以外から) 呼び出される場合は、常に値で渡す必要があります。
次の例では、EJB メソッドが値で渡すことができるようになります。
<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
...
<enable-call-by-reference>false</enable-call-by-reference>
</weblogic-enterprise-bean>
動的クエリを有効にするには、任意指定の enable-dynamic-queries 要素を true に設定する必要があります。動的クエリは、EJB 2.0 CMP Bean を使用しているときのみ使えます。
<enable-dynamic-queries>True</enable-dynamic-queries>
entity-cache 要素は、WebLogic Server 内のエンティティ EJB インスタンスのキャッシュに使用する以下のオプションを定義します。
WebLogic Server で使用可能なキャッシュ サービスについては、EJB のライフサイクルを参照してください。
<entity-descriptor>
<entity-cache>
<max-beans-in-cache>...</max-beans-in-cache>
<idle-timeout-seconds>...</idle-timeout-seconds>
<read-timeout-seconds>...<read-timeout-seconds>
<concurrency-strategy>...</concurrency-strategy>
</entity-cache>
<persistence>...</persistence>
<entity-clustering>...</entity-clustering>
</entity-descriptor>
entity-cache-name で指定する値は、weblogic-application.xml ファイルでアプリケーション レベルのエンティティ キャッシュに当てた名前と一致させること。 |
|
weblogic-enterprise-bean, |
entity-cache-name 要素は、エンティティ Bean が使用する、アプリケーション レベルのエンティティ キャッシュを参照します。アプリケーション レベルのキャッシュは、同じアプリケーション内の複数エンティティ Bean によって共有されるキャッシュです。
weblogic-application.xml ファイルの詳細については、「アプリケーション デプロイメント記述子の要素」を参照してください。
entity-cache-refを参照してください。
entity-cache-ref 要素は、同じアプリケーションの一部である複数エンティティ Bean のインスタンスをキャッシュすることのできる、アプリケーション レベルのエンティティ キャッシュを参照します。アプリケーション レベルのエンティティ キャッシュは、weblogic-application.xml ファイルで宣言されます。
concurrency-strategyを使用し、その Bean に使用させたい同時方式のタイプを定義します。同時方式はアプリケーション レベル キャッシュのキャッシュ戦略と適合していなくてはなりません。たとえば、排他的キャッシュは、Exclusive 同時方式である Bean だけをサポートします。一方、マルチバージョン キャッシュは、Database、ReadOnly、および Optimistic 同時方式をサポートします。
<entity-cache-ref>
<entity-cache-name>AllEntityCache</entity-cache-name>
<concurrency-strategy>ReadOnly</concurrency-strategy>
<estimated-bean-size>20</estimated-bean-size>
</entity-cache-ref>
entity-clustering 要素は、以下のオプションを使用して、エンティティ Bean を WebLogic クラスタ内でレプリケートする方法をしています。
次の例では、stateful-session-clustering スタンザの構造を示します。
<entity-clustering>
<home-is-clusterable>true</home-is-clusterable>
<home-load-algorithm>random</home-load-algorithm>
<home-call-router-class-name>beanRouter</home-call-router-class-name>
</entity-clustering>
entity-descriptor 要素は、エンティティ Bean に適用する以下のデプロイメント パラメータを指定します。
次の例では、entity-descriptor スタンザの構造を示します。
<entity-descriptor>
<entity-cache>...</entity-cache>
<persistence>...</persistence>
<entity-clustering>...</entity-clustering>
</entity-descriptor>
estimated-bean-size 要素は、エンティティ Bean のインスタンスについて評価された平均サイズをバイト数で指定します。各インスタンスが消費するメモリのバイト数の平均値です。
estimated-bean-size 要素は、Bean をキャッシュするのに使用する、アプリケーション レベルのキャシュがともにバイト数やメガバイト単位で指定されている場合に合わせて使用します。
エンティティ Bean インスタンスが消費する正確なバイト数が分からなくても、サイズを指定することにより、ある一時点でキャッシュを共有する Bean に対し相対的な重みを与えることができます。
たとえば、Bean A と Bean B が 1000 バイトのキャッシュを共有し、A のサイズが 10 バイト、B のサイズが 20 バイトであるとします。 その場合、キャッシュに格納できるのは、最大で、A のインスタンスで 100、B のインスタンスで 50 です。 A のインスタンスが 100 個キャッシュされた場合、B のインスタンス は 0 個、キャッシュされたことになります。
entity-cache-refを参照してください。
externally-defined 要素は、特定のセキュリティ ロールがデプロイメント記述子ではなくセキュリティ レルムで定義されていることを示します。セキュリティロールと関連するプリンシパル名のマッピングは別の場所で定義されているので、プリンシパル名はデプロイメント記述子には指定されていません。このタグは、principal-name 要素の代わりに、プレースホルダとして使用されます。
finders-load-bean は、ファインダ メソッドの呼び出しによって Bean への参照が返されてから WebLogic Server が EJB をキャッシュにロードするかどうかを指定します。この要素を true に設定した場合、Bean への参照がファインダによって返されると、WebLogic Server はすぐにその Bean をキャッシュにロードします。この要素を false に設定した場合、WebLogic Server は、最初のメソッドが呼び出されるまで Bean を自動的にロードしません。 この動作は、EJB 1.1 の仕様と一致しています。
次のエントリでは、ファインダ メソッドによって Bean への参照が返されたら、EJB が自動的に WebLogic Server キャッシュにロードされるように指定します。
<entity-descriptor>
<persistence>
<finders-load-bean>true</finders-load-bean>
</persistence>
</entity-descriptor>
global-role 要素は、特定のセキュリティ ロールがセキュリティ レルムでグローバルに定義されていることを示します。セキュリティロールと関連するプリンシパル名のマッピングは別の場所で定義されているので、プリンシパル名はデプロイメント記述子には指定されていません。このタグは、principal-name 要素の代わりに、プレースホルダとして使用されます。
home-call-router-class-name は、Bean メソッド呼び出しのルーティングに使用するカスタム クラスの名前を指定します。このクラスは weblogic.rmi.cluster.CallRouter() を実装する必要があります。指定すると、このクラスのインスタンスは各メソッド呼び出しの前に呼び出されます。ルータ クラスでは、メソッドのパラメータを基に、ルーティングするサーバを選択できます。このクラスは、サーバ名を返すか、または現在のロード アルゴリズムがサーバを選択する必要があることを示す null を返します。
entity-clusteringとstateful-session-clusteringを参照してください。
home-is-clusterable は、エンティティ Bean、ステートレス セッション Bean、またはステートフル セッション Bean のホーム インタフェースがクラスタ化されているかどうかを示す場合に使用します。
クラスタにデプロイされている EJB に関して home-is-clusterable が true の場合、各サーバ インスタンスは Bean のホーム インタフェースをクラスタの JNDI ツリーに同じ名前でバインドします。クライアントがクラスタから Bean のホーム インタフェースをリクエストすると、ルックアップを実行するサーバ インスタンスは、各サーバのホームへの参照を持つ EJBHome スタブを返します。
クライアントが create() または find() 呼び出しを発行すると、スタブは、ロード バランシング アルゴリズムに従ってレプリカ リストからサーバを選択し、そのサーバのホーム インタフェースに呼び出しをルーティングします。選択されたホーム インタフェースは呼び出しを受け取り、そのサーバ インスタンス上に Bean インスタンスを作成し、呼び出しを実行します。
entity-clusteringを参照してください。
weblogic-enterprise-bean, weblogic-enterprise-bean |
home-load-algorithm では、EJB ホームのレプリカ間でのロード バランシングに使用するアルゴリズムを指定します。この要素を定義しない場合、WebLogic Server はサーバ要素、weblogic.cluster.defaultLoadAlgorithm で指定されたアルゴリズムを使用します。
home-load-algorithm は以下のいずれかの値に定義できます。
entity-clusteringとstateful-session-clusteringを参照してください。
idempotent-method 要素は、同じメソッドを同じ引数で繰り返し呼び出したとしても、1 回呼び出したときとまったく同じ結果になるように記述される、メソッドのリストを定義します。これにより、フェールオーバ ハンドラは、失敗したサーバ上で実際に呼び出しがコンパイルされるかどうかを知らなくても、失敗した呼び出しを再試行できるようになります。あるメソッドに対し多重呼び出し不変メソッドを有効にした場合、EJB スタブは、EJB のホスト サーバに接続できるかぎり、あらゆる失敗から自動的に回復することができます。
クラスタ化を有効にする手順については、entity-clustering、stateful-session-clustering、およびstateless-clusteringを参照してください。
ステートレス セッション Bean ホームおよび読み込み専用 エンティティ Bean のメソッドは、自動的に多重呼び出し不変に設定されます。これらについては多重呼び出し不変を明示的に設定する必要はありません。
<idempotent-method>
<method>
<description>...</description>
<ejb-name>...</ejb-name>
<method-intf>...</method-intf>
<method-name>...</method-name>
<method-params>...</method-params>
</method>
</idempotent-method>
identity-assertion 要素は、EJB が ID アサーションをサポートするか、あるいは、必要とするかどうかを指定します。
iiop-security-descriptorを参照してください。
weblogic-enterprise-bean, weblogic-enterprise-bean, |
idle-timeout-seconds では、ステートフル EJB がキャッシュに保持される最長時間を定義します。この時間を過ぎると、キャッシュ内の Bean の数が max-beans-in-cache で指定した値を超えている場合、WebLogic Server では Bean インスタンスが削除されます。削除された Bean インスタンスに対してはパッシベーションが行われます。詳細については、EJB のライフサイクルを参照してください。
注意: idle-timeout-seconds は entity-cache スタンザで使用しますが、WebLogic Server 7. 0 SP01、SP02、SP03、および SP04 ではエンティティ EJB のライフサイクルの管理でその値を使用しません。それらのサービス パックでは、エンティティ Bean がいつキャッシュから削除されるかについて idle-timeout-seconds の設定は影響しません。
次のエントリでは、max-beans-in-cache の値に達し、Bean がキャッシュに 20 分保持されている場合、ステートフル セッション EJB AccountBean が削除の対象になります。
<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
<stateful-session-descriptor>
<stateful_session-cache>
<max-beans-in-cache>200</max-beans-in-cache>
<idle-timeout-seconds>1200</idle-timeout-seconds>
</stateful-session-cache>
</stateful-session-descriptor>
</weblogic-enterprise-bean>
iiop-security-descriptor 要素は、Bean レベルのセキュリティ コンフィグレーション パラメータを指定します。これらのパラメータにより、IOR に含まれる IIOP セキュリティ情報が決定します。
iiop-security-descriptor スタンザには、以下の要素を指定できます。
<iiop-security-descriptor>
<transport-requirements>...</transport-requirements>
<client-authentication>supported<client-authentication>
<identity-assertion>supported</identity-assertion>
</iiop-security-descriptor>
weblogic-enterprise-bean, |
initial-bean-in-free-pool の値を指定すると、WebLogic Server では、起動時に、すべての Bean クラスの指定した数の Bean インスタンスがフリー プールに生成されます。この方法で Bean インスタンスをフリー プールに格納しておくと、要求が来てから新しいインスタンスを生成せずに Bean に対する初期要求が可能になるため、EJB の初期応答時間が短縮されます。
poolを参照してください。
initial-context-factory 要素は、コンテナが接続ファクトリを作成するために使用する初期 contextFactory を指定します。initial-context-factory を指定しなかった場合、デフォルトは weblogic.jndi.WLInitialContextFactory になります。
次の例では、initial-context-factory 要素の構造を示します。
<message-driven-descriptor>
<initial-context-factory>weblogic.jndi.WLInitialContextFactory
</initial-context-factory>
</message-driven-descriptor>
integrity 要素は、その EJB の転送の整合性の要件を指定します。integrity 要素を使用すると、クライアントとサーバ間で、データが途中で変化することなく転送されることが保証されます。
transport-requirementsを参照してください。
invalidation-target 要素は、コンテナ管理による永続性エンティティ EJB が変更された場合に、無効化する読み込み専用エンティティ EJB を指定します。
次の例では、EJB が変更されると StockReaderEJB という EJB が無効化されるように指定します。
<invalidation-target>
<ejb-name>StockReaderEJB</ejb-name>
</invalidation-target>
is-modified-method-name では、EJB の保存時に WebLogic Server によって呼び出されるメソッドを指定します。指定したメソッドはブール値を返す必要があります。メソッドを指定しない場合、WebLogic Server では、EJB は常に変更されていると見なされて保存されます。
メソッドを指定して適切な値を設定すると、EJB 1.1 準拠の Bean、および Bean 管理の永続性を使用する Bean のパフォーマンスが向上します。ただし、メソッドの戻り値にエラーがあると、データに矛盾が発生する場合があります。 詳細については、is-modified-method-name を使用した ejbStore() の呼び出しの制限 (EJB 1.1 のみ)を参照してください。
注意: isModified() は、EJB 2.0 仕様に基づく 2.0 CMP エンティティ EJB では不要ですが、BMP および 1.1 CMP の EJB では有効です。コンテナ管理の永続性を使用して EJB 2.0 エンティティ Bean をデプロイする場合、WebLogic Server によって、変更されている EJB フィールドが自動的に検出され、そのフィールドのみが基底のデータストアに書き込まれます。
次の例では、EJB が変更されると semidivine という EJB メソッドが WebLogic Server に通知するように指定します。
<entity-descriptor>
<persistence>
<is-modified-method-name>semidivine</is-modified-method-name>
</persistence>
</entity-descriptor>
TransactionSerializable | TransactionReadCommitted | TransactionReadUncommitted | TransactionRepeatableRead | TransactionReadCommittedForUpdate | TransactionReadCommittedForUpdateNoWait |
|
transaction-isolation 要素は、EJB に対してメソッド レベル トランザクションのアイソレーション設定を定義します。 指定できる値は以下のとおりです。
次の追加の値は Oracle データベース、およびコンテナ管理による永続性 (CMP) EJB でのみサポートされます。
この値では、アイソレーション レベルが TRANSACTION_READ_COMMITTED に設定されます。トランザクションの間、メソッドで実行されるすべての SQL SELECT 文は、FOR UPDATE NO WAIT が付加されて実行されます。 その結果、選択された行は更新のためにロックされます。
TRANSACTION_READ_COMMITTED_FOR_UPDATE 設定とは異なり、TRANSACTION_READ_COMMITTED_FOR_UPDATE_NO_WAIT では、要求されたロックを即座に行えない場合に Oracle DBMS は待機しません。つまり、影響される SELECT クエリは失敗し、コンテナによって例外が送出されます。
Oracle 固有の isolation-level 値の背景情報については、コンテナ管理トランザクションのアイソレーション レベルの設定を参照してください。
さまざまなアイソレーション レベルのサポートの詳細については、各データベースのマニュアルを参照してください。
transaction-isolationを参照してください。
jms-polling-interval-seconds 要素は、JMS 送り先に再接続しにいく間隔の秒数を指定します。各メッセージ駆動型 Bean は、関連付けられているJMS 送り先にリスンします。JMS 送り先が別の WebLogic Server インスタンスまたは外部 JMS プロバイダに配置されている場合には、 JMS 送り先にアクセスできなくなることもあります。この場合、EJB コンテナは自動的に JMS サーバに再接続しにいきます。JMS サーバが再び起動した時点で、メッセージ駆動型 Bean は再びメッセージを受信できるようになります。
次のエントリでは、メッセージ駆動型 Bean の JMS ポーリング間隔を指定しています。
<jms-polling-interval-seconds>5</jms-polling-interval seconds>
jms-client-id は、JMS コンシューマに関連付ける ID を指定します。恒久サブスクリプションを持つメッセージ駆動型 Bean では、関連付けられたクライアント ID が必要になります。個別の接続ファクトリを使用する場合には、その接続ファクトリ上にクライアント ID を設定できます。この場合、メッセージ駆動型 Bean はこのクライアント ID を使用します。
関連する接続ファクトリにクライアント ID がない場合、または、デフォルトの接続ファクトリを使用する場合には、メッセージ駆動型 Bean は jms-cliend-id の値をそれのクライアント ID として使用します。
次のエントリでは、JMS コンシューマに関連付ける ID を指定しています。
<jms-client-id>MyClientID</jms-client-id>
weblogic-enterprise-bean weblogic-enterprise-bean |
jndi-name は、WebLogic Server で使用可能な実際の EJB、リソース、または参照の JNDI 名を指定します。
resource-descriptionとejb-reference-descriptionを参照してください。
local-jndi-name 要素は、Bean のローカル ホームの jndi-name を指定します。Bean がリモート ホームとローカル ホームを持つ場合は、それぞれのホームに 1 つずつの JNDI 名を指定する必要があります。
次の例では、local-jndi-name 要素の構造を示します。
<local-jndi-name>weblogic.jndi.WLInitialContext
</local-jndi-name>
weblogic-enterprise-bean, weblogic-enterprise-bean |
max-beans-in-cache 要素は、メモリに保持可能なこのクラスのオブジェクトの最大数を指定します。 max-bean-in-cache の値に達すると、WebLogic Server では、最近クライアントに使用されていない EJB の一部に対してパッシベーションが行われます。また、EJB の同時方式で説明されているように、max-beans-in-cache の値は、EJB を WebLogic Server のキャッシュからいつ削除するかにも影響を与えます。
次の例では、WebLogic Server が AccountBean クラスのインスタンスを最大で 200 個キャッシュできるようにします。
<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
<entity-descriptor>
<entity-cache>
<max-beans-in-cache>200</max-beans-in-cache>
</entity-cache>
</entity-descriptor>
</weblogic-enterprise-bean>
weblogic-enterprise-bean, |
WebLogic Server は、すべてのエンティティ Bean、ステートレス セッション Bean、およびメッセージ駆動型 Bean クラスに対して EJB のフリー プールを保持します。max-beans-in-free-pool 要素は、このフリー プールのサイズを定義します。詳細については、ステートレス セッション EJB のライフサイクルとメッセージ駆動型 Bean とステートレス セッション EJB との違いを参照してください。
poolを参照してください。
message-driven-descriptor 要素は、メッセージ駆動型 Bean を WebLogic Server の JMS 送り先に関連付けます。この要素は、以下のデプロイメント パラメータを指定します。
次の例では、message-driven-descriptor スタンザの構造を示します。
<message-driven-descriptor>
<destination-jndi-name>...</destination-jndi-name>
</message-driven-descriptor>
method 要素は、エンタープライズ Bean のホームまたはリモート インタフェースのメソッドあるいはメソッドのセットを定義します。
<method>
<description>...</description>
<ejb-name>...</ejb-name>
<method-intf>...</method-intf>
<method-name>...</method-name>
<method-params>...</method-params>
</method>
method-intf では、WebLogic Server がアイソレーション レベル プロパティを適用する EJB インタフェースを指定します (メソッドが複数のインタフェースで同じシグネチャを持つ場合)。
methodを参照してください。
method スタンザで必須。 |
|
method-name は、WebLogic Server がアイソレーション レベルのプロパティを適用する個々の EJB メソッドの名前を指定します。アスタリスク (*) を使用して EJB のホームおよびリモート インタフェースの全メソッドを指定します。
method-name を指定すると、そのメソッドが指定した ejb-name で使用可能になります。
methodを参照してください。
method-params で必須。 |
|
method-param 要素には、Java タイプのメソッド パラメータの完全修飾名を指定します。
method-paramsを参照してください。
method-params スタンザには、各メソッド パラメータの Java タイプ名を定義する 1 つまたは複数の要素があります。
method-params スタンザには、次のように 1 つまたは複数の method-param 要素が含まれます。
<method-params>
<method-param>java.lang.String</method-param>
...
</method-params>
persistence 要素は、WebLogic Server のエンティティ EJB に対する永続性タイプ、トランザクション コミット動作、ejbLoad() 動作、および ejbStore() 動作を決定するプロパティを定義します。
次の例では、persistence 要素の構造を指定します。
<entity-descriptor>
<persistence>
<is-modified-method-name>...</is-modified-
method-name>
<delay-updates-until-end-of-tx>
</delay-updates-until-end-of-tx>
<finders-load-beand>...</finders-load-bean>
<db-is-shared>false</db-is-shared>
<persistence-use>...</persistence-use>
</persistence>
</entity-descriptor>
persistence-use 要素は、この Bean に使用する永続性タイプの識別子を格納します。
次の例では、persistence-use スタンザの例を示します。
<persistence-use>
<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-use>
WebLogic Server がパッシベーションされたステートフル セッション Bean インスタンスの状態を格納するファイル システム ディレクトリを指定します。 詳細については、4-12 ページの「パッシベーションされた Bean の永続ストア ディレクトリの指定」を参照してください。
<stateful-session-descriptor>
<stateful-session-cache>...</stateful-session-cache>
<allow-concurrent-calls>...</allow-concurrent-calls>
<persistent-store-dir>MyPersistenceDirr</persistent-store-dir>
<stateful-session-clustering>...</stateful-session-clustering>
<allow-remove-during-transaction>
</stateful-session-descriptor>
pool 要素は、EJB 用の WebLogic Server フリー プールの動作をコンフィグレーションします。
<stateless-session-descriptor>
<pool>
<max-beans-in-free-pool>500</max-beans-in-free-pool>
<initial-beans-in-free-pool>250</initial-beans-in-free-pool>
</pool>
</stateless-session-descriptor>
security-role-assignment スタンザには、最低 1 つの principal-name が必須。各 role-name に対しては、複数の principal-name を定義できる。 |
|
principal-name は、指定した role-name に適用される実際の WebLogic Server プリンシパルの名前を指定します。
security-role-assignmentを参照してください。
provider-url 要素は、InitialContext が使用する URL プロバイダを指定します。通常、指定するのはホスト : ポートで、initial-context-factory および connection-factory-jndi-name と組み合わせて使用します。
次の例では、provider-url 要素の構造を指定します。
<message-driven-descriptor>
<provider-url>WeblogicURL:Port</provider-url>
</message-driven-descriptor>
read-timeout-seconds 要素では、Read-Only エンティティ Bean での各 ejbLoad() 呼び出しの間隔を秒数で指定します。 0 に設定すると、WebLogic Server では、その Bean がキャッシュされた場合にのみ、ejbLoad() が呼び出されます。
次の例では、インスタンスが最初にキャッシュされた場合にのみ WebLogic Server が AccountBean クラスのインスタンスに対して ejbLoad() を呼び出します。
<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
<entity-descriptor>
<entity-cache>
<read-timeout-seconds>0</read-timeout-seconds>
</entity-cache>
</entity-descriptor>
</weblogic-enterprise-bean>
reference-descriptor 要素では、ejb-jar.xml ファイル内の参照が、WebLogic Server で実際に使用可能なリソース ファクトリと EJB の JNDI 名にマップされます。
reference-descriptor スタンザには、リソース ファクトリ参照および EJB 参照を定義するために 1 つまたは複数のスタンザが追加されます。次の例に、これらの要素の構造を示します。
<reference-descriptor>
<resource-description>
...
</resource-description>
<ejb-reference-description>
...
</ejb-reference-description>
</reference-descriptor>
現在、この要素は WebLogic Server でサポートされていません。
replication-type 要素は、クラスタ内の WebLogic Server インスタンスのステートフル セッション EJB の状態を WebLogic Server がレプリケートするかどうかを指定します。InMemory を指定した場合、EJB の状態はレプリケートされます。None を指定した場合、状態はレプリケートされません。
詳細については、ステートフル セッション EJB のインメモリ レプリケーションを参照してください。
stateful-session-clusteringを参照してください。
res-env-ref-name はリソース環境参照名を指定します。
resource-descriptionを参照してください。
res-ref-name は resourcefactory 参照名を指定します。これは、EJB プロバイダによって ejb-jar.xml デプロイメント記述子ファイル内に記載される参照です。
resource-descriptionを参照してください。
resource-description 要素は、ejb-jar.xml で定義されたリソース参照を、WebLogic Server で使用可能な実際のリソースの JNDI 名にマップします。
resource-description スタンザには、以下のように要素を追加できます。
<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-env-description 要素は、ejb-jar.xml で定義されたリソース環境参照を、WebLogic Server で使用可能な実際のリソースの JNDI 名にマップします。
resource-env-description スタンザには、以下のように要素を追加できます。
<reference-descriptor>
<resource-env-description>
<res-env-ref-name>. . .</res-env-ref-name>
<jndi-name>...</jndi-name>
<reference-env-description>
</reference-descriptor>
role-name 要素は、EJB プロバイダが ejb-jar.xml デプロイメント ファイルに指定したアプリケーションのロール名を示します。スタンザの次の principal-name 要素で、WebLogic Server プリンシパルを、指定した role-name にマップします。
security-role-assignmentを参照してください。
security-permission 要素は、J2EE Sandbox と関連するセキュリティ パーミッションを指定します。
詳細については、Sun によるセキュリティ パーミッション仕様の実装を参照してください。
http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax
security-permission スタンザには、以下の要素を 1 つまたは複数、指定できます。
<security-permission> </security-permission>
security-permission-spec 要素は、J2EE sandbox と関連するセキュリティ パーミッションを指定します。
詳細については、Sun によるセキュリティ パーミッション仕様の実装を参照してください。
http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax
「java.vm.version」に「read」パーミッションを付与して、上書きされないようにするには、次の手順に従います。
security-role-assignment 要素は、ejb-jar.xml ファイル内のアプリケーション ロールを、WebLogic Server で使用可能なセキュリティ プリンシパル名にマップします。
security-role-assignment スタンザには、以下の要素を 1 つまたは複数、指定できます。
<security-role-assignment>
<role-name>PayrollAdmin</role-name>
<principal-name>Tanya</principal-name>
<principal-name>system</principal-name>
...
</security-role-assignment>
session-timeout-seconds 要素は、パッシベーションされたステートフル セッション Bean がディスクから削除されるまで EJB コンテナが待機する時間を指定します。
idle-timeout-seconds 要素は、ステートフル セッション Bean でパッシベーションが行われるまで、つまりキャッシュから削除されてディスクに書き込まれるまで EJB コンテナが待機する時間を指定します。
以前のリリースでは、EJB コンテナは、パッシベーションされた EJB をディスクから削除するまでの待機時間を指定するためにも idle-timeout-seconds を使用していました。session-timeout-seconds の追加により、ステートフル セッション Bean がキャッシュ内に留まる時間と、それらがディスクに留まる時間を別々の要素で指定できます。
次の例では、session-timeout-seconds 要素の指定方法を示します。
<session-timeout-seconds>3600</session-timeout-seconds>
stateful-session-cache 要素は、WebLogic Server 内のステートフル セッション EJB インスタンスのキャッシュに使用する以下のオプションを定義します。
WebLogic Server で使用可能なキャッシュ サービスについては、EJB のライフサイクルを参照してください。
次の例では、stateful-session-cache 要素の指定方法を示します。
<stateful-session-cache>
<max-beans-in-cache>...</max-beans-in-cache>
<idle-timeout-seconds>...</idle-timeout-seconds>
<cache-type>...</cache-type>
</stateful-session-cache>
stateful-session-clustering スタンザ要素では、クラスタ内のステートフル セッション EJB インスタンスのクラスタ化動作を指定します。
次の例では、stateful-session-clustering スタンザの構造を示します。
<stateful-session-clustering>
<home-is-clusterable>true</home-is-clusterable>
<home-load-algorithm>random</home-load-algorithm>
<home-call-router-class-name>beanRouter</home-call-router-class-name>
<replication-type>InMemory</replication-type>
</stateful-session-clustering>
stateful-session-descriptor 要素では、ステートフル セッション EJB のデプロイメント動作を指定します。
次の例では、stateful-session-descriptor スタンザの構造を示します。
<stateful-session-descriptor>
<stateful-session-cache>...</stateful-session-cache>
<allow-concurrent-calls>...</allow-concurrent-calls>
<persistent-store-dir>...</persistent-store-dir>
<stateful-session-clustering>...</stateful-session-clustering>
<allow-remove-during-transaction>...
</allow-remove-during-transaction>
</stateful-session-descriptor>
stateless-bean-call-router-class-name
stateless-bean-call-router-class-name 要素は、Bean メソッド呼び出しのルーティングに使用するカスタム クラスの名前を指定します。このクラスは weblogic.rmi.cluster.CallRouter() を実装する必要があります。指定すると、このクラスのインスタンスは各メソッド呼び出しの前に呼び出されます。ルータ クラスでは、メソッドのパラメータを基に、ルーティングするサーバを選択できます。このクラスは、サーバ名を返すか、または現在のロード アルゴリズムがサーバを選択する必要があることを示す null を返します。
stateless-clusteringを参照してください。
stateless-bean-is-clusterable は、ステートレス セッション Bean の EJBObject インタフェースがクラスタ化されているかどうかを示す場合に使用します。クラスタ化されている EJBObject は、ロード バランシングとフェイルオーバをサポートしています。
stateless-bean-is-clusterable が true の場合、クラスタ化されているステートレス セッション Bean のホーム インタフェースが Bean インスタンスを作成すると、クラスタ内のすべてのサーバを示す EJBObject スタブがクライアントに返されます。ステートレスという Bean の特性のため、どのインスタンスもすべてのクライアントにサービスできます。
stateless-clusteringを参照してください。
stateless-bean-load-algorithm は、EJB ホームのレプリカ間でのロード バランシングに使用するアルゴリズムを指定します。このプロパティを定義しない場合、WebLogic Server はサーバ プロパティ weblogic.cluster.defaultLoadAlgorithm で指定されたアルゴリズムを使用します。
stateless-bean-load-algorithm を以下のいずれかの値で定義できます。
stateless-clusteringを参照してください。
stateless-bean-methods-are-idempotent
非推奨 : stateless-bean-methods-are-idempoten 要素は現在、非推奨となっており、WebLogic の将来のバージョンでは削除される予定です。
代わりに、idempotent-methods 要素を使用してください。
stateless-clusteringを参照してください。
stateless-clustering 要素は、WebLogic Server がクラスタ内のステートレス セッション EJB インスタンスをレプリケートする方法を決めるオプションを指定します。
次の例では、stateless-clustering スタンザの構造を示します。
<stateless-clustering>
<home-is-clusterable>.../home-is-clusterable>
<home-load-algorithm>...</home-load-algorithm>
<home-call-router-class-name>...</home-call-router-class-name>
<use-serverside-stubs>...</use-serverside-stubs>
<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>
</stateless-clustering>
stateless-session-descriptor 要素は、WebLogic Server のステートレス セッション EJB に対するキャッシュ、クラスタ化、および永続性などのデプロイメント動作を定義します。
次の例では、stateless-session-descriptor スタンザの構造を示します。
<stateless-session-descriptor>
<pool>...</pool>
<stateless-clustering>...</stateless-clustering>
</stateless-session-descriptor>
transaction-descriptor 要素は、WebLogic Server のトランザクション動作を定義するオプションを指定します。 現在、このスタンザには trans-timeout-seconds という要素のみがあります。
次の例では、transaction-descriptor スタンザの構造を示します。
<transaction-descriptor>
<trans-timeout-seconds>20</trans-timeout-seconds>
</transaction-descriptor>
Etransaction-isolation 要素は、EJB に対してメソッド レベル トランザクションのアイソレーション設定を指定します。
transaction-isolation スタンザには、以下の要素を指定できます。
<transaction-isolation>
<isolation-level>...</isolation-level>
<method>
<description>...</description>
<ejb-name>...</ejb-name>
<method-intf>...</method-intf>
<method-name>...</method-name>
<method-params>...</method-params>
</method>
</transaction-isolation>
詳細については、isolation-levelを参照してください。
transport-requirements 要素は、EJB の転送の要件を指定します。
<iiop-security-descriptor>
<transport-requirements>
<confidentiality>supported</confidentiality>
<integrity>supported</integrity>
<client-cert-authorization>suppoted
</client-cert-authentication>
</transport-requirements>
</iiop-security-descriptor>
transport-requirements スタンザには、次の要素を指定できます。
<iiop-security-descriptor>
<transport-requirements>
<confidentiality>supported</confidentiality>
<integrity>supported</integrity>
<client-cert-authorization>suppoted
</client-cert-authentication>
</transport-requirements>
</iiop-security-descriptor>
trans-timeout-seconds 要素は、EJB のコンテナで初期化されたトランザクションの最長継続時間を指定します。トランザクションの継続時間が trans-timeout-seconds の値を超えると、WebLogic Server によってトランザクションがロールバックされます。
transaction-descriptorを参照してください。
有効な文字列 |
|
weblogic-enterprise-bean, |
type-identifier 要素には、エンティティ EJB の永続性タイプを示すテキストを指定します。WebLogic Server RDBMS ベースの永続性では、WebLogic_CMP_RDBMS という識別子を使用します。別の永続性ベンダを使用している場合の正しい type-identifier についてはベンダのマニュアルを参照してください。
WebLogic Server RDBMS ベースの永続性に関する詳細な persistence-use の定義の例については、persistence-useを参照してください。
weblogic-enterprise-bean, |
type-storage 要素では、この永続性タイプのデータを格納するファイルの絶対パスを定義します。パスは、EJB のデプロイメント JAR ファイルまたはデプロイメント ディレクトリの最上位を基準にしたファイルの場所を指定する必要があります。
WebLogic Server RDBMS ベースの永続性では通常、Bean の永続性データを格納するのに weblogic-cmp-rdbms-jar.xml という XML ファイルを使用します。このファイルは、JAR ファイルの META-INF サブディレクトリにあります。
WebLogic Server RDBMS ベースの永続性に関する詳細な persistence-use の定義の例については、persistence-useを参照してください。
たとえば、WebLogic 2.0 CMP の永続性の場合は次の値を使用します。
WebLogic 1.1 CMP の永続性の場合は、次の値を使用します。
この要素は、同じ永続性タイプの複数のバージョンがインストールされている場合に必須です。
注意: WebLogic Server の RDBMS ベースの永続性を使用する場合、指定したバージョンは、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-use の定義の例については、persistence-useを参照してください。
weblogic-ejb-jar は、EJB デプロイメント記述子の weblogic コンポーネントのルート要素です。
weblogic-enterprise-bean 要素には、WebLogic Server 内で利用可能な Bean に関するデプロイメント情報が含まれます。
5.1 の weblogic-ejb-jar.xml デプロイメント記述子ファイルの構造
WebLogic Server 5.1 の weblogic-ejb-jar.xml ファイルは、EJB 1.1 Bean で使用する EJB 文書型定義 (DTD) を定義します。これらのデプロイメント記述子要素は WebLogic 固有です。WebLogic Server 5.1 の weblogic-ejb-jar.xml の最上位要素は次のとおりです。
5.1 の weblogic-ejb-jar.xml デプロイメント記述子要素
以下の節では、WebLogic Server 5.1 の weblogic-ejb-jar.xml デプロイメント記述子の要素について説明します。
caching-descriptor スタンザは、WebLogic Server キャッシュ内の EJB の数、および EJB に対してパッシベーションが行われるまたは EJB がプールされるまでの時間の長さに影響します。このスタンザは、各要素だけでなく、スタンザ全体が省略可能です。 要素が定義されていない場合、WebLogic Server ではデフォルト値が使用されます。
以下は、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 のライフサイクルを参照してください。
注意: この要素は、ステートレス セッション EJB に対してのみ有効です。
initial-bean-in-free-pool の値を指定すると、WebLogic Server では、起動時に、指定した数の Bean インスタンスがフリー プールに生成されます。この方法で Bean インスタンスをフリー プールに格納しておくと、要求が来てから新しいインスタンスを生成せずに Bean に対する初期要求が可能になるため、EJB の初期応答時間が短縮されます。
initial-bean-in-free-pool が定義されていない場合のデフォルト値は 0 です。
注意: この要素は、ステートフル セッション EJB に対してのみ有効です。
この要素では、メモリの許容範囲内で、このクラスのオブジェクトの最大数を指定します。 max-bean-in-cache の値に達すると、WebLogic Server では、最近クライアントに使用されていない EJB の一部に対してパッシベーションが行われます。また、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 インスタンスが削除されます。 詳細については、EJB のライフサイクルを参照してください。
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>
<persistence-use>
<type-identifier>...</type-identifier>
<type-version>...</type-version>
<type-storage>...</type-storage>
</persistence-use>
<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 は常に変更されていると見なされて保存されます。
メソッドを指定して適切な値を設定すると、パフォーマンスが向上します。ただし、メソッドの戻り値にエラーがあると、データに矛盾が発生する場合があります。 詳細については、is-modified-method-name を使用した ejbStore() の呼び出しの制限 (EJB 1.1 のみ)を参照してください。
トランザクションの完了時にトランザクションですべての Bean の永続ストレージを更新するには、このプロパティを true (デフォルト) に設定します。通常、これによって不要な更新を防ぐことができるため、パフォーマンスが向上します。ただし、データベース トランザクション内のデータベース更新の順序は保持されません。
データベースがアイソレーション レベルとして TRANSACTION_READ_UNCOMMITTED を使用している場合は、進行中のトランザクションに関する中間結果を他のデータベースのユーザに表示することもできます。この場合、delay-updates-until-end-of-tx を false に設定して、各メソッド呼び出しの完了時に Bean の永続ストレージを更新するように指定します。 詳細については、エンティティ EJB に対する ejbLoad() と ejbStore() の動作を参照してください。
注意: delay-updates-until-end-of-tx を false に設定しても、各メソッド呼び出しの後にデータベース更新が「コミットされた」状態になるわけではありません。更新はデータベースに送信されるだけです。更新は、トランザクションの完了時にのみデータベースにコミットまたはロールバックされます。
persistence-use では、EJB で使用可能な永続性サービスを定義します。複数の永続性サービスを持つ EJB をテストするために、weblogic-ejb-jar.xml で複数の persistence-use エントリを定義できます。
persistence-use には、サービスのプロパティを定義する要素が含まれます。
注意: 指定したバージョンは、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-use スタンザの例です。
<persistence-use>
<type-identifier>WebLogic_CMP_RDBMS</type-identifier>
<type-version>5.1.0</type-version>
<type-storage>META-INF¥weblogic-cmp-rdbms-jar.xml</type-storage>
</persistence-use>
db-is-shared 要素はエンティティ Bean に対してのみ有効です。true (デフォルト値) に設定すると、WebLogic Server では、EJB データがトランザクション間で変更されると見なされ、各トランザクションの開始時にデータが再ロードされます。false に設定すると、WebLogic Server では、永続ストレージの EJB データに排他的にアクセスすると見なされます。 詳細については、トランザクション間のキャッシュを使用した ejbStore() の呼び出しの制限を参照してください。
stateful-session-persistent-store-dir
stateful-session-persistent-store-dir 要素では、WebLogic Server で、パッシベーションが行われたステートフル セッション Bean インスタンスの状態が格納されるファイル システム ディレクトリを指定します。
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.cluster.CallRouter() を実装する必要があります。指定すると、このクラスのインスタンスは各メソッド呼び出しの前に呼び出されます。ルータ クラスでは、メソッドのパラメータを基に、ルーティングするサーバを選択できます。このクラスは、サーバ名を返すか、または現在のロード アルゴリズムがサーバを選択する必要があることを示す null を返します。
stateless-bean-is-clusterable は、ステートレス セッション Bean の EJBObject インタフェースがクラスタ化されているかどうかを示す場合に使用します。 クラスタ化されている EJBObject は、ロード バランシングとフェイルオーバをサポートしています。
stateless-bean-is-clusterable が true の場合、クラスタ化されているステートレス セッション Bean のホーム インタフェースが Bean インスタンスを作成すると、クラスタ内のすべてのサーバを示す EJBObject スタブがクライアントに返されます。 ステートレスという Bean の特性のため、どのインスタンスもすべてのクライアントにサービスできます。
このプロパティは home-load-algorithm に似ていますが、ステートレス セッション EJB にのみ適用できます。
stateless-bean-call-router-class-name
このプロパティは home-call-router-class-name に似ていますが、ステートレス セッション EJB にのみ適用できます。
stateless-bean-methods-are-idempotent
この要素は、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 に値を指定しなかった場合、コンテナで初期化されたトランザクションはデフォルトで 30 秒後にタイムアウトになります。
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 を定義します。
以下の要素で、各 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 要素で構成されます。 次に例を示します。
<isolation-level>TransactionSerializable</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 内の各要素について説明します。
TransactionSerializable | TransactionReadCommitted | TransactionReadUncommitted | TransactionRepeatableRead | TransactionReadCommittedForUpdate | TransactionReadCommittedForUpdateNoWait |
|
transaction-isolation 要素は、EJB に対してメソッド レベル トランザクションのアイソレーション設定を定義します。 指定できる値は以下のとおりです。
次の追加の値は Oracle データベース、およびコンテナ管理による永続性 (CMP) EJB でのみサポートされます。
この値では、アイソレーション レベルが TRANSACTION_READ_COMMITTED に設定されます。トランザクションの間、メソッドで実行されるすべての SQL SELECT 文は、FOR UPDATE NO WAIT が付加されて実行されます。 その結果、選択された行は更新のためにロックされます。
TRANSACTION_READ_COMMITTED_FOR_UPDATE 設定とは異なり、TRANSACTION_READ_COMMITTED_FOR_UPDATE_NO_WAIT では、要求されたロックを即座に行えない場合に Oracle DBMS は待機しません。つまり、影響される SELECT クエリは失敗し、コンテナによって例外が送出されます。
Oracle 固有の isolation-level 値の背景情報については、コンテナ管理トランザクションのアイソレーション レベルの設定を参照してください。
異なるアイソレーション レベルの関係と各アイソレーション レベルのサポートの詳細については、各データベースのマニュアルを参照してください。
transaction-isolationを参照してください。
method スタンザは、アイソレーション レベルを適用する EJB メソッドを定義します。 method では、以下の要素を使用してメソッドの範囲を定義します。
たとえば、次の 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 つまたは複数、指定できます。
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |