JP2006185229A - オンライン同期処理方法及び装置 - Google Patents

Abstract

【課題】 クライアントが発行する同期型のＲＰＣに対して非同期処理によって応答するサーバ計算機において、クライアント側のプログラムを変更することなく同期処理を実現する。
【解決手段】 制御サーバ１１は、クライアント１０からＲＰＣ要求を受信すると、リソースを確保し、このＲＰＣの処理をする非同期処理を起動するとともにＲＰＣ応答送信を抑止し、その後確保したリソースを解放する。非同期処理が終了したとき、制御サーバ１１は、再度リソースを確保し、当該ＲＰＣについて抑止されていた応答をクライアント１０へ送信し、非同期処理の終了時に確保したリソースを解放する。
【選択図】 図２

Description

本発明は、クライアント／サーバ型のオンライン処理システムにおいて、クライアント側からのリモートプロシジャコール（ＲＰＣ）の同期呼び出しに応答するサーバ計算機に関する。

クライアント／サーバ形態のクライアントプログラムからの呼び出し方式には、同期処理呼び出しと非同期処理呼び出しの２種類の方式がある。

同期呼び出し方式では、クライアントは、サーバに処理要求をすると、サーバの処理が完了して応答が返ってくるまで待機する。クライアントは、サーバからの応答を受け取った後に次の処理を実行できる。同期呼び出しではサーバの処理結果を即座に受信することができるが、要求処理中にサーバ障害やネットワーク障害が発生すると同期呼び出しの処理は失敗し、失敗した結果がクライアントに通知される。

非同期呼び出し方式では、クライアントはメッセージキューイングプログラムに処理を要求すると、サーバからの応答を待たずに次の処理を実行できる。クライアントが依頼した処理要求は、サーバ側のメッセージキューに蓄積される。サーバは、このメッセージキューから処理要求を取り出してサーバ側処理を実行し、その結果を再びメッセージキューに格納する。クライアントは、任意の時点でメッセージキューから処理結果を取り出すことができる。このように、非同期呼び出しでは処理要求、処理結果がメッセージキューに蓄積されるため、サーバ障害やネットワーク障害発生時でも、クライアントは処理要求を依頼することができ、また、サーバ側での処理結果を確実に受信することが保証される。

クライアントサーバ型システムの多くは同期呼び出し方式を利用して作成されている。これらのプログラムをサーバ障害やネットワーク障害発生時や、サーバ側が稼動していない状態でも利用できるようにする場合、サーバ側の呼び出し処理方式に合わせて、クライアントプログラムの処理方式を変更する必要がある。サーバ側プログラムが非同期処理を行う場合、クライアントプログラムも非同期処理方式にする必要があった。

これらの問題に対処する従来の技術としては、特開平９−３３０２８７号公報（特許文献１）に開示されるクライアント／サーバシステムの方式がある。

この方式は、クライアント処理の同期呼び出しを内部的に非同期呼び出しに変換することにより、クライアントの同期処理方式を実現するものである。

特開平９−３３０２８７号公報

上記従来の処理方式では、クライアントのプログラム処理には一度エラーが返送される。また、クライアントは、サーバに対して処理結果呼び出しを再度要求する必要がある。このためクライアントプログラムの変更が生じる可能性がある。

本発明の目的は、送られた同期処理要求に対し、非同期処理を実現することにある。

本発明は、クライアント計算機が発行する同期型のリモートプロシジャコール（以下、ＲＰＣと呼ぶ）に応答するサーバ計算機の機能を特徴とする。サーバ計算機は、このＲＰＣのためにリソースを確保した上で、このＲＰＣの処理をする非同期処理を起動するとともにＲＰＣ応答送信を抑止し、その後確保したリソースを解放する。非同期処理が終了したとき、サーバ計算機は、再度リソースを確保し、当該ＲＰＣについて抑止されていた応答をクライアント計算機へ送信し、非同期処理の終了時に確保したリソースを解放する。

