この章では、TopLinkのコーディネート・キャッシュの構成方法について説明します。
表88-2に、複数のTopLinkコーディネート・キャッシュ・タイプに共通の構成可能オプションを示します。
詳細は、「キャッシュ・コーディネーションの概要」を参照してください。
表88-2に、複数のTopLinkコーディネート・キャッシュ・タイプに共通の構成可能オプションを示します。ここに記載の構成可能オプション以外にも、表88-1に記載の、特定のコーディネート・キャッシュ・タイプ用のオプションも構成する必要があります。
表88-2 共通コーディネート・キャッシュ・オプション
オプション | タイプ | TopLink Workbench |
Java |
---|---|---|---|
「ディスクリプタ・レベルでのキャッシュ・コーディネーションの変更伝播機能の構成」 |
基本 |
![]() |
![]() |
|
基本 |
![]() |
![]() |
|
基本 |
![]() |
![]() |
|
基本 |
![]() |
![]() |
|
基本 |
![]() |
![]() |
|
基本 |
![]() |
![]() |
|
基本 |
![]() |
![]() |
|
詳細 |
![]() |
![]() |
|
詳細 |
![]() |
![]() |
|
詳細 |
![]() |
![]() |
コーディネート・キャッシュでオブジェクト変更の伝播を非同期と同期のどちらで行うかを構成できます。
表88-3では、どのコーディネート・キャッシュが伝播モードの構成をサポートしているかを示します。
表88-3 コーディネート・キャッシュでの伝播モードの構成のサポート
コーディネート・キャッシュ | TopLink Workbenchの使用 |
Javaの使用 |
---|---|---|
JMSコーディネート・キャッシュ(非同期のみ) |
|
|
RMIコーディネート・キャッシュ |
|
|
CORBAコーディネート・キャッシュ |
|
|
カスタム・コーディネート・キャッシュ |
|
|
同期伝播モードでは、セッションは次のオブジェクト変更通知を送信する前に、承認の待機を強制されます。これにより、パフォーマンスは低下しますが、失効したデータが発生する可能性は軽減されます。
非同期伝播モードでは、セッションは別々のスレッドを作成して変更内容を複数のリモート・サーバーに伝播できます。リモート・サーバーでの変更内容のマージが成功したかどうかには関係なく、制御はローカル・コミット操作の後でただちにクライアントに返されます。したがって、失効したデータをある程度許容するアプリケーションでは、優れたパフォーマンスが得られます。
詳細は、「失効したデータの処理」を参照してください。
変更伝播モードを指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュのタイプを選択します(表88-3を参照)。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
同期変更伝播を使用する場合は、「同期」オプションを選択します。非同期変更伝播を使用する場合は、このオプションを選択しないでください。
サービス・チャネルは、複数のセッションが同一コーディネート・キャッシュに参加するためにサブスクライブするTopLinkのコーディネート・キャッシュ・チャネルの名前です。それらのセッションでは、サービス・チャネルを使用してメッセージを相互に交換します。他のサービス・チャネルで送信されたメッセージは、このコーディネート・キャッシュとは交換されません。
表88-4では、どのコーディネート・キャッシュがサービス・チャネルの構成をサポートしているかを示します。
表88-4 コーディネート・キャッシュでのサービス・チャネルの構成のサポート
コーディネート・キャッシュ | TopLink Workbenchの使用 |
Javaの使用 |
---|---|---|
JMSコーディネート・キャッシュ |
|
|
RMIコーディネート・キャッシュ |
|
|
CORBAコーディネート・キャッシュ |
|
|
カスタム・コーディネート・キャッシュ |
|
|
サービス・チャネルを指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、目的のコーディネート・キャッシュのタイプ(表88-4を参照)を選択します。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
「チャネル」フィールドに、このコーディネート・キャッシュのサービス・チャネルの名前を入力します。
マルチキャスト・グループ・アドレスは、224.0.0.0〜239.255.255.255の範囲のインターネット・プロトコル(IP)アドレスであり、IPマルチキャスト・グループのメンバーを識別します。同一メッセージをIPマルチキャスト・グループの全メンバーに効率的にブロードキャストするために、各受信者を同じマルチキャスト・グループ・アドレスで構成し、メッセージをそのアドレスに送信します。
表88-5では、どのコーディネート・キャッシュがマルチキャスト・グループ・アドレスの構成をサポートしているかを示します。
表88-5 コーディネート・キャッシュでのマルチキャスト・グループ・アドレスの構成のサポート
コーディネート・キャッシュ | TopLink Workbenchの使用 |
Javaの使用 |
---|---|---|
JMSコーディネート・キャッシュ |
|
|
RMIコーディネート・キャッシュ |
|
|
CORBAコーディネート・キャッシュ |
|
|
カスタム・コーディネート・キャッシュ |
|
|
注意: このオプションを構成する前に、マルチキャスト操作をサポートするようにホストとネットワークが構成されていることを確認してください。 |
マルチキャスト・グループ・アドレスの構成以外にも、コーディネート・キャッシュ・タイプ用のマルチキャスト・ポートの構成(表88-6を参照)も行う必要があります(「マルチキャスト・ポートの構成」を参照)。
マルチキャスト・グループ・アドレスを指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュのタイプを選択します(表88-5を参照)。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
図88-3 「キャッシュ・コーディネーション」タブ、「マルチキャスト・グループ・アドレス」フィールド
「マルチキャスト・グループ・アドレス」に224.0.0.0〜239.255.255.255の範囲内のアドレスを入力し、このセッションを特定のコーディネート・キャッシュにサブスクライブします。
マルチキャスト・ポートは、マルチキャスト・メッセージが受信されるポートです。マルチキャスト・グループ(「マルチキャスト・グループ・アドレスの構成」を参照)のメンバーは、マルチキャスト・グループ・アドレスにブロードキャストされたメッセージを使用して相互に通信します。
表88-6では、どのコーディネート・キャッシュがマルチキャスト・ポートの構成をサポートしているかを示します。
表88-6 コーディネート・キャッシュでのマルチキャスト・ポートの構成のサポート
コーディネート・キャッシュ | TopLink Workbenchの使用 |
Javaの使用 |
---|---|---|
JMSコーディネート・キャッシュ |
|
|
RMIコーディネート・キャッシュ |
|
|
CORBAコーディネート・キャッシュ |
|
|
カスタム・コーディネート・キャッシュ |
|
|
注意: このオプションを構成する前に、マルチキャスト操作をサポートするようにホストとネットワークが構成されていることを確認してください。 |
マルチキャスト・ポートを指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュのタイプを選択します(表88-6を参照)。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
マルチキャスト・グループ・アドレスにブロードキャストされたメッセージが受信されるマルチキャスト・ポートを入力します。
セッションのメッセージ・トランスポート・サービスでは、他のセッションへの接続をコーディネート・キャッシュから検索する際に、ネーミング・サービスを使用します。RMIレジストリまたはJava Naming and Directory Interface(JNDI)を使用してリモート・オブジェクトを検索するようにメッセージ・トランスポート・サービスを構成できます。デフォルトでは、JNDIが使用されます。
表88-7では、どのコーディネート・キャッシュがネーミング・サービスの構成をサポートしているかを示します。
表88-7 コーディネート・キャッシュでのネーミング・サービスの構成のサポート
コーディネート・キャッシュ | JNDIネーミング・サービス | RMIレジストリ・ネーミング・サービス |
---|---|---|
JMSコーディネート・キャッシュ |
|
|
RMIコーディネート・キャッシュ |
|
|
CORBAコーディネート・キャッシュ |
|
|
カスタム・コーディネート・キャッシュ |
|
|
詳細は、次の項を参照してください。
セッションのメッセージ・トランスポート・サービスでは、他のセッションへの接続をコーディネート・キャッシュから検索する際に、ネーミング・サービスを使用します。JNDIネーミング・サービスを使用する場合は、JNDIネーミング・サービス情報を構成する必要があります。
表88-8では、どのコーディネート・キャッシュがJNDIネーミング・サービスの構成をサポートしているかを示します。
表88-8 コーディネート・キャッシュでのJNDIネーミング・サービスの構成のサポート
コーディネート・キャッシュ | TopLink Workbenchの使用 |
Javaの使用 |
---|---|---|
JMSコーディネート・キャッシュ |
|
|
RMIコーディネート・キャッシュ |
|
|
CORBAコーディネート・キャッシュ |
|
|
カスタム・コーディネート・キャッシュ |
|
|
TopLinkでは、コーディネート・キャッシュのタイプに応じて、JNDIネーミング・サービス情報の使用方法が異なります。
JMSコーディネート・キャッシュの場合は、特定のセッションのコーディネート・キャッシュが起動されると、そのセッションは、自身のJNDIネーミング・サービス情報を使用してJMSサーバーへの接続を検索および作成します。すべての参加セッションがJMSサーバーに接続されると、コーディネート・キャッシュが準備完了状態になります。この時点で、セッションはオブジェクト変更メッセージの送受信を開始できます。この後、同一JNDIネーミング・サービス情報を使用して、同一コーディネート・キャッシュに参加しているすべてのセッションを構成できます。
RMIまたはCORBAコーディネート・キャッシュの場合は、特定のセッションのコーディネート・キャッシュが起動されると、そのセッションは、自身の接続をJNDIにバインドし、通知メッセージ(そのセッション自身のJNDIネーミング・サービス情報を含む)を作成し、この通知メッセージをそのマルチキャスト・グループにブロードキャストします(「マルチキャスト・グループ・アドレスの構成」および「マルチキャスト・ポートの構成」を参照)。同一マルチキャスト・グループに属するセッションは、この通知を受信すると、通知メッセージ内のJNDIネーミング・サービス情報を使用して、新たに通知されたセッションのコーディネート・キャッシュとの双方向接続を確立します。すべての参加セッションがこの方法で相互接続されると、コーディネート・キャッシュが準備完了状態になります。この時点で、セッションはオブジェクト変更メッセージの送受信を開始できます。この後、セッションがデプロイされているホストを識別するJNDIネーミング情報を使用して、各セッションを構成できます。
セッションのJNDIネーミング・サービスを指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュのタイプを選択します(表88-8を参照)。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
図88-5 「キャッシュ・コーディネーション」タブ、「JNDIネーミング・サービス」のオプション
次の情報を参照し、「キャッシュ・コーディネーション」タブのフィールドにデータを入力し、ネーミング・サービス・オプションを構成します。
フィールド | 説明 |
---|---|
URL | JNDIネーミング・サービスの場所。
JMSコーディネート・キャッシュの場合: Oracle Containers for J2EE(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コンテキスト・プロパティを構成します(「コンテキスト・プロパティの構成」を参照)。 |
セッションのメッセージ・トランスポート・サービスでは、他のセッションへの接続をコーディネート・キャッシュから検索する際に、ネーミング・サービスを使用します。RMIレジストリ・ネーミング・サービスを使用する場合は、RMIレジストリ・ネーミング・サービスのオプションを構成できます。
表88-9では、どのコーディネート・キャッシュがRMIレジストリ・ネーミング・サービスの構成をサポートしているかを示します。
表88-9 コーディネート・キャッシュでのRMIレジストリ・ネーミング・サービスの構成のサポート
コーディネート・キャッシュ | TopLink Workbenchの使用 |
Javaの使用 |
---|---|---|
JMSコーディネート・キャッシュ |
|
|
RMIコーディネート・キャッシュ |
|
|
CORBAコーディネート・キャッシュ |
|
|
カスタム・コーディネート・キャッシュ |
|
|
RMIコーディネート・キャッシュの場合は、特定のセッションのコーディネート・キャッシュが起動されると、そのセッションは自身の接続をそのRMIレジストリにバインドし、通知メッセージ(そのセッション自身のネーミング・サービス情報を含む)を作成し、この通知メッセージをそのマルチキャスト・グループにブロードキャストします(「マルチキャスト・グループ・アドレスの構成」および「マルチキャスト・ポートの構成」を参照)。同一マルチキャスト・グループに属するセッションは、この通知を受信すると、通知メッセージ内のJNDIネーミング・サービス情報を使用して、新たに通知されたセッションのコーディネート・キャッシュとの双方向接続を確立します。すべての参加セッションがこの方法で相互接続されると、コーディネート・キャッシュが準備完了状態になります。この時点で、セッションはオブジェクト変更メッセージの送受信を開始できます。この後、セッションがデプロイされているホストを識別するRMIレジストリ・ネーミング情報を使用して、各セッションを構成できます。
セッションのレジストリ・ネーミング・サービスを指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタ・ウィンドウに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュのタイプを選択します(表88-9を参照)。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
次の情報を参照し、ネーミング・サービスのオプションを構成します。
フィールド | 説明 |
---|---|
URL | OC4JのJNDIネーミング・サービスを使用していて、コーディネート・キャッシュにあるすべてのホストがOC4Jのデフォルト・ポートである23791でOC4J固有のRMIプロトコルであるORMIを使用して通信できる場合、次のようなURLを使用します。
ormi://<session-host-IP>:23791 ここで、 |
通知の遅延のオプションは、セッションが使用可能になってからその通知メッセージをコーディネート・キャッシュのメンバーにブロードキャストするまで待機する時間(ミリ秒)の設定に使用します。この余分な遅延は、一部のシステムで接続をネーミング・サービスにポストするまでの時間を延長するために必要な場合があります(「ネーミング・サービス・タイプの構成」を参照)。
表88-10では、どのコーディネート・キャッシュが通知の遅延の構成をサポートしているかを示します。
表88-10 コーディネート・キャッシュでの通知の遅延の構成のサポート
コーディネート・キャッシュ | TopLink Workbenchの使用 |
Javaの使用 |
---|---|---|
JMSコーディネート・キャッシュ |
|
|
RMIコーディネート・キャッシュ |
|
|
CORBAコーディネート・キャッシュ |
|
|
カスタム・コーディネート・キャッシュ |
|
|
通知の遅延以外に、パケットの有効時間の構成も検討が必要な場合があります(「パケットの有効時間の構成」を参照)。
RMIコーディネート・キャッシュに通知の遅延(ミリ秒)を指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュのタイプを選択します(表88-10を参照)。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
このセッションが使用可能になってからその通知メッセージをコーディネート・キャッシュのメンバーにブロードキャストするまでに待機する時間(ミリ秒)を選択します。
セッションのトランスポート・マネージャにより、コーディネート・キャッシュの複数メンバーへの接続が作成されます。これらの接続のいずれかで通信エラーが発生した場合、セッションでエラーを無視するか、接続を削除するかを構成できます。
表88-11では、どのコーディネート・キャッシュが接続処理の構成をサポートしているかを示します。
表88-11 コーディネート・キャッシュでの接続処理の構成のサポート
コーディネート・キャッシュ | TopLink Workbenchの使用 |
Javaの使用 |
---|---|---|
JMSコーディネート・キャッシュ |
|
|
RMIコーディネート・キャッシュ |
|
|
CORBAコーディネート・キャッシュ |
|
|
カスタム・コーディネート・キャッシュ |
|
|
エラー時に接続を削除するようにセッションを構成した場合、セッションは、そのコーディネート・キャッシュのメンバーとの通信を次回試行する際に、新しい接続を確立します。
エラーを無視するようにセッションを構成した場合、セッションは、そのコーディネート・キャッシュのメンバーとの通信を次回試行する際に、同じ接続を引き続き使用します。
エラー時のTopLinkによるセッション接続の処理方法を指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーション」タブをクリックします。「キャッシュ・コーディネーション」タブが表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュのタイプを選択します(表88-11を参照)。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
エラー時にデータ・ソース接続を削除するようにセッションを構成する場合は、「エラー時に接続を削除」オプションを選択します。
JNDIネーミング・サービスを使用するようにコーディネート・キャッシュを構成した場合は(「ネーミング・サービス・タイプの構成」を参照)、初期JNDIコンテキストの環境に新しい環境プロパティを追加できます。
表88-12では、どのコーディネート・キャッシュがコンテキスト・プロパティをサポートしているかを示します。
表88-12 コーディネート・キャッシュでのコンテキスト・プロパティのサポート
コーディネート・キャッシュ | TopLink Workbenchの使用 |
Javaの使用 |
---|---|---|
JMSコーディネート・キャッシュ |
|
|
RMIコーディネート・キャッシュ脚注1 |
|
|
CORBAコーディネート・キャッシュ脚注1 |
|
|
カスタム・コーディネート・キャッシュ |
|
|
脚注1 JNDIネーミング・サービスが選択されている場合(「ネーミング・サービス・タイプの構成」を参照)。
TopLink Workbenchを使用する場合、TopLinkでは、追加された新しい環境プロパティを使用して、ローカルとリモートの両方のJNDIアクセス用に初期コンテキストが作成されます。
Javaを使用する場合は、TransportManager
メソッドsetLocalContextProperties
およびsetRemoteContectProperties
をコールするセッション・カスタマイザ・クラスを使用して、ローカルとリモートのJNDIアクセス用に異なるプロパティを構成できます(詳細は、「カスタマイザ・クラスの構成」を参照してください)。
JNDIコンテキスト・プロパティを定義するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュのタイプを選択します(表88-12を参照)。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
「JNDIネーミング・サービス」オプションが選択されていることを確認します。「ネーミング・サービス・タイプの構成」を参照してください。
「JNDIネーミング・サービス」領域で、「プロパティ」をクリックします。「プロパティの編集」ダイアログ・ボックスが表示されます。
新しいプロパティを作成するには、「追加」をクリックします。「新規プロパティの追加」ダイアログ・ボックスが表示されます。
既存のプロパティを変更(または削除)するには、プロパティを選択して「編集」(または「削除」)をクリックします。
次の表を参照し、ダイアログ・ボックスの次のフィールドにデータを入力します。
フィールド | 説明 |
---|---|
名前 | プロパティの名前 |
値 | プロパティの値 |
パケットの有効時間とは、セッション・データ・パケットが失効するまでのホップ数です。デフォルトは2です。この設定では、ハブとインタフェース・カードが使用可能となり、データ・パケットがローカル・ネットワークを離れることが防止されます。Wide Area Network(WAN)の一部である複数の異なるLocal Area Network(LAN)上でセッションがホスティングされている場合、またはデータ・パケットがローカル・ネットワークを離れないようにファイアウォールが構成されている場合は、あるセッションが送信した通知がコーディネート・キャッシュにある別のセッションに到達しないことがあります。この場合は、正しい有効時間の値をネットワーク管理者に確認してください。
表88-13では、どのコーディネート・キャッシュがパケットの有効時間の構成をサポートしているかを示します。
表88-13 コーディネート・キャッシュでのパケットの有効時間の構成のサポート
コーディネート・キャッシュ | TopLink Workbenchの使用 |
Javaの使用 |
---|---|---|
JMSコーディネート・キャッシュ |
|
|
RMIコーディネート・キャッシュ |
|
|
CORBAコーディネート・キャッシュ |
|
|
カスタム・コーディネート・キャッシュ |
|
|
パケットの有効時間の構成以外に、通知の遅延の構成も必要な場合があります(「通知の遅延の構成」を参照)。
セッション・データ・パケットが失効するまでのホップ数を指定するには、次の手順を実行します。
ナビゲータでセッションまたはセッション・ブローカを選択します。そのプロパティがエディタに表示されます。
「キャッシュ・コーディネーションを有効にする」オプションが選択されていることを確認し、適切なコーディネート・キャッシュのタイプを選択します(表88-13を参照)。キャッシュ・コーディネーションの各オプションの値がタブ上で表示されます。
「パケットの有効時間」フィールドで、セッション・データ・パケットが失効するまでのホップ数を指定します(デフォルトは2
)。