10g（10.1.3.1.0）
B31852-03
 目次 |
 索引 |
| Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド 10g（10.1.3.1.0） B31852-03 |
|
この章では、EJBアプリケーションについて構成できる次のようなOC4Jアプリケーション・クラスタリング・オプションについて説明します。
詳細は、「OC4J EJBアプリケーション・クラスタリング・サービスについて」を参照してください。
EJB 3.0またはEJB 2.1ステートフル・セッションBeanのEJBアプリケーション・クラスタリングを構成する一般的な手順は、次のとおりです。
詳細は、次を参照してください。
レプリケーション・ポリシーを構成するには、表24-1にリストする1つ以上の適切なデプロイメント・ディスクリプタ・ファイルに<replication-policy>要素を追加します。OC4Jがグローバルに適用する1つのレプリケーション・ポリシーを指定するか、WebコンポーネントとEJBコンポーネントの両方またはEJBコンポーネントのみに対してファイングレインなレプリケーション・ポリシーをアプリケーション・レベルで指定できます。
trigger属性を次のいずれかに構成します。
inherited: ステートフル・セッションBeanは、アプリケーション・レベルで構成する状態レプリケーション・トリガー設定を使用します。これはデフォルト値です。
onRequestEnd: ステートフル・セッションBeanの状態は、各EJBメソッドのコールの終了時に、クラスタ内の（マルチキャスト・アドレス、ポートが同一の）すべてのホストにレプリケートされます。ノードの電源が切断された場合でも、状態はすでにレプリケートされています。この方法は、状態の送信回数が多くなるため、JVM終了レプリケーション・モードよりパフォーマンスが低下します。ただし、信頼性の保証は高くなります。
onShutdown: ステートフル・セッションBeanは、JVMが終了すると、クラスタ内の（マルチキャスト・アドレス、ポートが同一の）別のホストの1つにのみレプリケートされます。このオプションは、状態のレプリケートが1回のみであるため、最高のパフォーマンスを得ることができます。ただし、次の理由により、信頼性は高くありません。
none: このステートフル・セッションBeanのクラスタリングが無効化されます。
Application Server Controlを使用して
注意
trigger属性をinheritedまたはnoneに構成することはできません。これらの値を設定するには、デプロイXMLを手動で編集します。詳細は、「Oracle Enterprise Manager 10g Application Server Controlの使用方法」を参照してください。
ステートフル・セッションBeanの場合、scope属性は常にallAttributesに設定されます。
詳細は、「状態レプリケーション」を参照してください。
| 有効範囲 | コンポーネント | デプロイXMLファイル | 参照先 |
|---|---|---|---|
|
グローバル |
WebおよびEJB |
|
『Oracle Application Server高可用性ガイド』のOracle Application Serverクラスタ（OC4J）でのステートフル・セッションEJBの状態レプリケーションに関する項 |
|
アプリケーションレベル |
WebおよびEJB |
|
『Oracle Application Server高可用性ガイド』のOracle Application Serverクラスタ（OC4J）でのステートフル・セッションEJBの状態レプリケーションに関する項 |
|
アプリケーションレベル |
EJB |
|
「EJBコンポーネントのorion-ejb-jar.xmlファイルのアプリケーションレベル・レプリケーション・ポリシーのオーバーライド」 |
orion-ejb-jar.xmlファイルをステートフル・セッションBeanの状態レプリケーション・ポリシー（例24-1を参照）で構成する場合、各Beanでは、Webコンポーネント・レプリケーション・タイプに関係なく、異なるタイプのレプリケーションを使用できます。
<orion-ejb-jar>
...
<session-deployment
name="AirlinePOEndpointBean"
max-tx-retries="0"
location="AirlinePOEndpointBean"
persistence-filename="AirlinePOEndpointBean">
...
<replication-policy
trigger="onRequestEnd"
scope="allAttributes"
/>
...
</session-deployment>
...
</orion-ejb-jar>
ロード・バランシングのためにOC4Jインスタンスの静的検出を使用するには、次のようにします。
詳細は、次を参照してください。
例24-2に、ロード・バランシングを使用するために、3つのOC4Jノード（それぞれホスト名がs1、s2およびs3で、ポートが23791、23792および23793）があるクライアント・コンテナを提供するURL定義を示します。
java.naming.factory.initial= oracle.j2ee.rmi.RMIInitialContextFactory
java.naming.provider.url=ormi://s1:23791/ejbs, ormi://s2:23792/ejbs, ormi://s3:23793/ejbs;
java.naming.security.principal=admin
java.naming.security.credentials=welcome
DNSロード・バランシングを使用するには、次のようにします。
IPアドレスでOC4Jの実行を識別します。ポート番号はRMIポート番号です。
DNSサーバーでルックアップが発生するたびに、DNSサーバーは、マップされているIPアドレスの1つを返します。
詳細は、次を参照してください。
例24-3では、初期コンテキスト・ファクトリはRMIInitialContextFactory（ただし、DNSロード・バランシングの任意の初期コンテキスト・ファクトリを使用できる）、myserverはサーバーのリスト用にDNSサーバーに設定されているホスト名、RMIポートはデフォルトのポートです。
java.naming.factory.initial= oracle.j2ee.rmi.RMIInitialContextFactory
java.naming.provider.url=ormi://myserver/applname
java.naming.security.principal=admin
java.naming.security.credentials=welcome
EJB 3.0とEJB 2.1の両方、およびすべてのロード・バランシング計画（レプリケーションベース、静的検出またはDNS）において、クライアントのリクエストをクラスタ内のOC4Jインスタンス間でロード・バランシングする方法を構成できます（「システム・プロパティの使用方法」を参照）。
詳細は、「ロード・バランシング」を参照してください。
このリリースでは、oracle.j2ee.rmi.loadBalanceシステム・プロパティを構成して、アプリケーション・クラスタ内でのロード・バランシングを指定します。
このシステム・プロパティの値は次のいずれかになります。
client: クライアントは、変換全体の最初のルックアップで最初に選択されたOC4Jプロセスと対話します（デフォルト）。
context: クライアントは、別のコンテキストが使用されている場合に新しいサーバーに移動します（非推奨のdedicated.rmicontextと同様）。
lookup: クライアントは、リクエストのたびに新しい（ランダムに選択された）サーバーに移動します。
このシステム・プロパティは、OC4Jのコマンドラインで-D引数として、または環境参照（「環境変数への環境参照の構成」を参照）として構成できます。このシステム・プロパティは、すべてのクライアントに適用されます。
|
 Copyright © 2002, 2008 Oracle Corporation. All Rights Reserved. |
|