本発明によれば、送られた同期処理要求に対し、内部的に非同期処理を実現可能とする。また、サーバ側のリソースを有効に活用する同期処理を実現できる。

以下、本発明の実施形態について図面を用いて説明する。

図１は、本発明によるＲＰＣ通信処理を行うオンライントランザクション処理システムの一構成例を示すブロック図である。実施例のオンライントランザクション処理システムは、業務要求元となる複数のクライアント１０、制御サーバ１１および業務サーバ１４で構成される。クライアント１０と制御サーバ１１の間は任意のネットワークによって接続され、制御サーバ１１と業務サーバ１４はＬＡＮを経由して接続される。

制御サーバ１１は、その外部記憶装置上にステータスファイル１３を格納する。ステータスファイルは、業務サーバ１４と共有してもよい。制御サーバ１１は、クライアント１０からのＲＰＣの送受信を行うＲＰＣ送受信部１１１と、ＲＰＣ応答送信を抑止するＲＰＣ応答抑止制御部１１５と、抑止した応答の送信制御を行うＲＰＣ抑止応答送信制御部１１８とを備える。また、制御サーバ１１は、ＲＰＣ応答抑止制御部１１５とＲＰＣ抑止応答送信制御部１１８をそれぞれ呼び出す受信処理ＵＡＰ（ユーザ・アプリケーション・プログラム）部１２１と、応答処理ＵＡＰ部１２２とを備える。

ＲＰＣ送受信部１１１は、クライアントからのＲＰＣ要求を受信するＲＰＣ受信処理１１２とクライアントにＲＰＣ送信を行うＲＰＣ送信処理１１４と、ＲＰＣ応答抑止状態を監視するタイマ監視処理１２０を有する。

ＲＰＣ応答抑止制御部１１５は、受信処理ＵＡＰ部１２１から呼び出されるＲＰＣ応答抑止処理１１６と、ステータスファイルに抑止情報を設定するステータスファイル抑止情報設定処理１１７とを有する。

ＲＰＣ抑止応答送信制御部１１８は、応答抑止していたクライアントに対して、応答送信するＲＰＣ応答送信処理１１９と、ステータスファイルの抑止情報を削除するステータスファイル抑止状態解除処理１２４とを有する。

業務サーバ１４は、制御サーバ１１から制御を渡され、実際の業務処理を実行する。

クライアント１０、制御サーバ１１および業務サーバ１４は、各々ＣＰＵ、メモリおよび外部記憶装置を有する計算機である。ＲＰＣ送受信部１１１、ＲＰＣ応答抑止制御部１１５、ＲＰＣ抑止応答送信制御部１１８、受信処理ＵＡＰ部１２１および応答処理ＵＡＰ部１２２は、制御サーバ１１のメモリに格納され、そのＣＰＵによって実行されるプログラムである。これらのプログラムの全体は、１つのプロセスとして動作する。図示しない後述の再開始処理部も制御サーバ１１のプログラムであり、このプロセスとして動作する。なお制御サーバ１１と業務サーバ１４を１台のサーバ計算機で実現することも可能である。

図２は、ＲＰＣ送受信処理の概略処理の流れを示す。図２は、クライアント１０のＵＡＰ処理部１０１から同期応答型ＲＰＣ送信を行った場合の例を示している。同期応答型ＲＰＣ送信とは、送信した電文を処理した結果の応答が戻るまで、ＵＡＰ処理部１０１の処理が続行できないものを言う。

ＲＰＣ送受信部１１１は、クライアント１０からＲＰＣ要求を受信すると、トランザクションを起動し、リソースを確保する。次にＲＰＣ送受信部１１１は、受信処理ＵＡＰ部１２１を呼び出し、受信処理ＵＡＰ部１２１がクライアントからのＲＰＣ要求に対応する業務処理をするためにＲＰＣ送受信部１１１を介して業務サーバ１４にサービス要求を送信する。このサービス要求は、メッセージキューイングによる非同期呼び出しの形態をとる。次に受信処理ＵＡＰ部１２１は、ＲＰＣ応答抑止制御部１１５を呼び出してＲＰＣ応答を抑止し、ＲＰＣ送受信部１１１に制御を戻す。ＲＰＣ送受信部１１１は、当該トランザクションを終了させるとともに、確保していたリソースを解放する。図２の点線で囲んだ部分が１つのトランザクション処理の範囲を示す。

