分散トランザクション処理機能 OpenTP1 解説
OpenTP1は,SPPのサービスグループごとにスケジュールキューを作成してスケジュールします。クライアントUAPがRPCで指定したサービスグループ名とサービス名を基に,SPPへのサービス要求をスケジュールキューに登録します。登録したサービス要求は,先入れ先出しでスケジュールキューから取り出します。
クライアントUAPが指定したSPPのサービスグループが,ほかのノードにある場合でも,スケジュールできます。
SPPのスケジュールを次の図に示します。
図3-42 SPPのスケジュール
クライアントUAPからのサービス要求に,優先順位(スケジュールプライオリティ)を付けられます。サービス要求のスケジュールプライオリティは,クライアントUAPでRPCを使う直前に,dc_rpc_set_service_prio関数で宣言します。ここで宣言したスケジュールプライオリティに従って,サーバUAP側のスケジュールサービスでスケジュールします。
クライアントUAPのスケジュールプライオリティの指定に従うかどうかは,サーバUAP側のユーザサービス定義で指定します。
サービス実行中のSPPが異常終了したときに,SPPのスケジュールを閉塞するかどうかをユーザサービス定義に指定します。
SPPのスケジュールの閉塞を次の図に示します。
図3-43 SPPのスケジュールの閉塞
スケジュールを閉塞する単位として,サービスグループ単位,サービス単位のどちらかを指定します。サービスグループ単位で閉塞すると指定した場合は,異常終了したサービスがあるSPPをすぐに閉塞します。サービス単位で閉塞すると指定した場合は,該当のサービスのスケジュールだけを閉塞して,同じサービスグループに属するほかのサービスのスケジュールは閉塞しません。
SPPのUAPプロセスが異常終了したときに閉塞すると指定した場合は,そのサービスのスケジュールを閉塞します。閉塞されたサービスにサービス要求が来た場合,サービス要求元のクライアントUAPにエラーリターンします。また,サービスを閉塞した時点ですでにスケジュールキューに入っていたサービス要求も,サービス要求元のクライアントUAPにエラーリターンします。
SPPのUAPプロセスが異常終了したときに閉塞しないと指定した場合は,閉塞しないでスケジュールを続けます。ただし,ユーザサービス定義に指定した時間内に3回以上異常終了した場合は,そのSPPをサービスグループ単位またはサービス単位で閉塞します。
SPPの閉塞を解除して再開始するときは,scdrlesコマンドを実行します。
オンライン停止後の全面回復時に,SPPの閉塞状態を引き継ぐかどうかを,SPPごとにユーザサービス定義で指定します。オンライン停止時に閉塞状態だったSPPのうち,閉塞状態を引き継ぐ指定をしたSPPは,全面回復後も閉塞状態で再開始されます。閉塞しているSPPにサービスを要求しても,サービス要求元にエラーリターンされます。
閉塞状態を引き継がないと指定したSPPは,閉塞が解除された状態で再開始されて,要求されたサービスを実行します。
scdholdコマンドとscdrlesコマンドで,SPPをサービスグループ単位,またはサービス単位で閉塞/閉塞解除できます。
SPPの実行形式ファイルをオンライン中に入れ替える場合は,サービスグループ単位で閉塞します。そして閉塞済みのSPPを新しいSPPと入れ替えます。入れ替えが完了してから,scdrlesコマンドで閉塞を解除すれば,新しいSPPを実行できます。
このように,コマンドで閉塞/閉塞解除することで,オンライン中にSPPを変更したり修正したりできます。
scdholdコマンドに指定するサーバ名に,-pオプションを付けて指定する(scdhold -s サーバ名 -p)と,SPPを閉塞したあとでも,該当するSPPへのサービス要求を受け付けられます。受け付けたサービス要求は,スケジュールキューに保持されます。該当するSPPがサービスを処理できる状態になったら,保持していたサービス要求のスケジュールを再開します。
サービス要求を保持できるのは,UAPのサービスグループ単位で閉塞する場合だけです。サービス単位で閉塞する場合は,コマンドの引数にサービス要求を保持する指定はできません。
スケジュールキューにサービス要求を保持する閉塞を次の図に示します。
図3-44 スケジュールキューにサービス要求を保持する閉塞
スケジュールの効率を上げるため,スケジュールキューを経由しないでサービス要求を受信するSPPを指定できます。このようなサーバUAP(ユーザサーバ)をソケット受信型サーバといいます。ソケット受信型サーバの場合,スケジュールキューを経由しないで,SPPに直接サービス要求が渡ります。
トランザクションの同期点処理待ちなど,ソケット受信型サーバがサービス要求を受信できない場合は,一時的にサービス要求のデータを格納します。サービス要求を受信できる状態になってから,格納していたサービス要求を受信します。一時的に格納しておく領域が満杯の場合は,サービス要求はエラーリターンします。
SPPをソケット受信型サーバとするかどうかは,ユーザサービス定義で指定します。
ソケット受信型サーバには,スケジュールキューを使用するSPP(キュー受信型サーバ)に比べて,次に示す制限があります。
ソケット受信型サーバは,ユーザサーバ名(ユーザサービス定義のファイル名)だけを変えることで,複数起動できます。この場合,同じサービスグループ名,同じサーバ名,同じ実行形式プログラム名を指定しておきます。
これによって,マルチサーバ機能と同じように,ソケット受信型サーバを複数起動でき,サービスを分散して要求できます。
なお,同一サービスグループ名のキュー受信型サーバとソケット受信型サーバとは,同時に起動できません。ソケット受信型サーバを起動するときは,稼働しているキュー受信型サーバを停止してから起動してください。
マルチサーバ機能については,「3.4.3 プロセスの制御」を参照してください。
ユーザサービス定義またはユーザサービスデフォルト定義にscdsvcdef定義コマンドを指定することで,SPPのスケジュールキューに対してサービス単位のスケジュール制御ができます。指定できるスケジュール制御は次のとおりです。なお,scdsvcdef定義コマンドの詳細については,マニュアル「OpenTP1 システム定義」を参照してください。
該当サービスを処理しているサーバプロセス数が,scdsvcdef定義コマンドで指定した同時実行可能なサービス数に達している場合,同時実行可能なサービス数に達していないサービスへのサービス要求を,登録順およびスケジュールプライオリティに関係なくスケジュールします。
スケジュールキューに登録されているすべてのサービス要求が,同時実行可能なサービス数に達しているサービスへのサービス要求であった場合,実行中のサービス処理が終了するのを待ち合わせます。サービスごとの同時実行可能なサービス数を次の図に示します。
図3-45 サービスごとの同時実行可能なサービス数
scdsvcdef -c SV1 -p 1 scdsvcdef -c SV2 -p 1
該当サービスへのサービス要求数が,scdsvcdef定義コマンドで指定したキューイング可能なサービス要求数に達している場合,スケジュールキューへは登録しないで,ほかのOpenTP1ノードへの再スケジュールを試みます。
再スケジュールできない場合には,サービス要求元にメッセージ格納バッファ不足としてエラーリターンします。サービスごとのキューイング可能なサービス要求数を次の図に示します。
図3-46 サービスごとのキューイング可能なサービス要求数
scdsvcdef -c SV1 -n 2 scdsvcdef -c SV2 -n 1
該当サービスへのサービス要求のメッセージ格納バッファプール長が,scdsvcdef定義コマンドで指定したキューイング可能なメッセージ格納バッファプール長に達している場合,スケジュールキューへは登録しないで,ほかのOpenTP1ノードへの再スケジュールを試みます。
再スケジュールできない場合には,サービス要求元にメッセージ格納バッファ不足としてエラーリターンします。サービスごとのキューイング可能なメッセージ格納バッファプール長を次の図に示します。
図3-47 サービスごとのキューイング可能なメッセージ格納バッファプール長
scdsvcdef -c SV1 -l 2048 scdsvcdef -c SV2 -l 1024
All Rights Reserved. Copyright (C) 2006, 2012, Hitachi, Ltd.