Hitachi

OpenTP1 Version 7　分散トランザクション処理機能　OpenTP1 クライアント使用の手引 TP1/Client/J編

2.2.9　ネームサービスを使用したRPC

ネームサービスを使用したRPCは，JavaアプリケーションおよびJavaサーブレットから実行できるサービス要求です。Javaアプレットのセキュリティの制約があるため，Javaアプレットからは実行できません。

ネームサービスを使用したRPCの流れと，RPCごとにサービス要求先スケジューラを分散させる場合の定義について説明します。

〈この項の構成〉

(1)　ネームサービスを使用したRPCの流れ

ネームサービスを使用したRPCを行う場合は，TP1/Client/J環境定義にdcnamuse=Yを指定します。さらに，TP1/Client/J環境定義にdchostオペランド，およびdcnamportオペランドを指定するか，またはsetDchostメソッドでnamサーバを指定します。また，rpcCallメソッドを呼び出す前にはrpcOpenメソッドを呼び出す必要があります。CUPの最後にはrpcCloseメソッドを呼び出す必要があります。

ネームサービスを使用した場合のサービス要求の流れを次の図に示します。

図2‒7　ネームサービスを使用した場合のサービス要求の流れ

[図データ]

  1. TP1/Client/Jが提供するTP1Clientクラスのインスタンスを作成する。

  2. rpcOpenメソッドを呼び出してCUPのRPC環境を初期化する。

  3. rpcCallメソッドを呼び出して該当するSPPにサービス要求をする。※

  4. rpcCloseメソッドを呼び出してRPC環境を解放する。

注※

rpcCallメソッド内部の処理の流れを次に示します。

  1. dchostオペランドおよびdcnamportオペランドで定義されたnamサーバに対してコネクションを確立する。

  2. サービス情報を取得するための要求を送信し，namサーバとの間に確立したコネクションを解放する。

  3. namサーバから応答メッセージ送信用のコネクション確立要求を受信後，コネクションを確立しサービス情報を受信する。

  4. namサーバとのコネクションを解放し，namサーバからの応答メッセージのサービス情報を基に，サービスを実行しているTP1/Server上のscdサーバに対してコネクションを確立する。

  5. scdサーバとのコネクションの確立後，サービス要求を送信しコネクションを切断する。

  6. SPPから応答メッセージ送信用のコネクション確立要求を受信後，コネクションを確立し応答メッセージを受信する。

  7. SPPとの間で確立したコネクションを解放する。

なお，この機能の使用時は，ソケット受信型SPPに対してRPCを発行できません。また，TP1/Client/J環境定義のdccltrpcmaxmsgsizeオペランドに2以上を指定した場合，ネームサービスを使用したRPCは，システム共通定義のrpc_max_message_sizeオペランドをサポートするTP1/Server上で稼働しているサービスの情報だけを取得します。サービスの入力パラメタ長が，サービス要求先のシステム共通定義のrpc_max_message_sizeオペランドの値を超える場合もサービス要求は実行されます。システム共通定義のrpc_max_message_sizeオペランドをサポートしないTP1/Server上のSPPに対してはRPCを発行できません。

ページの先頭へ

(2)　RPCごとにサービス要求先スケジューラを分散させる場合の定義

ネームサービスを使用したRPCでは，サービス要求先スケジューラの情報をネームサーバからキャッシュに格納し，キャッシュの情報を参照してRPCごとにサービス要求先スケジューラを分散させることができます。RPCごとにサービス要求先スケジューラを分散させる場合のTP1/Client/J側，TP1/Server側の関連する定義について説明します。

(a)　TP1/Client/J側の定義

RPCごとにサービス要求先スケジューラを分散させる場合は，TP1/Client/J環境定義にdccltloadbalance=Yを指定します。