業務サーバ１４の業務処理部１４１は、上記のサービス要求を受け付け、業務処理を実行する。業務処理が終了すると、業務処理部１４１は、メッセージキューイングを介して制御サーバ１１へ業務処理回答を送信する。

ＲＰＣ送受信部１１１は、この業務処理回答を受信すると、新たにトランザクションを起動し、リソースを確保する。次にＲＰＣ送受信部１１１は、応答処理ＵＡＰ部１２２を呼び出す。応答処理ＵＡＰ部１２２は、ＲＰＣ抑止応答送信制御部１１８を呼び出してクライアント１０へＲＰＣ抑止応答を送信する。ＲＰＣ応答抑止制御部１１５がＲＰＣ応答抑止をするとき、該当するクライアントの情報を記憶するので、ＲＰＣ抑止応答送信制御部１１８はこの情報を読み出し、該当するクライアント１０へＲＰＣ抑止応答を送信する。その後、応答処理ＵＡＰ部１２２は、ＲＰＣ送受信部１１１に制御を戻す。ＲＰＣ送受信部１１１は、当該トランザクションを終了させるとともに、確保していたリソースを解放する。

受信処理ＵＡＰ部１２１は、その最後の処理でトランザクションを終了させ、リソースを解放するので、ＲＰＣ送受信部１１１は、他のＲＰＣ要求についてそのリソースを割り当て、同様のトランザクション処理を実行させることができる。

また受信処理ＵＡＰ部１２１は、クライアント１０からのＲＰＣ要求に対してＲＰＣ応答を抑止するので、この段階でクライアント１０へＲＰＣ応答が送信されることはない。これによって同期応答型のＲＰＣを送信するクライアント１０のＵＡＰ処理部１０１を変更する必要がない。

図３は、ＲＰＣ受信処理１１２の流れを示すフローチャートである。ＲＰＣ受信処理１１２は、クライアント１０から同期ＲＰＣ要求を受け付ける（ステップ３１）と、このＲＰＣ要求が指定するサービスに該当する受信処理ＵＡＰ部１２１が制御サーバ１１内に存在するか否か判定する（ステップ３２）。サービス要求をする場合、通常、要求するサービスのサービス名を指定する。該当サービスがない場合、ＲＰＣ受信処理１１２は、クライアント１０に対して即座にエラー応答を送信する（ステップ３３）。該当サービスがある場合、ＲＰＣ受信処理１１２は、トランザクション処理を開始する（ステップ３４）。トランザクションを起動するとき、ＲＰＣ受信処理１１２は、このトランザクションに空きのスレッドを割り当てる。各スレッドは、各々メモリ領域などのリソースを確保しているので、トランザクション起動とともにリソースが確保されることになる。その後、ＲＰＣ受信処理１１２は、指定されたサービスに対応する受信処理ＵＡＰ部１２１を呼び出す（ステップ３５）。

受信処理ＵＡＰ部１２１から制御が戻ったとき、ＲＰＣ受信処理１１２は、受信処理ＵＡＰ部１２１からＲＰＣ応答抑止要求があったか否かを判定する（ステップ３６）。受信処理ＵＡＰ部１２１によって、あるいはクライアント１０からのＲＰＣ要求によってはＲＰＣ応答抑止を行わない場合がある。ＲＰＣ応答抑止を行わない場合には、ＲＰＣ受信処理１１２は、クライアント１０に対してＲＰＣ応答を送信し（ステップ３７）、ステップ３８へ行く。ＲＰＣ応答抑止要求がある場合には、ＲＰＣ受信処理１１２は、トランザクション処理を終了させる（ステップ３８）。ＲＰＣ受信処理１１２は、このトランザクションに割り当てられていたスレッドを解放するので、このスレッドとともに確保されていたリソースが解放される。

