| Oracle Fusion Middleware Oracle TopLink開発者ガイド 11gリリース1（11.1.1） B56246-01 |
|
 戻る |
 次へ |
この章では、TopLinkのコーディネート・キャッシュの構成方法について説明します。
この章の内容は次のとおりです。
詳細は、102.3項「キャッシュ・コーディネーション」を参照してください。
表103-1は、複数のTopLinkコーディネート・キャッシュ・タイプに共通の構成可能オプションを示します。ここで説明する構成可能オプション以外にも、表103-2に示すように、特定のコーディネート・キャッシュ・タイプについて説明しているオプションも構成する必要があります。
表103-2 共通コーディネート・キャッシュ・オプション
| 構成オプション | Oracle JDeveloper |
TopLink Workbench |
Java |
|---|---|---|---|
|
ディスクリプタ・レベルでのキャッシュ・コーディネーション変更伝播（119.15項「ディスクリプタ・レベルでのキャッシュ・コーディネーション変更伝播の構成」を参照） |
|
 |
|
|
同期変更伝播モード（103.2項「同期変更伝播モードの構成」を参照） |
|
|
|
|
サービス・チャネル（103.3項「サービス・チャネルの構成」を参照） |
|
|
|
|
マルチキャスト・グループ・アドレス（103.4項「マルチキャスト・グループ・アドレスの構成」を参照） |
|
|
|
|
マルチキャスト・ポート（103.5項「マルチキャスト・ポートの構成」を参照） |
|
|
|
|
ネーミング・サービス・タイプ（103.6項「ネーミング・サービス・タイプの構成」を参照） |
|
|
|
|
通知の遅延（103.9項「通知の遅延の構成」を参照） |
|
|
|
|
接続処理（103.10項「接続処理の構成」を参照） |
|
|
|
|
コンテキスト・プロパティ（103.11項「コンテキスト・プロパティの構成」を参照） |
|
|
|
|
パケットの有効時間（103.12項「パケットの有効時間の構成」を参照） |
|
|
|
コーディネート・キャッシュでオブジェクト変更の伝播を非同期と同期のどちらで行うかを構成できます。
表103-3では、どのコーディネート・キャッシュが伝播モードの構成をサポートしているかを示します。
表103-3 コーディネート・キャッシュでの伝播モードの構成のサポート
| コーディネート・キャッシュ | Oracle JDeveloperの使用方法 | TopLink Workbenchを使用した同期変更伝播モードの構成方法 |
Javaを使用した同期変更伝播モードの構成方法 |
|---|---|---|---|
|
JMSコーディネート・キャッシュ（非同期のみ） |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
同期伝播モードでは、セッションは次のオブジェクト変更通知を送信する前に、承認の待機を強制されます。これにより、パフォーマンスは低下しますが、失効したデータが発生する可能性は軽減されます。
非同期伝播モードでは、セッションは別々のスレッドを作成して変更内容を複数のリモート・サーバーに伝播できます。リモート・サーバーでの変更内容のマージが成功したかどうかには関係なく、制御はローカル・コミット操作の後でただちにクライアントに返されます。したがって、失効したデータをある程度許容するアプリケーションでは、優れたパフォーマンスが得られます。
詳細は、102.2.3項「失効したデータの処理」を参照してください。
変更伝播モードを指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュの「タイプ」を選択します（表103-3を参照）。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
同期変更伝播を使用する場合は、「同期」オプションを選択します。非同期変更伝播を使用する場合は、このオプションを選択しないでください。
このコーディネート・キャッシュで変更の伝播を非同期と同期のどちらで行うかを定義するには、oracle.toplink.remotecommand.RemoteCommandManagerのメソッドsetShouldPropagateAsynchronouslyを使用します。
詳細は、102.4.4項「キャッシュ・コーディネーションAPI」を参照してください。
サービス・チャネルは、複数のセッションが同一コーディネート・キャッシュに参加するためにサブスクライブするTopLinkのコーディネート・キャッシュ・チャネルの名前です。それらのセッションでは、サービス・チャネルを使用してメッセージを相互に交換します。他のサービス・チャネルで送信されたメッセージは、このコーディネート・キャッシュとは交換されません。
表103-4では、どのコーディネート・キャッシュがサービス・チャネルの構成をサポートしているかを示します。
表103-4 コーディネート・キャッシュでのサービス・チャネルの構成のサポート
| コーディネート・キャッシュ | Oracle JDeveloperの使用方法 | TopLink Workbenchを使用したサービス・チャネルの構成方法 |
Javaを使用したサービス・チャネルの構成方法 |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
サービス・チャネルを指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュの「タイプ」を選択します（表103-4を参照）。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
「チャネル」フィールドに、このコーディネート・キャッシュのサービス・チャネルの名前を入力します。
このコーディネート・キャッシュのサービス・チャネルの名前を設定するには、oracle.toplink.remotecommand.RemoteCommandManagerのメソッドsetChannelを使用します。
詳細は、102.4.4項「キャッシュ・コーディネーションAPI」を参照してください。
マルチキャスト・グループ・アドレスは、224.0.0.0〜239.255.255.255の範囲のインターネット・プロトコル（IP）アドレスであり、IPマルチキャスト・グループのメンバーを識別します。同一メッセージをIPマルチキャスト・グループの全メンバーに効率的にブロードキャストするために、各受信者を同じマルチキャスト・グループ・アドレスで構成し、メッセージをそのアドレスに送信します。
表103-5では、どのコーディネート・キャッシュがマルチキャスト・グループ・アドレスの構成をサポートしているかを示します。
表103-5 コーディネート・キャッシュでのマルチキャスト・グループ・アドレスの構成のサポート
| コーディネート・キャッシュ | Oracle JDeveloperの使用方法 | TopLink Workbenchを使用したマルチキャスト・グループ・アドレスの構成方法 |
Javaを使用したマルチキャスト・グループ・アドレスの構成方法 |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注意: このオプションを構成する前に、マルチキャスト操作をサポートするようにホストとネットワークが構成されていることを確認してください。 |
マルチキャスト・グループ・アドレスの構成以外にも、コーディネート・キャッシュ・タイプ用のマルチキャスト・ポートの構成（表103-5を参照）も行う必要があります（103.5項「マルチキャスト・ポートの構成」を参照）。
マルチキャスト・グループ・アドレスを指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュの「タイプ」を選択します（表103-5を参照）。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
図103-3 「キャッシュ・コーディネーション」タブ、「マルチキャスト・グループ・アドレス」フィールド
「マルチキャスト・グループ・アドレス」に224.0.0.0〜239.255.255.255の範囲内のアドレスを入力し、このセッションを特定のコーディネート・キャッシュにサブスクライブします。
このセッションを特定のコーディネート・キャッシュにサブスクライブするには、oracle.toplink.remotecommand.DiscoveryManagerのメソッドsetMulticastGroupAddressを使用します。
|
注意: アドレスが224.0.0.0〜239.255.255.255の範囲内にあることを確認してください。 |
詳細は、102.4.4項「キャッシュ・コーディネーションAPI」を参照してください。
マルチキャスト・ポートは、マルチキャスト・メッセージを受信するポートです。マルチキャスト・グループ（103.4項「マルチキャスト・グループ・アドレスの構成」を参照）のメンバーは、マルチキャスト・グループ・アドレスにブロードキャストされたメッセージを使用して相互に通信します。
表103-6では、どのコーディネート・キャッシュがマルチキャスト・ポートの構成をサポートしているかを示します。
表103-6 コーディネート・キャッシュでのマルチキャスト・ポートの構成のサポート
| コーディネート・キャッシュ | Oracle JDeveloperの使用方法 | TopLink Workbenchを使用したマルチキャスト・ポートの構成方法 |
Javaを使用したマルチキャスト・ポートの構成方法 |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注意: このオプションを構成する前に、マルチキャスト操作をサポートするようにホストとネットワークが構成されていることを確認してください。 |
マルチキャスト・ポートを指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュの「タイプ」を選択します（表103-6を参照）。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
マルチキャスト・グループ・アドレスにブロードキャストされたメッセージが受信されるマルチキャスト・ポートを入力します。
マルチキャスト・グループ・アドレスにブロードキャストされたメッセージを受信するマルチキャスト・ポートを定義するには、oracle.toplink.remotecommand.DiscoveryManagerのメソッドsetMulticastPortを使用します。
詳細は、102.4.4項「キャッシュ・コーディネーションAPI」を参照してください。
セッションのメッセージ・トランスポート・サービスでは、他のセッションへの接続をコーディネート・キャッシュから検索する際に、ネーミング・サービスを使用します。RMIレジストリまたはJava Naming and Directory Interface（JNDI）を使用してリモート・オブジェクトを検索するようにメッセージ・トランスポート・サービスを構成できます。デフォルトでは、JNDIが使用されます。
表103-7では、どのコーディネート・キャッシュがネーミング・サービスの構成をサポートしているかを示します。
詳細は、次の項を参照してください。
セッションのメッセージ・トランスポート・サービスでは、他のセッションへの接続をコーディネート・キャッシュから検索する際に、ネーミング・サービスを使用します。JNDIネーミング・サービスを使用する場合は、JNDIネーミング・サービス情報を構成する必要があります。
表103-8では、どのコーディネート・キャッシュがJNDIネーミング・サービスの構成をサポートしているかを示します。
表103-8 コーディネート・キャッシュでのJNDIネーミング・サービスの構成のサポート
| コーディネート・キャッシュ | Oracle JDeveloperの使用方法 | TopLink Workbenchを使用したJNDIネーミング・サービス情報の構成方法 |
Javaを使用したJNDIネーミング・サービス情報の構成方法 |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TopLinkでは、コーディネート・キャッシュのタイプに応じて、JNDIネーミング・サービス情報の使用方法が異なります。
JMSコーディネート・キャッシュの場合は、特定のセッションのコーディネート・キャッシュが起動されると、そのセッションは、自身のJNDIネーミング・サービス情報を使用してJMSサーバーへの接続を検索および作成します。すべての参加セッションがJMSサーバーに接続されると、コーディネート・キャッシュが準備完了状態になります。この時点で、セッションはオブジェクト変更メッセージの送受信を開始できます。この後、同一JNDIネーミング・サービス情報を使用して、同一コーディネート・キャッシュに参加しているすべてのセッションを構成できます。
RMIまたはCORBAコーディネート・キャッシュの場合は、特定のセッションのコーディネート・キャッシュが起動されると、そのセッションは、自身の接続をJNDIにバインドし、通知メッセージ（そのセッション自身のJNDIネーミング・サービス情報を含む）を作成し、この通知メッセージをそのマルチキャスト・グループにブロードキャストします（103.4項「マルチキャスト・グループ・アドレスの構成」および103.5項「マルチキャスト・ポートの構成」を参照）。同一マルチキャスト・グループに属するセッションは、この通知を受信すると、通知メッセージ内のJNDIネーミング・サービス情報を使用して、新たに通知されたセッションのコーディネート・キャッシュとの双方向接続を確立します。すべての参加セッションがこの方法で相互接続されると、コーディネート・キャッシュが準備完了状態になります。この時点で、セッションはオブジェクト変更メッセージの送受信を開始できます。この後、セッションがデプロイされているホストを識別するJNDIネーミング情報を使用して、各セッションを構成できます。
セッションのJNDIネーミング・サービスを指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュの「タイプ」を選択します（表103-8を参照）。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
図103-5 「キャッシュ・コーディネーション」タブ、「JNDIネーミング・サービス」のオプション
次の情報を参照し、「キャッシュ・コーディネーション」タブのフィールドにデータを入力し、ネーミング・サービス・オプションを構成します。
| フィールド | 説明 |
|---|---|
| URL | JNDIネーミング・サービスの場所。
JMSコーディネート・キャッシュの場合: Oracle Containers for Java EE（OC4J）のJNDIネーミング・サービスを使用していて、コーディネート・キャッシュにあるすべてのホストがOC4J固有のRMIプロトコルであるORMIを使用して通信できる場合、次のようなURLを使用します。 ormi://<JMS-host-IP>:<JMS-host-port> ここで、 RMIまたはCORBAコーディネート・キャッシュの場合: OC4JのJNDIネーミング・サービスを使用していて、コーディネート・キャッシュにあるすべてのホストが、OC4Jのデフォルト・ポートである23791で、OC4J固有のRMIプロトコルであるORMIを使用して通信できる場合、次のようなURLを使用します。 ormi://<session-host-IP>:23791 ここで、 |
| ユーザー名 | JNDIネーミング・サービスへのログインに必要なユーザー名。 |
| パスワード | JNDIネーミング・サービスへのログインに必要なプレーン・テキストの（暗号化されていない）パスワード。パスワードはTopLink Workbenchではプレーン・テキストで表示されますが、sessions.xmlファイルへの書込み時には暗号化されます。
|
| 初期コンテキスト・ファクトリ | ファクトリ・クラスの名前。JNDIネーミング・サービス・プロバイダにより提供され、このクラスによってjavax.naming.spi.InitialContextFactoryインタフェースが実装されます。このファクトリ・クラスは、JNDIネーミング・サービス・プロバイダのコンテキスト実装にアクセスできるjavax.naming.Contextインスタンスの作成に使用されます。
入力する値により、 |
| プロパティ | JNDIコンテキスト・プロパティ。
「プロパティ」をクリックし、カスタムJNDIコンテキスト・プロパティを構成します（103.11項「コンテキスト・プロパティの構成」を参照）。 |
次のようにoracle.toplink.remotecommand.TransportManagerのメソッドsetNamingServiceTypeを使用します。
setNamingServiceType(TransportManager.JNDI_NAMING_SERVICE)
次のTransportManagerメソッドを使用してJNDIネーミング・サービスのオプションを構成します。
setUserName: JNDIネーミング・サービスへのログインに必要なユーザー名を設定します。入力する値により、Context.SECURITY_PRINCIPAL環境プロパティが定義されます。
setPassword: JNDIネーミング・サービスへのログインに必要な非暗号化パスワードを設定します。入力する値により、キャッシュされたコンテキスト・プロパティのContext.SECURITY_CREDENTIALSが定義されます。
setEncriptedPassword: JNDIネーミング・サービスへのログインに必要な暗号化パスワードを設定します。入力する値により、キャッシュされたコンテキスト・プロパティのContext.SECURITY_CREDENTIALSが定義されます。
setInitialContextFactoryName: ファクトリ・クラスの名前。JNDIネーミング・サービス・プロバイダによって提供され、このクラスによってjavax.naming.spi.InitialContextFactoryインタフェースが実装されます。このファクトリ・クラスは、JNDIネーミング・サービス・プロバイダのコンテキスト実装にアクセスできるjavax.naming.Contextインスタンスの作成に使用されます。入力する値により、キャッシュされたコンテキスト・プロパティのContext.INITIAL_CONTEXT_FACTORYが定義されます。
setLocalContextProperties: ローカルJNDIアクセスの初期コンテキストの作成に使用されるプロパティを設定します。
JNDIネーミング・サービスの場所は、URLを入力して指定してください。次の点を考慮してください。
JMSコーディネート・キャッシュでは、OC4JのJNDIネーミング・サービスを使用していて、コーディネート・キャッシュにあるすべてのホストがOC4J固有のRMIプロトコルであるORMIを使用して通信できる場合、次のようなURLを使用します。
ormi://<JMS-host-IP>:<JMS-host-port>
ここで、JMS-host-IPは、JMSサービス・プロバイダが稼働するホストのIPアドレスで、JMS-host-portは、JMSサービス・プロバイダがJMSリクエストをリスニングするポートです。
RMIまたはCORBAコーディネート・キャッシュでは、OC4JのJNDIネーミング・サービスを使用していて、コーディネート・キャッシュにあるすべてのホストが、OC4Jのデフォルト・ポートである23791で、OC4J固有のRMIプロトコルであるORMIを使用して通信できる場合、次のようなURLを使用します。
ormi://<session-host-IP>:23791
ここで、session-host-IPはこのセッションがデプロイされるホストのIPアドレスです。
プロトコルのデフォルト値はormi、ポートのデフォルト値は23791です。TransportManager.DEFAULT_URL_PROTOCOLおよびDEFAULT_URL_PORTを使用することもできます。
詳細は、102.4.4項「キャッシュ・コーディネーションAPI」を参照してください。
セッションのメッセージ・トランスポート・サービスでは、他のセッションへの接続をコーディネート・キャッシュから検索する際に、ネーミング・サービスを使用します。RMIレジストリ・ネーミング・サービスを使用する場合は、RMIレジストリ・ネーミング・サービスのオプションを構成できます。
表103-9では、どのコーディネート・キャッシュがRMIレジストリ・ネーミング・サービスの構成をサポートしているかを示します。
表103-9 コーディネート・キャッシュでのRMIレジストリ・ネーミング・サービスの構成のサポート
| コーディネート・キャッシュ | Oracle JDeveloperの使用方法 | TopLink Workbenchを使用したRMIレジストリ・ネーミング・サービス情報の構成方法 |
Javaを使用したRMIレジストリ・ネーミング・サービス情報の構成方法 |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RMIコーディネート・キャッシュの場合は、特定のセッションのコーディネート・キャッシュが起動されると、そのセッションは自身の接続をそのRMIレジストリにバインドし、通知メッセージ（そのセッション自身のネーミング・サービス情報を含む）を作成し、この通知メッセージをそのマルチキャスト・グループにブロードキャストします（103.4項「マルチキャスト・グループ・アドレスの構成」および103.5項「マルチキャスト・ポートの構成」を参照）。同一マルチキャスト・グループに属するセッションは、この通知を受信すると、通知メッセージ内のJNDIネーミング・サービス情報を使用して、新たに通知されたセッションのコーディネート・キャッシュとの双方向接続を確立します。すべての参加セッションがこの方法で相互接続されると、コーディネート・キャッシュが準備完了状態になります。この時点で、セッションはオブジェクト変更メッセージの送受信を開始できます。この後、セッションがデプロイされているホストを識別するRMIレジストリ・ネーミング情報を使用して、各セッションを構成できます。
セッションのレジストリ・ネーミング・サービスを指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタ・ウィンドウに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュの「タイプ」を選択します（表103-9を参照）。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
図103-6 「キャッシュ・コーディネーション」タブ、「レジストリ・ネーミング・サービス」オプション
次の情報を参照し、ネーミング・サービスのオプションを構成します。
| フィールド | 説明 |
|---|---|
| URL | OC4JのJNDIネーミング・サービスを使用していて、コーディネート・キャッシュにあるすべてのホストがOC4Jのデフォルト・ポートである23791でOC4J固有のRMIプロトコルであるORMIを使用して通信できる場合、次のようなURLを使用します。
ormi://<session-host-IP>:23791 ここで、 |
次のようにoracle.toplink.remotecommand.TransportManagerのメソッドsetNamingServiceTypeを使用します。
setNamingServiceType(TransportManager.REGISTRY_NAMING_SERVICE)
次に、URLを入力してJNDIネーミング・サービスの場所を指定します。次の点を考慮してください。
RMIまたはCORBAコーディネート・キャッシュでは、OC4JのJNDIネーミング・サービスを使用していて、コーディネート・キャッシュにあるすべてのホストが、OC4Jのデフォルト・ポートである23791で、OC4J固有のRMIプロトコルであるORMIを使用して通信できる場合、次のようなURLを使用します。
ormi://<session-host-IP>:23791
ここで、session-host-IPはこのセッションがデプロイされるホストのIPアドレスです。
プロトコルのデフォルト値はormi、ポートのデフォルト値は23791です。TransportManager.DEFAULT_URL_PROTOCOLおよびDEFAULT_URL_PORT定数を使用することもできます。
詳細は、102.4.4項「キャッシュ・コーディネーションAPI」を参照してください。
通知の遅延のオプションは、セッションが使用可能になってからその通知メッセージをコーディネート・キャッシュのメンバーにブロードキャストするまで待機する時間（ミリ秒）の設定に使用します。この余分な遅延は、一部のシステムで接続をネーミング・サービスにポストするまでの時間を延長するために必要な場合があります（103.6項「ネーミング・サービス・タイプの構成」を参照）。
表103-10では、どのコーディネート・キャッシュが通知の遅延の構成をサポートしているかを示します。
表103-10 コーディネート・キャッシュでの通知の遅延の構成のサポート
| コーディネート・キャッシュ | Oracle JDeveloperの使用方法 | TopLink Workbenchを使用した通知の遅延の構成方法 |
Javaの使用方法 |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
通知の遅延以外に、パケットの有効時間の構成も検討が必要な場合があります（103.12項「パケットの有効時間の構成」を参照）。
RMIコーディネート・キャッシュに通知の遅延（ミリ秒）を指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュの「タイプ」を選択します（表103-10を参照）。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
このセッションが使用可能になってからその通知メッセージをコーディネート・キャッシュのメンバーにブロードキャストするまでに待機する時間（ミリ秒）を選択します。
このセッションが使用可能になってからその通知メッセージをコーディネート・キャッシュのメンバーにブロードキャストするまでに待機する時間（ミリ秒）を選択するには、oracle.toplink.remotecommand.DiscoveryManagerのメソッドsetAnnouncementDelayを使用します。
詳細は、102.4.4項「キャッシュ・コーディネーションAPI」を参照してください。
セッションのトランスポート・マネージャにより、コーディネート・キャッシュの複数メンバーへの接続が作成されます。これらの接続のいずれかで通信エラーが発生した場合、セッションでエラーを無視するか、接続を削除するかを構成できます。
表103-11では、どのコーディネート・キャッシュが接続処理の構成をサポートしているかを示します。
表103-11 コーディネート・キャッシュでの接続処理の構成のサポート
| コーディネート・キャッシュ | Oracle JDeveloperの使用方法 | TopLink Workbenchを使用した接続処理の構成方法 |
Javaを使用した接続処理の構成方法 |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
エラー時に接続を削除するようにセッションを構成した場合、セッションは、そのコーディネート・キャッシュのメンバーとの通信を次回試行する際に、新しい接続を確立します。
エラーを無視するようにセッションを構成した場合、セッションは、そのコーディネート・キャッシュのメンバーとの通信を次回試行する際に、同じ接続を引き続き使用します。
エラー時のTopLinkによるセッション接続の処理方法を指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュの「タイプ」を選択します（表103-11を参照）。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
エラー時にデータ・ソース接続を削除するようにセッションを構成する場合は、「エラー時に接続を削除」オプションを選択します。
エラー発生時にデータ・ソース接続を削除するようにセッションを構成するには、oracle.toplink.remotecommand.TransportManagerのメソッドsetShouldRemoveConnectionOnErrorを使用します。
詳細は、102.4.4項「キャッシュ・コーディネーションAPI」を参照してください。
JNDIネーミング・サービスを使用するようにコーディネート・キャッシュを構成した場合は（103.6項「ネーミング・サービス・タイプの構成」を参照）、初期JNDIコンテキストの環境に新しい環境プロパティを追加できます。
表103-12では、どのコーディネート・キャッシュがコンテキスト・プロパティをサポートしているかを示します。
表103-12 コーディネート・キャッシュでのコンテキスト・プロパティのサポート
| コーディネート・キャッシュ | Oracle JDeveloperの使用方法 | TopLink Workbenchを使用したコンテキスト・プロパティの構成方法 |
Javaを使用したコンテキスト・プロパティの構成方法 |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
脚注1 JNDIネーミング・サービスが選択されている場合（103.6項「ネーミング・サービス・タイプの構成」を参照）。
TopLink Workbenchを使用する場合、TopLinkでは、追加された新しい環境プロパティを使用して、ローカルとリモートの両方のJNDIアクセス用に初期コンテキストが作成されます。
Javaを使用する場合は、TransportManagerのメソッドsetLocalContextPropertiesおよびsetRemoteContectPropertiesをコールするセッション・カスタマイザ・クラスを使用して、ローカルとリモートのJNDIアクセス用に異なるプロパティを構成できます（詳細は、89.8項「セッション・カスタマイザ・クラスの構成」を参照してください）。
JNDIコンテキスト・プロパティを定義するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュの「タイプ」を選択します（表103-12を参照）。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
「JNDIネーミング・サービス」オプションが選択されていることを確認します。103.6項「ネーミング・サービス・タイプの構成」を参照してください。
「JNDIネーミング・サービス」領域で、「プロパティ」をクリックします。「プロパティの編集」ダイアログ・ボックスが表示されます。
次の表を参照し、ダイアログ・ボックスの次のフィールドにデータを入力します。
| フィールド | 説明 |
|---|---|
| 名前 | プロパティの名前 |
| 値 | プロパティの値 |
既存のプロパティを変更（または削除）するには、プロパティを選択して「編集」（または「削除」）をクリックします。
ローカルJNDIアクセスの初期コンテキストの作成に使用されるJNDIコンテキスト・プロパティのHashtableを定義するには、oracle.toplink.remotecommand.TransportManagerのメソッドsetLocalContextPropertiesを使用します。dedicated.connectionは、trueのデフォルト値を持つデフォルトのキーです。
詳細は、102.4.4項「キャッシュ・コーディネーションAPI」を参照してください。
パケットの有効時間とは、セッション・データ・パケットが失効するまでのホップ数です。デフォルトは2です。この設定では、ハブとインタフェース・カードが使用可能となり、データ・パケットがローカル・ネットワークを離れることが防止されます。Wide Area Network（WAN）の一部である複数の異なるLocal Area Network（LAN）上でセッションがホスティングされている場合、またはデータ・パケットがローカル・ネットワークを離れないようにファイアウォールが構成されている場合は、あるセッションが送信した通知がコーディネート・キャッシュにある別のセッションに到達しないことがあります。この場合は、正しい有効時間の値をネットワーク管理者に確認してください。
表103-13では、どのコーディネート・キャッシュがパケットの有効時間の構成をサポートしているかを示します。
表103-13 コーディネート・キャッシュでのパケットの有効時間の構成のサポート
| コーディネート・キャッシュ | Oracle JDeveloperの使用方法 | TopLink Workbenchを使用したパケットの有効時間の構成方法 |
Javaの使用方法 |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
パケットの有効時間の構成以外に、通知の遅延の構成も必要な場合があります（103.9項「通知の遅延の構成」を参照）。
セッション・データ・パケットが失効するまでのホップ数を指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュの「タイプ」を選択します（表103-12を参照）。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
「パケットの有効時間」フィールドで、セッション・データ・パケットが失効するまでのホップ数を指定します（デフォルトは2）。
セッション・データ・パケットが失効するまでのホップ数（デフォルトは2）を指定するには、oracle.toplink.remotecommand.DiscoveryManagerのメソッドsetPacketTimeToLiveを使用します。
詳細は、102.4.4項「キャッシュ・コーディネーションAPI」を参照してください。