これによって，TP1/Client/Jは，ネームサーバから複数のサービス要求先スケジューラの情報を取得し，負荷レベルが最も低いサービス要求先スケジューラの情報をキャッシュに格納します。キャッシュに格納されるサービス要求先スケジューラは，一つだけではなく，複数の場合もあります。

キャッシュに格納されたサービス要求先スケジューラが複数ある場合，最初のサービス要求先スケジューラは，ランダムに選択されます。RPCでのサービス要求が2度目以降の場合は，サービス要求先スケジューラの情報を取得するためにキャッシュを参照し，RPCごとにラウンドロビン方式でサービス要求先スケジューラを切り替え，分散させます。

キャッシュの有効期限の指定

TP1/Client/J環境定義のdccltcachetimオペランドで，サービス要求先スケジューラの情報を保持する，キャッシュの有効期限を指定できます。

キャッシュにサービス要求先スケジューラの情報を格納したあとで，キャッシュの有効期限を満了した場合，そのサービス要求先スケジューラの情報を破棄します。その後，サービス要求先スケジューラの情報を再度取得して，その情報をキャッシュに格納することで，キャッシュを更新します。

TP1/Client/J環境定義のdccltcachetimオペランドは，TP1/Client/J環境定義にdccltloadbalance=Yを指定した場合だけ有効になります。

(b)　TP1/Server側の定義

次に示すTP1/Server側の定義のオペランドを指定すると，ネームサーバからサービス要求先スケジューラの情報を取得するときに，スケジューラの負荷情報も同時に取得します。

スケジュールサービス定義

  • scd_announce_server_status=Y（デフォルト）※1

ユーザサービス定義，またはユーザサービスデフォルト定義

  • loadcheck_interval

  • levelup_queue_count※2

  • leveldown_queue_count※2

注※1

このオペランドにNを指定した場合，スケジューラの負荷レベルは常にLEVEL0（負荷が低い状態）となります。負荷レベルが常にLEVEL0のスケジューラが，TP1/Client/Jのサービス要求先スケジューラとなった場合，実際の負荷状態に関係なく，常にサービス要求先スケジューラとして選択されます。

注※2

スケジューラの負荷レベルがサービス要求の滞留数で決まる方式とする場合に指定します。

ページの先頭へ

(3)　マルチホームドホスト形態のTP1/Serverに対してRPCを行う場合の定義

ネームサービスを使用したRPCでは，通信先TP1/Serverがマルチホームドホスト形態の場合に通信障害が発生することがあります。これは，CUPが存在するネットワークから，通信先TP1/Serverのシステム共通定義のmy_hostオペランドで指定したホスト名（IPアドレス）に対応するネットワークアダプタに通信できないことが原因です。

これを回避するためには，TP1/Client/J環境定義にdccltnammlthost=Yを指定します。ネットワークの構成例を次の図に二つ示し，それぞれのネットワーク構成でのTP1/Client/J環境定義のdccltnammlthostオペランドの要否を示します。

図2‒8　マルチホームドホスト形態のTP1/Serverに対してRPCを行う場合の例

[図データ]

ネットワーク構成例2のCUPがTP1/Serverと通信するには，TP1/Client/J環境定義にdccltnammlthost=Yの指定が必要です。

通信先TP1/Serverがマルチホームドホスト形態で，かつ同じTP1/Server上にサービス要求先のSPPが存在しているときは，TP1/Client/J環境定義にdccltnammlthost=Yを指定することでRPCが行えるようになります。通信先TP1/Serverのシステム共通定義のall_nodeオペランドに，CUPが接続されていないネットワーク上に存在するTP1/Serverが指定されている場合，このTP1/Server上のSPPに対してRPCを行うと通信障害が発生します。なお，通信先TP1/Serverがマルチホームドホスト形態でない場合，TP1/Client/J環境定義のdccltnammlthostオペランドの指定に関係なくRPCを行えます。

ページの先頭へ

商品名称に関する表示

All Rights Reserved. Copyright (C) 2006, 2022, Hitachi, Ltd.