ステップ３６でＲＰＣ応答抑止要求がある場合、ＲＰＣ受信処理１１２は、クライアント１０に対してＲＰＣ応答を送信しないが、クライアント１０側の処理は完結していないので、待ち合わせることになる。制御サーバ１１は、ステップ３８で解放されたリソースを用いて他のトランザクションの処理を実行することができる。

図４は、受信処理ＵＡＰ部１２１の処理の流れを示すフローチャートである。受信処理ＵＡＰ部１２１は、ステップ３５の受信処理ＵＡＰ部呼び出しにより処理を開始する。受信処理ＵＡＰ部１２１は、サービス処理を行うための準備処理等を実行し（ステップ４１）、その後、業務サーバ１４の業務処理部１４１に業務処理を実行させるためにサービス要求を行う（ステップ４２）。このサービス要求には応答先のＩＰアドレス又は後述の抑止識別子５１が付加されている。このサービス要求は、キューを使用したメッセージ転送による要求でも、ＲＰＣによる非応答送信要求でもよい。いずれにしても業務サーバ１４の業務処理は非同期処理となる。

業務処理部１４１からの業務処理回答を待つ必要がある場合には、受信処理ＵＡＰ部１２１は、クライアント１０へのＲＰＣ応答を抑止することとし、ＲＰＣ応答抑止制御部１１５を呼び出す（ステップ４３）。ＲＰＣ応答抑止制御部１１５から戻ったとき、受信処理ＵＡＰ部１２１は処理を終了し、ＲＰＣ受信処理１１２に制御を戻す。ただし受信処理ＵＡＰ部１２１によっては、あるいはＲＰＣ要求の内容によってはＲＰＣ応答を抑止しないことも可能であり、その場合にはステップ４３を実行せず、ＲＰＣ応答抑止要求なしを指定してＲＰＣ受信処理１１２に制御を戻す。なおステップ４３をステップ４２の前に実行してもよい。

図５は、ＲＰＣ応答抑止制御部１１５とＲＰＣ抑止応答送信制御部１１８で用いられるＲＰＣ応答抑止管理テーブル２００のデータ構成を示す図である。ＲＰＣ応答抑止管理テーブル２００の各レコードは、抑止識別子５１、応答先サービス名５２、応答先ＩＰアドレス５３、応答先ポート番号５４及びタイムアウト時刻５５から構成される。抑止識別子５１は、ＲＰＣ応答抑止管理テーブル２００のレコードを検索するときのキーとなる一意な識別子である。応答先サービス名５２は、要求されたサービスのサービス名である。タイムアウト時刻５５は、応答抑止してから抑止応答を送信するまでの時間を監視するときの上限時刻を設定する。

ＲＰＣ応答抑止管理テーブル２００は、プロセス内のメモリ領域に展開される。またＲＰＣ応答抑止管理テーブル２００の情報は、障害回復に備えてステータスファイル１３にも保存される。

使用中のＲＰＣ応答抑止レコード５６，５７は、図示するように、使用中ＲＰＣ応答抑止レコード制御ポインタ６２からチェーンされる。また空きのＲＰＣ応答抑止レコード５８，５９は、空きＲＰＣ応答抑止レコード制御ポインタ６１からチェーンされる。新しくＲＰＣ応答抑止レコードを作成するとき、空きＲＰＣ応答抑止レコード制御ポインタ６１からチェーンされている空きレコードの１つに上記のＲＰＣ応答抑止情報を作成し、使用中ＲＰＣ応答抑止レコード制御ポインタ６２にチェーンし直すことにより、ＲＰＣ応答抑止管理テーブル２００に新しく作成したレコードが追加される。

本実施例では、ＲＰＣ応答抑止管理テーブル２００は、当該プロセスを起動するときにあらかじめメモリに展開され、空きレコードの動的追加は行われない。

図６は、受信処理ＵＡＰ部１２１から呼び出されるＲＰＣ応答抑止制御部１１５の処理の流れを示すフローチャートである。ＲＰＣ応答抑止制御部１１５のＲＰＣ応答抑止処理１１６は、メモリ内に展開されているＲＰＣ応答抑止管理テーブル２００に応答抑止対象となる当該応答先を設定できる空きレコードが存在するか否か判定する（ステップ７１）。空きレコードがない場合、ＲＰＣ応答抑止処理１１６は、呼び出し元に対してＲＰＣ応答抑止ができない旨のエラーを設定し（ステップ７２）、処理を終了する。このエラー報告は、受信処理ＵＡＰ部１２１を介してＲＰＣ受信処理１１２に伝えられ、ステップ３７でクライアント１０にエラー報告される。空きレコードがある場合、ＲＰＣ応答抑止処理１１６は、空きレコードの１つに当該クライアントについて応答先サービス名５２、応答先ＩＰアドレス５３および応答先ポート番号５４を設定する（ステップ７３）。またＲＰＣ応答抑止処理１１６は、抑止中のタイマ監視を行うために、現在時刻を求め（ステップ７４）、現在時刻にタイマ時間を加算した値を当該レコードのタイムアウト時刻５５に設定する（ステップ７５）。またＲＰＣ応答抑止処理１１６は、一意な識別子を求め（ステップ７６）、当該レコードの抑止識別子５１に設定する（ステップ７７）。以上の処理によってＲＰＣ応答抑止レコードが作成されたので、ＲＰＣ応答抑止処理１１６は、このレコードを使用中ＲＰＣ応答抑止レコード制御ポインタ６２にチェーンし直す。

次にステータスファイル抑止情報設定処理１１７は、作成したレコードをステータスファイル１３に追加する（ステップ７８）。ステータスファイル１３の情報は、後述するように、制御サーバ１１に障害が発生し、メモリ内容が消失した場合に障害回復のために使用される。なおＲＰＣ応答抑止管理テーブル２００の内容を制御サーバ１１、業務サーバ１４間で共用されるメモリ上に保存してもよい。

ＲＰＣ応答抑止制御部１１５は、設定された抑止識別子５１又は抑止識別子５１と応答先ＩＰアドレス５３をもって受信処理ＵＡＰ部１２１に戻る。受信処理ＵＡＰ部１２１は、取得した抑止識別子５１と応答先ＩＰアドレス５３の対応を応答処理ＵＡＰ部１２２に引き渡してもよい。

図７は、業務サーバ１４の業務処理部１４１の処理が終了し、業務処理回答が戻ってきたときのＲＰＣ送受信部１１１の処理の流れを示すフローチャートである。業務サーバ１４から応答を受信する（ステップ８１）と、ＲＰＣ送信処理１１４は、ＲＰＣ応答を送信する処理を開始する。受信した業務処理回答には、抑止識別子５１又は応答先ＩＰアドレス５３が付加されている。ＲＰＣ送信処理１１４は、処理終了したサービスに該当する応答処理ＵＡＰ部１２２が制御サーバ１１内に存在するか否か判定する（ステップ８２）。該当サービスがない場合、ＲＰＣ送信処理１１４は、エラー処理を行い（ステップ８３）、ステップ８６へ行く。エラー処理は、クライアント１０へエラーメッセージを送信する場合と、クライアント１０へＲＰＣエラー応答を送信する場合とで処理手順が異なるが、詳細な手順の説明を省略する。

該当サービスがある場合、ＲＰＣ送信処理１１４は、トランザクション処理を開始する（ステップ８４）。ＲＰＣ送信処理１１４は、新しいトランザクションに空きのスレッドを割り当てて、このトランザクションを起動する。すなわちこのトランザクションを処理するために、ここでリソースが確保される。その後、ＲＰＣ送信処理１１４は、指定されたサービスに対応する応答処理ＵＡＰ部１２２を呼び出す（ステップ８５）。このときＲＰＣ送信処理１１４が応答処理ＵＡＰ部１２２に応答先ＩＰアドレス５３を渡してもよい。応答処理ＵＡＰ部１２２から制御が戻ったとき、ＲＰＣ送信処理１１４は、トランザクション処理を終了させる（ステップ８６）。ＲＰＣ送信処理１１４は、このトランザクションに割り当てられていたスレッドを解放するので、このスレッドとともに確保されていたリソースが解放される。

図８は、応答処理ＵＡＰ部１２２の処理の流れを示すフローチャートである。応答処理ＵＡＰ部１２２は、ステップ８５の応答処理ＵＡＰ部呼び出しにより処理を開始する。応答処理ＵＡＰ部１２２は、サービス処理を行うための準備処理等を実行し（ステップ９１）、その後、業務サーバ１４が処理した結果を応答対象のクライアント１０に応答するため、受信処理ＵＡＰ部１２１が取得した抑止識別子５１を指定し、ＲＰＣ抑止応答送信制御部１１８を呼び出す（ステップ９２）。応答処理ＵＡＰ部１２２が抑止識別子５１と応答先ＩＰアドレス５３の対応を取得している場合には、ＲＰＣ送信処理１１４から受け取った応答先ＩＰアドレス５３と突き合わせることによって、対応する抑止識別子５１が得られる。

図９は、応答処理ＵＡＰ部１２２から呼び出されるＲＰＣ抑止応答送信制御部１１８の処理の流れを示すフローチャートである。ＲＰＣ抑止応答送信制御部１１８は、この呼び出し時に入力される抑止識別子５１と同一識別子がメモリ内に展開されているＲＰＣ応答抑止管理テーブル２００に設定されているか否か判定する（ステップ１５１）。当該抑止識別子がＲＰＣ応答抑止管理テーブル２００にない場合には、ＲＰＣ抑止応答送信制御部１１８は、エラーを設定し（ステップ１５２）、ＲＰＣ抑止応答送信処理を終了する。このエラーは、ＲＰＣエラー応答としてクライアント１０へ送信されない。当該抑止識別子がこのテーブルに存在する場合には、ＲＰＣ抑止応答送信制御部１１８は、テーブルの該当レコードから応答先となるクライアント１０の応答先サービス名５２、応答先ＩＰアドレス５３および応答先ポート番号５４を求める（ステップ１５３）。ＲＰＣ抑止応答送信制御部１１８は、これらの情報を用いてクライアント１０に業務処理結果応答の送信を行う（ステップ１５４）。その後、ＲＰＣ抑止応答送信制御部１１８は、ＲＰＣ応答抑止管理テーブル２００から当該抑止識別子５１をもつＲＰＣ応答抑止レコードをクリアする（ステップ１５５）。すなわちＲＰＣ抑止応答送信制御部１１８は、当該レコードの内容を０クリアして空きＲＰＣ応答抑止レコード制御ポインタ６１にチェーンし直す。またＲＰＣ抑止応答送信制御部１１８は、ステータスファイル１３上にある当該ＲＰＣ応答抑止レコードを削除する（ステップ１５６）。

図７、図８および図９の一連の処理を実行することにより、ＲＰＣ送受信部１１１は、業務サーバ１４からの結果応答を受信した時点で、トランザクションを起動してリソースを確保し、応答処理ＵＡＰ部１２２から当該クライアント１０にＲＰＣ抑止応答送信処理を行う。これによって制御サーバ１１が業務処理結果を待っている間にそのリソースを占有することなく、クライアント１０の同期処理を完結させることができる。

図１０は、ＲＰＣ応答抑止の監視上限時刻に達した時に、該当するクライアント１０にエラー応答送信を行うタイマ監視処理１２０の流れを示すフローチャートである。タイマ監視処理１２０は、例えば、一定時間ごとに起動されて動作する。タイマ監視処理１２０は、ＲＰＣ応答抑止管理テーブル２００に使用中のＲＰＣ応答抑止レコードがあるか否か判定する（ステップ１６１）。該当するレコードがない場合には、タイマ監視処理１２０は、タイマ監視処理を終了する。使用中の該当レコードがある場合、タイマ監視処理１２０は、先頭から最終までの使用中レコードについて、監視時刻に達しているか否か判定する。そのため、タイマ監視処理１２０は、現在時刻を求め（ステップ１６２）、取得したＲＰＣ応答抑止レコード中に設定されているタイムアウト時刻５５と現在時刻を比較し、ＲＰＣ応答抑止タイムアウトか否か判定する（ステップ１６３）。すなわちタイムアウト時刻５５より現在時刻の方が大きい場合には、タイマ監視処理１２０は、当該クライアントにエラー応答を送信する（ステップ１６４）。その後、タイマ監視処理１２０は、当該ＲＰＣ応答抑止管理レコードをクリアする（ステップ１６５）。また、タイマ監視処理１２０は、ステータスファイル１３上にある当該ＲＰＣ応答抑止レコードをクリアし（ステップ１６６）、ステップ１６７に進む。ＲＰＣ応答抑止タイムアウトでない場合か、またはステップ１６６の処理が済んだとき、タイマ監視処理１２０は、使用中の全レコードの処理が終了したか否か判定する（ステップ１６７）。次の使用中レコードがある場合には、タイマ監視処理１２０は、そのレコードを取得し（ステップ１６８）、取得したレコードについてステップ１６３の判定を行う。使用中の全レコードの処理が終了したとき、タイマ監視処理１２０は、その処理を終了する。

図１１は、制御サーバ１１の障害によりメモリに展開されるＲＣＰ応答抑止管理テーブル２００が消失した場合に、プロセスの実行を再開始する再開始処理部の本発明に関連する処理の流れを示すフローチャートである。

再開始処理部は、ステータスファイル１３からＲＰＣ抑止応答レコードを全レコード読み込む（ステップ１７１）。次に再開始処理部は、ＲＰＣ抑止応答レコードが存在するか否か判定する（ステップ１７２）。ＲＰＣ抑止応答レコードがない場合には、再開始処理部は、その処理を終了する。ＲＰＣ抑止応答レコードがある場合には、再開始処理部は、先頭のレコードを選択し、そのクライアント１０にエラー応答を送信する（ステップ１７３）。次に再開始処理部は、全レコードの処理が済んだか否か判定する（ステップ１７４）。まだ未処理のレコードがある場合には、再開始処理部は、次のレコードを選択し（ステップ１７５）、ステップ１７３の処理を繰り返す。全レコードの処理が済んだとき、再開始処理部はその処理を終了する。

本処理により、仕掛り中となっている応答抑止状態について応答送信を可能とし、クライアント１０での同期処理の早期決着を図ることができる。なお再開始処理部の処理は、プロセス再開始処理全体の一部を構成する。

本実施形態によれば、制御サーバ１１は、業務サーバ１４が非同期処理を行っている間に制御サーバ１１内のリソースを占有することなく、クライアントからのＲＰＣ要求に応答することができる。これによって、例えば制御サーバ１１のリソース量が限られていて１つのＲＰＣ要求しか処理できない場合にも、複数のクライアント１０からのＲＰＣ要求を同時に処理可能となる。また同期応答型のＲＰＣ要求をするクライアント１０に対して正常時のエラー応答が返送されないため、そのＵＡＰ処理部１０１に変更を加えることもなく、制御サーバ１１と業務サーバ１４を含むオンライントランザクション処理システムに対してＲＰＣを実現できる。また制御サーバ１１は、ＲＰＣ応答送信を抑止してからの経過時間をタイマ監視し、タイムアウト状態になったＲＰＣ応答を自動的に送信するので、クライアントへの応答送信漏れを防ぐことができる。

実施形態のシステムの構成図である。 実施形態のＲＰＣ送受信の概略処理の流れを示す図である。 実施形態のＲＰＣ受信処理の流れを示すフローチャートである。 実施形態の受信処理ＵＡＰ部の処理の流れを示すフローチャートである。 ＲＰＣ応答抑止管理テーブルのデータ構成例を示す図である。 実施形態のＲＰＣ応答抑止制御部の処理の流れを示すフローチャートである。 実施形態のＲＰＣ送信処理の流れを示すフローチャートである。 実実施形態の応答処理ＵＡＰ部の処理の流れを示すフローチャートである。 実施形態のＲＰＣ抑止応答送信制御部の流れを示すフローチャートである。 実施形態のタイマ監視処理の流れを示すフローチャートである。 実施形態の障害時の再開始処理の流れを示すフローチャートである。

符号の説明

１０…クライアント、１１…制御サーバ、１４…業務サーバ、１１１…ＲＰＣ送受信部、１１５…ＲＰＣ応答抑止制御部、１１８…ＲＰＣ抑止応答送信制御部、１２０…タイマ監視処理、１２１…受信処理ＵＡＰ部、１２２…応答処理ＵＡＰ部。

Claims (5)

1. 同期型のリモートプロシジャコールを発行するクライアント計算機と、前記リモートプロシジャコールの処理を行ってその処理結果を前記クライアント計算機に応答するサーバ計算機とを有するオンライン処理システムのうちの前記サーバ計算機によって実行される方法であって、
   受信した前記リモートプロシジャコールのためのリソースを確保し、
   前記リモートプロシジャコールの処理をする非同期処理を起動し、
   前記リモートプロシジャコールの応答送信を抑止し、
   確保した前記リソースを解放し、
   前記非同期処理が終了したとき、前記リモートプロシジャコールのためのリソースを確保し、
   当該リモートプロシジャコールについて抑止されていた応答を前記クライアント計算機へ送信し、
   前記非同期処理の終了時に確保した前記リソースを解放することを特徴とするオンライン同期処理方法。
2. 応答送信を抑止した前記リモートプロシジャコールの応答先情報をメモリに保存し、前記の抑止応答の送信処理に引き継ぐことを特徴とする請求項１記載のオンライン同期処理方法。
3. 前記サーバ計算機の障害時の障害回復に備えて、前記メモリ上の前記応答先情報を前記サーバ計算機の外部記憶装置にも保存することを特徴とする請求項２記載のオンライン同期処理方法。
4. 前記応答送信を抑止したときからの経過時間が所定時間を越えてなお抑止応答が前記クライアント計算機へ送信されないタイムアウト状態が発生したか否かタイマ監視し、
   前記タイムアウト状態を検出したとき、前記クライアント計算機へ応答を送信することを特徴とする請求項１記載のオンライン同期処理方法。
5. 同期型のリモートプロシジャコールを発行するクライアント計算機と、前記リモートプロシジャコールの処理を行ってその処理結果を前記クライアント計算機に応答するサーバ計算機とを有するオンライン処理システムのうちの前記サーバ計算機であって、
   前記サーバ計算機は、ＣＰＵとメモリを有し、前記メモリに格納されるプログラムを前記ＣＰＵによって実行することによって実現される処理手段として、
   受信した前記リモートプロシジャコールのためのリソースを確保する手段と、
   前記リモートプロシジャコールの処理をする非同期処理を起動する手段と、
   前記リモートプロシジャコールの応答送信を抑止する手段と、
   確保した前記リソースを解放する手段と、
   前記非同期処理が終了したとき、前記リモートプロシジャコールのためのリソースを確保する手段と、
   当該リモートプロシジャコールについて抑止されていた応答を前記クライアント計算機へ送信する手段と、
   前記非同期処理の終了時に確保した前記リソースを解放する手段とを有することを特徴とするサーバ計算機。

Images