【０００１】
【発明の属する技術分野】
本発明は、サーバコンピュータに備わるデータベース等のデータ記憶装置をネットワーク経由でクライアントコンピュータからアクセスする場合などに好適なクライアント・サーバ方式におけるデータ記憶装置のレコード先読み制御方法に関する。
【０００２】
【従来の技術】
従来のこの種のレコード先読み制御方法として、特開平６−９６０３３号公報に記載される方法（以下、第１の従来技術と称す）、特開昭６１−１９５４３９号公報に記載される方法（以下、第２の従来技術と称す）、特開平４−１８４６５２号公報に記載される方法（以下、第３の従来技術と称す）が知られている。
【０００３】
第１の従来技術では、ユーザプログラムから１レコードの読み込み要求を受けたクライアントが、要求されたレコードとそれ以降のレコードとの複数のレコードの読み込み依頼をサーバに対して行い、サーバが該当する複数のレコードをファイルから読み出してクライアントへ送信する。クライアントは、受信した複数レコードをバッファに蓄積後、要求された１レコードをユーザプログラムに返却し、次にユーザプログラムから１レコードの読み込み要求を受けたときはバッファから次の１レコードを取り出してユーザプログラムに返却する。そして、バッファの内容を全て返却し終え、ユーザから要求されるレコードがバッファになくなると、クライアントは最初と同様に、要求されたレコードとそれ以降のレコードとの複数のレコードの読み込み依頼をサーバに対して行い、サーバは前回と同様に該当する複数のレコードをファイルから読み出してクライアントへ送信する。
【０００４】
第２の従来技術も基本的には第１の従来技術と同じであり、クライアント計算機上で実行されるプログラムが、サーバ計算機に保持されたファイルにアクセスするに際し、クライアント計算機は、クライアント計算機で発生する１アクセス要求のアクセスデータ長より大きなデータ長のバッファと、前記プログラムとバッファ間でアクセス要求データの転送を制御する手段とを備え、バッファとサーバ計算機との間では、前記アクセスデータ長よりも大きなデータ長を転送単位としてファイルデータを転送する。
【０００５】
第３の従来技術も基本的には第１の従来技術と同じであり、端末コンピュータから順読みを指示する命令が送られてくると、ホストコンピュータはファイルからレコードを複数件読み出して一括して端末コンピュータに転送し、端末コンピュータではそれを受信バッファに蓄積する。そして、ユーザプログラムが順読みを指示する命令を発行する毎に、端末コンピュータでは受信バッファから１つのレコードを取り出してユーザプログラムに返却する。そして、受信バッファが空になると、前回と同様に順読みを指示する命令をホストコンピュータに送り、ホストコンピュータは再びファイルから複数のレコードを読み出して端末コンピュータに転送する。
【０００６】
他方、クライアント・サーバ方式のレコード先読み方法ではないが、特開昭６２−２５９１３５号公報には、データベース中に１個以上のフィールドからなるレコード群を格納する機能と、データベースから指定した条件のレコードを検索する機能とを有するデータベース管理システムにおいて、ユーザプログラムからのレコードの検索要求時に、１回のコールで複数個のレコードの検索を行い、その検索結果のレコード群をまとめてユーザプログラム側へ転送する方法が記載されている。ここで、データベース管理システム側をサーバ、ユーザプログラム側をクライアントに置き換えると、クライアントからの１回のコールで複数個のレコードの検索結果がサーバから返される構成になり、上述した第１乃至第３の従来技術に類似した方法となる。
【０００７】
【発明が解決しようとする課題】
上述したようにクライアント・サーバ方式のレコード先読み制御は従来からも提案されていたが、上述した従来技術では、ユーザプログラムに渡すべきレコード数が多く、クライアント側のバッファに何度も先読みする必要がある場合、バッファが空になった時点でユーザプログラムに対するレスポンスが悪化するという課題があった。その理由は、バッファが空になってユーザプログラムに返却すべきレコードがバッファにないことを検出した時点で、クライアントからサーバに次のレコードの読み込み要求を出し、サーバがこの要求を受けてファイルやデータベースから次の複数のレコードを読み出してクライアントに送信しており、クライアント側のバッファに先読みされるまでに時間がかかるためである。
【０００８】
また、サーバがファイル等から取得したレコードをそのままクライアントに渡すのではなく、レコード中のデータのデータ型を変換してからクライアントに渡す場合、データ型変換処理を行う時間も必要になるため、一層レスポンスが悪化することになる。
【０００９】
本発明はこのような事情に鑑みて提案されたものであり、その目的は、ユーザプログラムに渡すべきレコード数が多く、クライアント側のバッファに何度も先読みする必要がある場合であっても、レスポンス良くレコードをユーザプログラムに返却することができるようにすることにある。
【００１０】
【課題を解決するための手段】
本発明の第１のレコード先読み制御方法は、クライアント・サーバ方式におけるレコード先読み制御方法において、クライアントコンピュータからレコードの読み込み依頼を受けたサーバコンピュータが、データ記憶装置から複数のレコードを先読みしてサーバ側通信バッファに格納した後に前記クライアントコンピュータに一括して送信し、且つ、最終のレコードを前記データ記憶装置から未だ取り出していないときは前記クライアントコンピュータからの依頼を待たずに次に前記クライアントコンピュータに送信する予定の複数のレコードを前記データ記憶装置から先読みして前記サーバ側通信バッファに格納しておくことを特徴とする。
【００１１】
本発明の第２のレコード先読み制御方法は、クライアント・サーバ方式におけるレコード先読み制御方法において、クライアントコンピュータからレコードの読み込み依頼を受けたサーバコンピュータが、データ記憶装置から複数のレコードを先読みしてレコードバッファに格納し、該レコードバッファに格納された各レコード中のデータに対するデータ型変換を行った変換処理済みのレコードをサーバ側通信バッファに格納した後に前記クライアントコンピュータに一括して送信し、且つ、最終のレコードを前記データ記憶装置から未だ取り出していないときは前記クライアントコンピュータからの依頼を待たずに次に前記クライアントコンピュータに送信する予定の複数のレコードを前記データ記憶装置から先読みして前記レコードバッファに格納すると共にデータ型変換処理を行って前記サーバ側通信バッファに格納しておくことを特徴とする。
【００１２】
本発明の第３のレコード先読み制御方法は、第１または第２のレコード先読み制御方法において、前記クライアントコンピュータは、前記サーバコンピュータから受信した複数のレコードをクライアント側通信バッファに格納し、該クライアント側通信バッファからレコードを１つずつ読み出してユーザプログラムに返却し、ユーザプログラムに返却するレコードが前記クライアント側通信バッファに存在しない場合には次のレコードの読み込みを前記サーバコンピュータに依頼することを特徴とする。
【００１３】
本発明の第１のレコード先読み制御システムは、相互に通信可能なクライアントコンピュータとサーバコンピュータとから構成され、前記サーバコンピュータは、前記クライアントコンピュータからレコードの読み込み依頼を受けたときにデータ記憶装置から複数のレコードを先読みしてサーバ側通信バッファに格納する処理と、前記サーバ側通信バッファに格納された全てのレコードを前記クライアントコンピュータに一括して送信する処理と、最終のレコードを前記データ記憶装置から未だ取り出していないときは前記クライアントコンピュータからの依頼を待たずに前記クライアントコンピュータに送信する予定の複数のレコードを前記データ記憶装置から先読みして前記サーバ側通信バッファに格納する処理とを行うサーバシステムを備えることを特徴とする。
【００１４】
本発明の第２のレコード先読み制御システムは、相互に通信可能なクライアントコンピュータとサーバコンピュータとから構成され、前記サーバコンピュータは、前記クライアントコンピュータからレコードの読み込み依頼を受けたときにデータ記憶装置から複数のレコードを先読みしてレコードバッファに格納する処理と、該レコードバッファに格納された各レコード中のデータに対するデータ型の変換を行う処理と、該変換処理済みのレコードをサーバ側通信バッファに格納する処理と、前記サーバ側通信バッファに格納された全てのレコードを前記クライアントコンピュータに一括して送信する処理と、最終のレコードを前記データ記憶装置から未だ取り出していないときは前記クライアントコンピュータからの依頼を待たずに前記クライアントコンピュータに送信する予定の複数のレコードを前記データ記憶装置から先読みして前記レコードバッファに格納すると共に前記変換処理を行って前記サーバ側通信バッファに格納する処理とを行うサーバシステムを備えることを特徴とする。
【００１５】
本発明の第３のレコード先読み制御システムは、第１または第２のレコード先読み制御システムにおいて、前記クライアントコンピュータは、前記サーバコンピュータから受信した複数のレコードをクライアント側通信バッファに格納し、該クライアント側通信バッファからレコードを１つずつ読み出してユーザプログラムに返却し、ユーザプログラムに返却するレコードが前記クライアント側通信バッファに存在しない場合には次のレコードの読み込みを前記サーバコンピュータに依頼することを特徴とする。
【００１６】
本発明の第１のサーバコンピュータは、ネットワークを介してクライアントコンピュータに接続されたサーバコンピュータにおいて、前記クライアントコンピュータと通信するための送受信手段、サーバ側通信バッファおよび制御手段を備えるサーバシステムと、データを記憶するデータ記憶装置とを有し、前記サーバシステムは、前記クライアントコンピュータからレコードの読み込み依頼を受けたときに前記データ記憶装置から複数のレコードを先読みして前記サーバ側通信バッファに格納する処理と、前記サーバ側通信バッファに格納された全てのレコードを前記クライアントコンピュータに一括して送信する処理と、最終のレコードを前記データ記憶装置から未だ取り出していないときは前記クライアントコンピュータからの依頼を待たずに前記クライアントコンピュータに送信する予定の複数のレコードを前記データ記憶装置から先読みして前記サーバ側通信バッファに格納する処理とを行う。
【００１７】
本発明の第２のサーバコンピュータは、ネットワークを介してクライアントコンピュータに接続されたサーバコンピュータにおいて、前記クライアントコンピュータと通信するための送受信手段、サーバ側通信バッファ、レコードバッファ、データ変換処理手段および制御手段を備えるサーバシステムと、データを記憶するデータ記憶装置とを有し、前記サーバシステムは、前記クライアントコンピュータからレコードの読み込み依頼を受けたときに前記データ記憶装置から複数のレコードを先読みして前記レコードバッファに格納する処理と、前記レコードバッファに格納された各レコード中のデータに対するデータ型の変換を行う処理と、該変換処理済みのレコードを前記サーバ側通信バッファに格納する処理と、前記サーバ側通信バッファに格納された全てのレコードを前記クライアントコンピュータに一括して送信する処理と、最終のレコードを前記データ記憶装置から未だ取り出していないときは前記クライアントコンピュータからの依頼を待たずに前記クライアントコンピュータに送信する予定の複数のレコードを前記データ記憶装置から先読みして前記レコードバッファに格納すると共に前記変換処理を行って前記サーバ側通信バッファに格納する処理とを行う。
【００１８】
本発明の第１のサーバ用プログラムは、ネットワークを介してクライアントコンピュータに接続され、前記クライアントコンピュータと通信するための送受信手段、サーバ側通信バッファ、データ記憶装置を備えたサーバコンピュータに、前記クライアントコンピュータからレコードの読み込み依頼を受けたときに前記データ記憶装置から複数のレコードを先読みして前記サーバ側通信バッファに格納する処理、前記サーバ側通信バッファに格納された全てのレコードを前記クライアントコンピュータに一括して送信する処理、最終のレコードを前記データ記憶装置から未だ取り出していないときは前記クライアントコンピュータからの依頼を待たずに前記クライアントコンピュータに送信する予定の複数のレコードを前記データ記憶装置から先読みして前記サーバ側通信バッファに格納する処理、を実行させる。
【００１９】
本発明の第２のサーバ用プログラムは、ネットワークを介してクライアントコンピュータに接続され、前記クライアントコンピュータと通信するための送受信手段、サーバ側通信バッファ、レコードバッファ、データ記憶装置を備えたサーバコンピュータに、前記クライアントコンピュータからレコードの読み込み依頼を受けたときに前記データ記憶装置から複数のレコードを先読みして前記レコードバッファに格納する処理、前記レコードバッファに格納された各レコード中のデータに対するデータ型の変換を行う処理、該変換処理済みのレコードを前記サーバ側通信バッファに格納する処理、前記サーバ側通信バッファに格納された全てのレコードを前記クライアントコンピュータに一括して送信する処理、最終のレコードを前記データ記憶装置から未だ取り出していないときは前記クライアントコンピュータからの依頼を待たずに前記クライアントコンピュータに送信する予定の複数のレコードを前記データ記憶装置から先読みして前記レコードバッファに格納すると共に前記変換処理を行って前記サーバ側通信バッファに格納する処理、を実行させる。
【００２０】
【作用】
本発明にあっては、クライアントコンピュータからレコードの読み込み依頼を受けたときにサーバコンピュータが、データ記憶装置から複数のレコードを先読みしてクライアントコンピュータに一括して送信した後、最終のレコードをデータ記憶装置から未だ取り出していないときは、クライアントコンピュータからの依頼を待たずに、クライアントコンピュータに送信する予定の複数のレコードをデータ記憶装置から先読みして、送信によって空きになったサーバ側通信バッファに格納しておくため、クライアントコンピュータから実際に依頼があったときには直ちに次の複数のレコードを送信することができる。これによって、ユーザプログラムに渡すべきレコード数が多く、クライアント側の通信バッファに何度も先読みする必要がある場合でもレスポンス良くレコードをユーザプログラムに返却することができる。特に、サーバが先読みしたレコードをそのままクライアントに渡すのではなく、レコード中のデータのデータ型を変換してからクライアントに渡す場合、データ型の変換処理を行う時間も隠蔽され、レスポンスの悪化が防止される。
【００２１】
【発明の実施の形態】
次に本発明の第１の実施の形態について図面を参照して詳細に説明する。
【００２２】
図１を参照すると、本発明の第１の実施の形態は、クライアントコンピュータ１０１とサーバコンピュータ５０１とがＬＡＮ、ＷＡＮ、電話回線、インターネット等のネットワーク４０１を通じて相互に通信可能に接続されており、クライアントコンピュータ１０１には、ユーザプログラム２０１およびＤＢクライアントシステム３０１が設けられ、サーバコンピュータ５０１には、ＤＢサーバシステム６０１、ＤＢＭＳ７０１およびＤＢ８０１が設けられている。なお、ＤＢはデータベースの略称、ＤＢＭＳはデータベース管理システムの略称である。
【００２３】
ＤＢクライアントシステム３０１は、ユーザプログラム２０１がＤＢ８０１をクライアント・サーバ方式でアクセスする際のクライアント側の機能を提供するシステムであり、ＤＢサーバシステム６０１との間でネットワーク４０１経由でレコード読み込み要求などの情報の送信および検索結果のレコードなどの情報の受信を行う送信手段３０２および受信手段３０３と、ＤＢサーバシステム６０１から受信したレコードを複数レコード分格納し得る容量を持つ通信バッファ３０４と、ＤＢクライアントシステム３０１の主たる制御を司ると共に、通信バッファ３０４に先読みされた複数のレコードを１レコード単位に分割してユーザプログラム２０１に返却するレコード先読み結果分割機能を有する制御手段３０５とを含んで構成される。
【００２４】
ＤＢサーバシステム６０１は、ユーザプログラム２０１がＤＢ８０１をクライアント・サーバ方式でアクセスする際のサーバ側の機能を提供するシステムであり、ＤＢクライアントシステム３０１との間でネットワーク４０１経由で検索結果のレコードなどの情報の送信およびレコード読み込み要求などの情報の受信を行う送信手段６０２および受信手段６０３と、ＤＢクライアントシステム３０１へ送信するレコードを複数レコード分格納し得る容量を持つ通信バッファ６０４と、ＤＢサーバシステム６０１の主たる制御を司ると共に、ＤＢＭＳ７０１を通じてＤＢ８０１からレコードを先読みするレコード先読み機能を有する制御手段６０５とを含んで構成される。
【００２５】
次に、図２を参照して本実施の形態の概略動作を説明する。
【００２６】
今、クライアントコンピュータ１０１のユーザプログラム２０１がＤＢ８０１から一連のレコードを１件ずつ読み込んで処理することを考える。この場合、ユーザプログラム２０１からＤＢ８０１に対する最初のレコードの読み込み要求Ｒ１１が発生すると、ＤＢクライアントシステム３０１がネットワーク４０１経由でサーバコンピュータ５０１のＤＢサーバシステム６０１に対して最初の読み込み要求Ｒ２１を送信する。
【００２７】
ＤＢサーバシステム６０１は、読み込み要求Ｒ２１を受信すると、検索要求Ｒ３１をＤＢＭＳ７０１に対して送出して複数のレコードをＤＢ８０１からＤＢＭＳ７０１を通じてまとめて受取り、通信バッファ６０４に一旦格納する。次いで、通信バッファ６０４に格納した全てのレコードを読み込み要求Ｒ２１に対する応答としてネットワーク４０１経由でクライアントコンピュータ１０１へ送信する。そして、この送信により通信バッファ６０４が空になるので、最後のレコードをＤＢ８０１から未だ取得していない場合には、検索要求Ｒ３２をＤＢＭＳ７０１に対して送出することにより更に複数のレコードをＤＢ８０１から先読みして通信バッファ６０４に格納しておく。
【００２８】
他方、クライアントコンピュータ１０１のＤＢクライアントシステム３０１は、ＤＢサーバシステム６０１から送られてきた複数のレコードを通信バッファ３０４に一旦格納し、その格納された複数のレコードから１つのレコードを取り出し、読み込み要求Ｒ１１に対する応答としてユーザプログラム２０１に返却する。また、ユーザプログラム２０１から次の１件のレコードの読み込み要求Ｒ１２が発生すると、通信バッファ３０４に残っているレコードから１つのレコードを取り出し、読み込み要求Ｒ１２に対する応答としてユーザプログラム２０１に返却する。このような動作は、通信バッファ３０４に格納されているレコードが無くなるまで繰り返される。そして、通信バッファ３０４中の全てのレコードの返却を終えると、その直後にユーザプログラム２０１から出された読み込み要求Ｒ１ｎのときに、ＤＢサーバシステム６０１に対して次の複数のレコードを要求する読み込み要求Ｒ２２をネットワーク４０１経由で送信する。
【００２９】
ＤＢサーバシステム６０１は、この読み込み要求Ｒ２２に対して、既に通信バッファ６０４に先読みしてある複数のレコードをネットワーク４０１経由でＤＢクライアントシステム３０１に送信する。この送信された複数のレコードはＤＢクライアントシステム３０１の通信バッファ３０４に一旦格納され、前述と同様に１レコード毎に分割されてユーザプログラム２０１に返却される。
【００３０】
次に図３を参照して、ＤＢサーバシステム６０１の処理内容を詳しく説明する。ＤＢサーバシステム６０１における制御手段６０５は、ＤＢクライアントシステム３０１から最初の読み込み要求（図２のＲ２１に相当する）を受けると、図３の処理を開始する（１１００）。先ず、内部で使用する変数ＢＵＦを０に、変数ＤＡＴを１にそれぞれ初期化する（１１０１）。ここで、変数ＢＵＦは通信バッファ６０４に送信予定のレコード群が格納済みか否かを管理するためのもので、０は送信予定のレコード群が通信バッファ６０４に存在しないことを示し、１は存在することを示す。変数ＤＡＴは最終レコードの取り出しを終えたか否かを管理するもので、０は最終レコードの取り出しを終えていることを示し、１は終えていないことを示す。
【００３１】
次に、制御手段６０５は、ＤＢクライアントシステム３０１からの読み込み要求の監視を行い（１１０２）、読み込み要求が出ていれば（１１０３でＹＥＳ）、ステップ１１０４へ分岐して読み込み要求の有無を管理するための変数ＲＥＱの値を１に設定し、読み込み要求が出ていなければ（１１０３でＮＯ）、ステップ１１０５へ分岐して変数ＲＥＱの値を０に設定する。
【００３２】
次に、制御手段６０５は、変数ＢＵＦの値を判定し（１１０５）、１に等しくなければ、つまり通信バッファ６０４に送信予定のレコード群がなければ、ステップ１１０７へ分岐し、１に等しければ、つまり通信バッファ６０４に送信予定のレコード群が格納されていれば、ステップ１１１２へ分岐する。
【００３３】
ステップ１１０７へ分岐した場合、制御手段６０５は、ＤＢクライアントシステム３０１から要求される検索条件等に従い、ＤＢＭＳ７０１から要求を満たすレコードを所定量まとめて要求する。ここで、所定量は予めシステムで定義される。本例では例えば８ＫＢ分のレコードとする。勿論、容量で規定するのではなく、レコード数で規定しても良い。次に、ＤＢＭＳ７０１から返却されたレコード群中に最終レコードが含まれているか否かを判定し（１１０８）、最終レコードが含まれていれば（１１０８でＹＥＳ）、変数ＤＡＴを０に設定してその旨を管理して（１１０９）ステップ１１１０へ進み、最終レコードが含まれていなければステップ１１０９をスキップしてステップ１１１０へ進む。ステップ１１１０では、ＤＢＭＳ７０１から返却されたレコード群を通信バッファ６０４へ保存する。そして、変数ＢＵＦに１を設定して（１１１１）、ステップ１１１２へと進む。
【００３４】
ステップ１１１２では、制御手段６０５は、変数ＲＥＱの値を判定し、１に等しければ、つまりＤＢクライアントシステム３０１から読み込み要求が出ていれば、ステップ１１１３へ分岐し、１に等しくなければ、つまりＤＢクライアントシステム３０１から読み込み要求が出ていなければ、ステップ１１０２へ分岐して前述した処理を繰り返す。
【００３５】
ステップ１１１３へ分岐した場合、制御手段６０５は、通信バッファ６０４の内容すべてを送信手段６０２を通じてネットワーク４０１経由でＤＢクライアントシステム３０１へ送信する。この送信により通信バッファ６０４が空になったので、変数ＢＵＦを０に設定する（１１１４）。そして、変数ＤＡＴの値を判定し（１１１５）、０に等しければ、つまり最終レコードの取り出しを終えており全てのレコードのクライアントへの送信を終えていれば、処理を終了し（１１１６）、０に等しくなければ、つまり最終レコードの取り出しが終っていなければステップ１１０２へ分岐して上述した処理を繰り返す。
【００３６】
次に、図４を参照してＤＢクライアントシステム３０１の処理内容を詳しく説明する。ＤＢクライアントシステム３０１における制御手段３０５は、ユーザプログラム２０１から最初の読み込み要求（図２のＲ１１に相当する）があったときに図４の処理を開始する（１２００）。先ず、内部変数である変数ＥＭＰＴＹを１に初期化する。ここで、変数ＥＭＰＴＹは、通信バッファ３０４にレコードが１件も存在しないかどうかを管理するためのもので、１は１件も存在しないことを示し、０は少なくとも１件は存在することを示す。
【００３７】
次に制御手段３０５は、ユーザプログラム２０１からの読み込み要求の監視を行い（１２０２）、読み込み要求が出ていれば（１２０３でＹＥＳ）、ステップ１２０４へ分岐し、読み込み要求が出ていなければ（１２０３でＮＯ）、ステップ１２０２へ分岐して読み込み要求の監視を続ける。
【００３８】
読み込み要求があったためにステップ１２０４へ分岐した場合、制御手段３０５は、変数ＥＭＰＴＹの値を判定し、１に等しければ、つまり通信バッファ３０４に１件もレコードが存在しなければ、ステップ１２０５へ分岐してＤＢサーバシステム６０１へ送信手段３０２を通じて読み込み要求を発行する。そして、ステップ１２０６へ進む。この読み込み要求の発行により、最大８ＫＢ分のレコードがＤＢサーバシステム６０１から返却されるので、受信手段３０３を通じてそのレコード群を通信バッファ３０４に格納する。他方、変数ＥＭＰＴＹの値が１に等しくなければ、つまり、通信バッファ３０４に少なくとも１件のレコードが存在すれば、ステップ１２０５をスキップして、ステップ１２０６へと進む。
【００３９】
ステップ１２０６では、制御手段３０５は、通信バッファ３０４からレコードを１件読み込み、次のステップ１２０７で、ユーザプログラム３０５へこのレコード１件を返却する。そして、今回返却したレコードが最終レコードか否かを判定し（１２０８）、最終レコードでなければ（１２０８でＮＯ）、ステップ１２０９へ分岐し、最終レコードであれば（１２０８でＹＥＳ）、処理を終了する（１２１２）。ステップ１２０９では、通信バッファ３０４が空か否かを判定し、通信バッファ３０４が空であれば（１２０９でＹＥＳ）、変数ＥＭＰＴＹに１を設定してその旨を管理し（１２１０）、通信バッファ３０４が空でなければ（１２０９でＮＯ）、変数ＥＭＰＴＹに０を設定してその旨を管理し、それぞれステップ１２０２に戻って上述した処理を繰り返す。
【００４０】
次に、本実施の形態の具体的な動作を説明する。例としては、ＤＢ８０１がリレーショナルデータベースであり、ユーザプログラム２０１においてＳＱＬ文によるカーソル定義で指定した検索条件を満足する複数のレコード群をＦＥＴＣＨ文でユーザプログラム２０１が１レコードずつ読み込む場合を採りあげる。
【００４１】
図５は、埋め込みＳＱＬ文を用いてＤＢクライアントシステム３０１及びＤＢサーバシステム６０１を介してＤＢＭＳ７０１をアクセスするユーザプログラム２０１の内容例１３００をソースイメージで示す。なお、埋め込みＳＱＬ文には通常、先頭に「ＥＸＥＣ ＳＱＬ」が付けられるが図５では省略している。
【００４２】
図５において、１３０１は、ＤＢＭＳ７０１への問い合わせ条件を示すカーソル宣言文であり、検索条件（ＳＥＬＥＣＴ節以降）とカーソル名「ＣＳＲ１」とを対応付けている。ここでは、カラムＣ１の値が１００であるテーブルＴＢＬ１のカラムＣＯＬ１、ＣＯＬ２を検索するものとしている。このカーソル宣言文１３０１の実行時、ＤＢクライアントシステム３０１からＤＢサーバシステム６０１にカーソル宣言文の内容が送られ、ＤＢＭＳ７０１に登録される。１３０２は、カーソル宣言文１３０１で宣言したカーソルＣＳＲ１の利用の開始を示すＯＰＥＮ文である。このＯＰＥＮ文１３０２の実行時、ＤＢクライアントシステム３０１からＤＢサーバシステム６０１にカーソルＣＳＲ１のオープンが指示され、ＤＢＭＳ７０１により、カーソル定義文１３０１で定義された検索条件による検索結果のレコード群を格納した仮想的な表がＤＢ８０１に生成される。１３０３は、データの最後を示すＳＱＬＣＯＤＥ＝１００までの間繰り返し実行することを示すループ処理であり、ＣＯＢＯＬ、Ｃ等のホスト言語によって記述される。１３０４は、前記仮想的な表から１行（１レコード）を読み取るためのＦＥＴＣＨ文である。ここでは、ホスト変数としてＨ１、Ｈ２が指定されており、検索されたカラムＣＯＬ１、ＣＯＬ２の値がそれぞれＨ１、Ｈ２に設定されてユーザプログラム２０１に返される。なお、１レコードは、カラムＣＯＬ１、ＣＯＬ２の値のペアになる。１３０５は、カーソルＣＳＲ１の利用の終了を示すＣＬＯＳＥ文である。
【００４３】
カーソル宣言文１３０１、オープン文１３０２、クローズ文１３０５に関連する処理は従来と同じなので、以下では、ＷＨＩＬＥ文１３０３とＦＥＴＣＨ文１３０４の箇所に関連する動作を説明する。なお、説明の便宜上、カーソル宣言文１３０１で指定された検索条件を満たすレコードの総容量は２０ＫＢであったものとし、検索された１つのレコードの容量は１ＫＢとする。即ち、合計２０件（２０行）のレコードが検索されたものと仮定する。
【００４４】
先ず、ＤＢクライアントシステム３０１側の動作を説明する。
【００４５】
ユーザプログラム２０１において最初のＦＥＴＣＨ文１３０４が実行されると、ＤＢクライアントシステム３０１における制御手段３０５は図４の処理を開始する（１２００）。先ず制御手段３０５は、変数ＥＭＰＴＹに１を設定し（１２０１）、読み込み要求の監視を行う（１２０２）。この時点でユーザプログラム２０１から最初の読み込み要求が出ているので、ステップ１２０３における読み込み要求の判定はＹＥＳとなり、ステップ１２０４へ分岐する。
【００４６】
ステップ１２０４における変数ＥＭＰＴＹ＝＝１の判定はＹＥＳであるため、制御手段３０５はＤＢサーバシステム６０１に対して、カーソル名ＣＳＲ１を指定して、次のレコード群を渡す旨の読み込み要求を発行する（１２０５）。この読み込み要求に対してＤＢサーバシステム６０１から８ＫＢ分の検索結果、つまり８件分の検索レコードが返却されるので、それが受信手段３０３により通信バッファ３０４に格納される。制御手段３０５は、通信バッファ３０４から１件のレコードを読み込み（１２０６）、この１件のレコードをユーザプログラム２０１へ返却する（１２０７）。
【００４７】
ユーザプログラム２０１では、１回目のＦＥＴＣＨ文１３０４の処理が終了すると、ＷＨＩＬＥ文１３０３のループ処理によって再度、ＦＥＴＣＨ文１３０４の処理が繰り返される。
【００４８】
一方、ＤＢクライアントシステム３０１の制御手段３０５は、先に返却したレコードがＤＢＭＳ７０１での最終レコードでなく（１２０８でＮＯ）、また通信バッファ３０４が空でないので（１２０９でＮＯ）、変数ＥＭＰＴＹに０を設定し（１２１１）、ステップ１２０２へ分岐する。そして、このステップ１２０２でユーザプログラム２０１からの読み込み要求を監視し、ユーザプログラム２０１のＦＥＴＣＨ文１３０４で次の読み込み要求が実行されていれば、ステップ１２０３からステップ１２０４へ分岐し、変数ＥＭＰＴＹの値が０であるため、ステップ１２０６へ分岐し、通信バッファ３０４より検索結果として次の１件のレコード（２件目のレコード）を読み込む。このように、通信バッファ３０４が空でない間は、ＤＢサーバシステム６０１への読み込み要求を行わずに通信バッファ３０４から次の１件のレコードを読み込み、ユーザプログラム２０１へ返却する。そして、８件目のレコードをユーザプログラム２０１に返却し、通信バッファ３０４が空になった時点で、ステップ１２０９からステップ１２１０へ分岐して変数ＥＭＰＴＹに１を設定し、ステップ１２０２へ分岐する。
【００４９】
従って、ユーザプログラム２０１から次の読み込み要求が出た場合には、変数ＥＭＰＴＹが１なので、制御手段３０５はＤＢサーバシステム６０１へ２回目の読み込み要求を発行する（１２０５）。この読み込み要求に対してＤＢサーバシステム６０１から次の８ＫＢ分の検索結果、つまり８件分の検索レコードが返却されるので、それが受信手段３０３により通信バッファ３０４に格納され、その中から１件のレコードが取り出されてユーザプログラム２０１に返却される（１２０７）。以後、ユーザプログラム２０１から検索要求があると、通信バッファ３０４が空になるまで、通信バッファ３０４から１件ずつレコードを読み出して返却する。
【００５０】
そして再び通信バッファ３０４が空になると、未だ最終レコードの返却を終えていないので、制御手段３０５はＤＢサーバシステム６０１へ３回目の読み込み要求を発行する（１２０５）。この読み込み要求に対してＤＢサーバシステム６０１から最終レコードを含む４ＫＢ分の検索結果、つまり４件分のレコードが返却されるので、それがＤＢクライアントシステム３０１の通信バッファ３０４に格納され、その中から１件のレコードが取り出されてユーザプログラム２０１に返却される（１２０７）。以後、ユーザプログラム２０１から読み込み要求がある毎に、通信バッファ３０４から１件ずつレコードを取り出して返却する（１２０７）。そして、最終レコードの返却を終えると、制御手段３０５は処理を終える（１２１２）。
【００５１】
次にＤＢサーバシステム６０１側の動作を説明する。
【００５２】
ＤＢサーバシステム６０１では、ＤＢクライアントシステム３０１から最初の読み込み要求が発行されると、図３の処理が開始される（１１００）。まず、制御手段６０５は、変数ＢＵＦを０、変数ＤＡＴを１の値にそれぞれ初期設定し（１１０１）、ステップ１１０２、１１０３でＤＢクライアントシステム３０１からの最初の読み込み要求を認識し、変数ＲＥＱを１に設定する（１１０４）。そして、変数ＢＵＦの値が０であるため（１１０５でＮＯ）、制御手段６０５はＤＢＭＳ７０１へ要求を実行し、検索条件を満たす複数レコードを、最大８ＫＢ分まとめて受け取る。受け取った８件分のレコードに最終レコードが含まれていないので（１１０８でＮＯ）、制御手段６０５はステップ１１０９をスキップしてステップ１１１０に進み、受け取った８件分のレコードを通信バッファ６０４へ保存し、変数ＢＵＦを１に設定する（１１１１）。そして、ＲＥＱの値が１であるため（１１１２でＹＥＳ）、通信バッファ６０４の内容を送信手段６０２によりＤＢクライアントシステム３０１へ送信し（１１１３）、変数ＢＵＦを０に設定し（１１１４）、変数ＤＡＴが０でないので（１１１５でＮＯ）、ステップ１１０２に分岐する。
【００５３】
次に、制御手段６０５は、ＤＢクライアントシステム３０１からの２回目の読み込み要求を監視するが、送信直後は未だ２回目の読み込み要求がなされていないので変数ＲＥＱに０を設定し（１１０５）、ステップ１１０５へ進む。このステップ１１０５において、変数ＢＵＦの値が１か否かの判定を行うが、変数ＢＵＦの値が１であるためステップ１１０７へ分岐し、ＤＢクライアントシステム３０１からの次の２回目の読み込み要求を待たずに、ＤＢＭＳ７０１の検索を実施する（１１０７）。つまり、制御手段６０５はＤＢＭＳ７０１から検索条件を満たす残りの複数レコードを、最大８ＫＢ分まとめて受け取る。今度も、受け取った８件分のレコードに最終レコードが含まれていないので（１１０８でＮＯ）、ステップ１１０９をスキップしてステップ１１１０に進み、受け取った８件分のレコードを通信バッファ６０４へ保存し、変数ＢＵＦを１に設定する（１１１１）。そして、変数ＲＥＱの値が１か否かを判定するが、ＤＢクライアントシステム３０１から未だ２回目の読み込み要求が発行されておらず、変数ＲＥＱが１になっていないので、制御手段６０５はステップ１１０２に分岐する。ＤＢクライアントシステム３０１から２回目の読み込み要求が発行されない状態が続く間、変数ＲＥＱの値は１にならず、また変数ＢＵＦが１になっているため、制御手段６０５はステップ１１０２→１１０３→１１０５→１１０６→１１１２→１１０２のループを回っている。
【００５４】
そして、ＤＢクライアントシステム３０１から２回目の読み込み要求が発行されると、制御手段６０５はそれをステップ１１０２、１１０３で検出し、変数ＲＥＱを１に設定する（１１０４）。これにより上記のループを抜け出てステップ１１１３に進み、通信バッファ６０４に先読みしてあった８ＫＢ分の検索結果をＤＢクライアントシステム３０１に送信する。そして、変数ＢＵＦを０に設定し（１１１４）、変数ＤＡＴは未だ１のままなので、ステップ１１０２に分岐する。
【００５５】
制御手段６０５は、ＤＢクライアントシステム３０１からの次の読み込み要求を監視するが、送信直後は未だ３回目の読み込み要求がなされていないので変数ＲＥＱに０を設定し（１１０５）、ステップ１１０５へ進む。このステップ１１０５において、変数ＢＵＦの値が１か否かの判定を行うが、変数ＢＵＦの値が０であるためステップ１１０７へ分岐し、ＤＢクライアントシステム３０１からの次の３回目の読み込み要求を待たずにレコード先読み処理を行うべく、ＤＢＭＳ７０１から検索条件を満たす残りの４ＫＢ分のレコードをまとめて受け取る。今回は、受け取った検索結果中に最終レコードが含まれているので（１１０８でＹＥＳ）、ステップ１１０９で変数ＤＡＴを０に設定してステップ１１１０に進み、受け取った４件分の検索結果を通信バッファ６０４へ保存し、変数ＢＵＦを１に設定する（１１１１）。そして、変数ＲＥＱの値が１か否かを判定するが、ＤＢクライアントシステム３０１から未だ３回目の読み込み要求が発行されておらず、変数ＲＥＱが１になっていないので、制御手段６０５はステップ１１０２に分岐する。ＤＢクライアントシステム３０１から３回目の読み込み要求が発行されない状態が続く間、変数ＲＥＱの値は１にならず、また変数ＢＵＦが１になっているため、制御手段６０５はステップ１１０２→１１０３→１１０５→１１０６→１１１２→１１０２のループを回っている。
【００５６】
そして、ＤＢクライアントシステム３０１から３回目の読み込み要求が発行されると、制御手段６０５はそれをステップ１１０２、１１０３で検出し、変数ＲＥＱを１に設定する（１１０４）。これにより上記のループを抜け出てステップ１１１３に進み、通信バッファ６０４に先読みしてあった４ＫＢ分のレコードをＤＢクライアントシステム３０１に送信する。次に、変数ＢＵＦを０に設定し（１１１４）、変数ＤＡＴの値を判定する（１１１５）。今回は変数ＤＡＴは０に設定されているので、制御手段６０５は処理を終了する（１１１６）。
【００５７】
【発明の他の実施の形態】
次に本発明の第２の実施の形態について図面を参照して詳細に説明する。
【００５８】
図６を参照すると、本発明の第２の実施の形態は、ＤＢサーバシステム６０１における制御手段６０５と通信バッファ６０４との間にレコードバッファ６０６及びデータ変換処理手段６０７を備えている点で第１の実施の形態と相違する。
【００５９】
図７を参照すると、本実施の形態におけるＤＢサーバシステム６０１の処理は、図３に示した処理と比べて、ステップ１１１０の処理内容が検索結果を通信バッファ６０４でなくレコードバッファ６０６に格納するよう変更され、また、ステップ１１１０の直後にステップ１１１７、１１１８が追加されている点で相違する。
【００６０】
レコードバッファ６０６は、検索結果のレコードを複数レコード分格納し得る容量を持つ。第１の実施の形態では、制御手段６０５はＤＢＭＳ７０１を通じてＤＢ８０１から検索した複数レコードを通信バッファ６０４に格納したが、本実施の形態ではレコードバッファ６０６に格納する（１１１０）。
【００６１】
データ変換処理手段６０７は、レコードバッファ６０６に格納された個々の検索結果のデータ型をＤＢクライアントシステム３０１の要求するデータ型へ変換し、この変換処理後の個々の検索結果を通信バッファ６０４に格納する機能を有する。どのようなデータ型へ変換するかはユーザプログラム２０１で指定する。この指定は例えば図５におけるカーソル宣言文１３００において行うことができ、その場合、カーソル宣言文１３００の内容がＤＢサーバシステム６０１に通知される際に、変換するデータ型の情報がデータ変換処理手段６０７に設定される。なお、レコードに複数のフィールド（カラム）があるとき、フィールド単位で変換の有無、データ型の指定が可能である。
【００６２】
次に本実施の形態の動作を第１の実施の形態との相違点を中心に説明する。
【００６３】
ＤＢサーバシステム６０１の制御手段６０５は、ステップ１１０７でＤＢＭＳ７０１に対して出した検索要求に対してＤＢＭＳ７０１から複数のレコードを受け取ると、それをレコードバッファ６０６に格納する（１１１０）。次にデータ変換処理手段６０７は、レコードバッファ６０６からレコードを順次に読み出し、そのレコード中の要求されたフィールドのデータの型を要求されたデータ型に変換して通信バッファ６０４に格納する。こうして格納された変換処理後の複数のレコードは第１の実施の形態と同様にＤＢクライアントシステム３０１に一括して送信される。この変換処理は先読み処理の過程で実施されるため、変換処理時間の隠蔽化が可能になり、スループットが向上する。
【００６４】
以上の説明では、レコードを取り出すデータ記憶装置としてリレーショナルデータベースを例にしたが、他の種類のデータベースであっても良いし、前記特開平６−９６０３３号公報や前記特開平４−１８４６５２号公報と同様にファイルであって良い。
【００６５】
以上本発明の実施の形態について説明したが、本発明は以上の実施の形態にのみ限定されずその他各種の付加変更が可能である。例えば、前記の実施の形態ではサーバコンピュータ５０１は１つのクライアントコンピュータ１０１に接続されているが、一般には複数のクライアントコンピュータに接続され得る。その場合、サーバコンピュータ５０１には複数のＤＢサーバシステム６０１が設けられ、これらが並行して動作する。
【００６６】
また、本発明にかかるＤＢサーバシステム６０１およびＤＢクライアントシステム３０１は、ハードウェアで実現しても良いし、コンピュータ上で動作するプログラムで実現しても良い。後者の場合、サーバ用プログラムおよびクライアント用プログラムは、磁気ディスク、半導体メモリ等のコンピュータ可読記録媒体に記録されて提供されるか、ネットワークを通じて提供される。サーバ用プログラムは、サーバコンピュータに読み込まれ、そのコンピュータの動作を制御することにより、そのコンピュータ上に前述した各実施の形態におけるＤＢサーバシステム６０１を実現する。同様に、クライアント用プログラムは、クライアントコンピュータに読み込まれ、そのコンピュータの動作を制御することにより、そのコンピュータ上に前述した各実施の形態におけるＤＢクライアントシステム３０１を実現する。
【００６７】
【発明の効果】
以上説明したように本発明によれば、ユーザプログラムに渡すべきレコード数が多く、クライアント側のバッファに何度も先読みする必要がある場合でもレスポンス良くレコードをユーザプログラムに返却することができる。その理由は、クライアントコンピュータからレコードの読み込み依頼を受けたときにサーバコンピュータが、データ記憶装置から複数のレコードを先読みしてクライアントコンピュータに一括して送信した後、最終のレコードをデータ記憶装置から未だ取り出していないときは、クライアントコンピュータからの依頼を待たずに、クライアントコンピュータに送信する予定の複数のレコードをデータ記憶装置から先読みして、送信によって空きになったサーバ側通信バッファに格納しておくため、クライアントから実際に依頼があったときには直ちに次の複数のレコードをクライアントに送信することができるからである。
【００６８】
また本発明によれば、サーバが先読みしたレコードをそのままクライアントに渡すのではなく、レコード中のデータのデータ型を変換してからクライアントに渡す場合でも、レスポンス良くレコードをユーザプログラムに返却することができる。その理由は先読み処理の過程でデータ型の変換処理を行うため変換処理時間が隠蔽されるためである。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態の構成を示すブロック図である。
【図２】本発明の第１の実施の形態の概略動作の説明図である。
【図３】本発明の第１の実施の形態におけるＤＢサーバシステムの処理例を示す流れ図である。
【図４】本発明の第１の実施の形態におけるＤＢクライアントシステムの処理例を示す流れ図である。
【図５】本発明の第１の実施の形態におけるユーザプログラムの一例を示す図である。
【図６】本発明の第２の実施の形態の構成を示すブロック図である。
【図７】本発明の第２の実施の形態におけるＤＢサーバシステムの処理例を示す流れ図である。
【符号の説明】
１０１ クライアントコンピュータ
２０１ ユーザプログラム
３０１ ＤＢクライアントシステム
３０２ 送信手段
３０３ 受信手段
３０４ 通信バッファ
３０５ 制御手段
４０１ ネットワーク
５０１ サーバコンピュータ
６０１ ＤＢサーバシステム
６０２ 送信手段
６０３ 受信手段
６０４ 通信バッファ
６０５ 制御手段
６０６ レコードバッファ
６０７ データ変換処理手段
７０１ ＤＢＭＳ
８０１ ＤＢ[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a method for controlling prefetching of records in a data storage device in a client-server system suitable for accessing a data storage device such as a database provided in a server computer from a client computer via a network.
[0002]
[Prior art]
As a conventional record prefetch control method of this type, a method described in Japanese Patent Application Laid-Open No. 6-96033 (hereinafter, referred to as a first prior art) and a method described in Japanese Patent Application Laid-Open No. , A second prior art), and a method described in Japanese Patent Application Laid-Open No. 4-184652 (hereinafter, referred to as a third prior art).
[0003]
In the first related art, a client that has received a request to read one record from a user program requests a server to read a plurality of records including the requested record and subsequent records. Read out the record from the file and send it to the client. After accumulating the received records in the buffer, the client returns the requested one record to the user program. When the client receives a request to read one record from the user program, the client retrieves the next record from the buffer and returns to the user program. Return to the program. When all the contents of the buffer have been returned and the record requested by the user is no longer in the buffer, the client sends a request to the server to read a plurality of records, the requested record and subsequent records, as in the first case. The server reads the corresponding records from the file and sends them to the client as in the previous case.
[0004]
The second prior art is also basically the same as the first prior art. When a program executed on a client computer accesses a file held in a server computer, the client computer generates the program on the client computer. A buffer having a data length larger than the access data length of one access request to be transmitted, and means for controlling transfer of access request data between the program and the buffer. File data is transferred using a large data length as a transfer unit.
[0005]
The third prior art is also basically the same as the first prior art. When a command for instructing sequential reading is sent from the terminal computer, the host computer reads a plurality of records from the file and collectively reads them. The data is transferred to the terminal computer, and the terminal computer stores it in the reception buffer. Each time the user program issues a command to instruct sequential reading, the terminal computer retrieves one record from the reception buffer and returns it to the user program. Then, when the receiving buffer becomes empty, a command for instructing sequential reading is sent to the host computer as in the previous case, and the host computer reads a plurality of records from the file again and transfers them to the terminal computer.
[0006]
On the other hand, although it is not a client-server type record prefetching method, Japanese Patent Application Laid-Open No. 62-259135 discloses a function of storing a record group consisting of one or more fields in a database, and a record of a condition specified from the database. In a database management system having a function of searching for records, when a record search request is made from a user program, a plurality of records are searched in one call, and the records of the search results are collectively transferred to the user program side A method is described. Here, if the database management system side is replaced with a server and the user program side is replaced with a client, a search result of a plurality of records is returned from the server in one call from the client. This is a method similar to the prior art.
[0007]
[Problems to be solved by the invention]
As described above, the record prefetch control of the client-server method has been conventionally proposed. However, in the above-described conventional technology, the number of records to be passed to the user program is large, and it is necessary to prefetch the buffer many times in the client side. In some cases, there is a problem that the response to the user program deteriorates when the buffer becomes empty. The reason is that when it detects that the buffer is empty and there are no records to be returned to the user program in the buffer, the client issues a read request to the server for the next record, and the server receives this request and This is because the next plurality of records are read from the database and transmitted to the client, and it takes a long time to be pre-read in the buffer on the client side.
[0008]
Also, when the server does not pass the record obtained from a file or the like to the client as it is, but converts the data type of the data in the record and then passes it to the client, it takes time to perform data type conversion processing. The response will be worse.
[0009]
The present invention has been proposed in view of such circumstances, and its purpose is to increase the number of records to be passed to the user program, even when it is necessary to prefetch many times in the buffer on the client side, The object is to enable a record to be returned to a user program with good response.
[0010]
[Means for Solving the Problems]
According to a first record prefetch control method of the present invention, in the record prefetch control method in the client-server system, a server computer receiving a record read request from a client computer prefetches a plurality of records from a data storage device and executes a prefetch on a server side. After being stored in the communication buffer and transmitted collectively to the client computer, and when the last record has not yet been retrieved from the data storage device, the next record is transmitted to the client computer without waiting for a request from the client computer. A plurality of records to be performed are pre-read from the data storage device and stored in the server-side communication buffer.
[0011]
According to a second record prefetch control method of the present invention, in the record prefetch control method in the client-server system, a server computer receiving a record read request from a client computer prefetches a plurality of records from a data storage device and executes a record buffer operation. And stores the converted records obtained by performing data type conversion on the data in each of the records stored in the record buffer in the server-side communication buffer, and then transmits them collectively to the client computer. If no record has been retrieved from the data storage device, a plurality of records to be transmitted to the client computer next are read ahead from the data storage device without waiting for a request from the client computer, and the record buffer is read. And wherein the storing in the server-side communication buffer performs data type conversion processing stores in §.
[0012]
According to a third record prefetch control method of the present invention, in the first or second record prefetch control method, the client computer stores a plurality of records received from the server computer in a client communication buffer. Reading records one by one from the communication buffer and returning them to the user program, and if the record to be returned to the user program does not exist in the client-side communication buffer, requests the server computer to read the next record. I do.
[0013]
A first record look-ahead control system according to the present invention includes a client computer and a server computer that can communicate with each other, and the server computer receives a plurality of records from a data storage device when receiving a record reading request from the client computer. A process of pre-reading the record and storing it in the server-side communication buffer, a process of collectively transmitting all records stored in the server-side communication buffer to the client computer, and a process of transmitting the final record from the data storage device. A server system for prefetching from the data storage device a plurality of records to be transmitted to the client computer without waiting for a request from the client computer and storing the records in the server-side communication buffer when the request has not been retrieved yet Characterized in that it comprises.
[0014]
A second record prefetch control system of the present invention comprises a mutually communicable client computer and a server computer, wherein the server computer receives a plurality of records from a data storage device upon receiving a record reading request from the client computer. For pre-reading the record of the record and storing it in the record buffer, for converting the data type of the data in each record stored in the record buffer, and for storing the converted record in the server-side communication buffer. Processing, processing for transmitting all records stored in the server-side communication buffer to the client computer at a time, and requesting the last record from the client computer when the last record has not yet been retrieved from the data storage device. Without waiting A server system for prefetching a plurality of records to be transmitted to the client computer from the data storage device, storing the records in the record buffer, performing the conversion process, and storing the records in the server-side communication buffer. Features.
[0015]
A third record look-ahead control system according to the present invention is the first or second record look-ahead control system, wherein the client computer stores a plurality of records received from the server computer in a client-side communication buffer; Reading records one by one from the communication buffer and returning them to the user program, and if the record to be returned to the user program does not exist in the client-side communication buffer, requests the server computer to read the next record. I do.
[0016]
A first server computer of the present invention is a server computer connected to a client computer via a network, comprising: a server system including a transmission / reception unit for communicating with the client computer; a server-side communication buffer and a control unit; A data storage device for storing, wherein the server system prefetches a plurality of records from the data storage device when receiving a record reading request from the client computer, and stores the plurality of records in the server-side communication buffer. A process of transmitting all records stored in the server-side communication buffer to the client computer at once, and a request from the client computer when the final record has not yet been retrieved from the data storage device. And a process of storing in the server-side communication buffer multiple records of scheduled to be transmitted without the said client computer to pre-read from said data storage device.
[0017]
The second server computer of the present invention is a server computer connected to a client computer via a network, wherein the transmitting and receiving means for communicating with the client computer, a server-side communication buffer, a record buffer, a data conversion processing means and a control means And a data storage device for storing data, wherein the server system prefetches a plurality of records from the data storage device when receiving a record reading request from the client computer, and A process of storing data in a buffer, a process of performing data type conversion on data in each record stored in the record buffer, a process of storing the converted record in the server-side communication buffer, Communication bag Transmitting all the records stored in the client computer to the client computer in a lump, and transmitting the final record to the client computer without waiting for a request from the client computer when the last record has not been retrieved from the data storage device. A process of pre-reading a plurality of records to be transmitted from the data storage device, storing the records in the record buffer, performing the conversion process, and storing the converted data in the server-side communication buffer.
[0018]
A first server program according to the present invention is connected to a client computer via a network, and includes a transmitting / receiving means for communicating with the client computer, a server-side communication buffer, and a data storage device. A process of prefetching a plurality of records from the data storage device when receiving a record reading request from the data storage device and storing the records in the server-side communication buffer; and collectively storing all records stored in the server-side communication buffer in the client computer. The process of transmitting a plurality of records that are to be transmitted to the client computer without waiting for a request from the client computer when the last record has not yet been retrieved from the data storage device. Process to be stored in the server-side communication buffer already read, it is executed.
[0019]
The second server program of the present invention is connected to a client computer via a network, and provided in a server computer including a transmitting / receiving means for communicating with the client computer, a server-side communication buffer, a record buffer, and a data storage device. A process of prefetching a plurality of records from the data storage device and storing the records in the record buffer when receiving a record reading request from the client computer, and converting a data type for data in each record stored in the record buffer Performing the conversion, storing the converted record in the server-side communication buffer, transmitting all the records stored in the server-side communication buffer to the client computer at a time, data When not yet retrieved from the storage device, a plurality of records that are to be transmitted to the client computer without waiting for a request from the client computer are read ahead from the data storage device and stored in the record buffer, and the conversion process is performed. And storing the information in the server-side communication buffer.
[0020]
[Action]
According to the present invention, when receiving a record reading request from the client computer, the server computer pre-reads a plurality of records from the data storage device and collectively transmits the records to the client computer. When not yet retrieved from the device, multiple records to be transmitted to the client computer are read ahead from the data storage device without waiting for a request from the client computer, and stored in the server-side communication buffer vacated by the transmission. Therefore, the next plurality of records can be transmitted immediately when actually requested by the client computer. As a result, even when the number of records to be passed to the user program is large and it is necessary to pre-read many times in the communication buffer on the client side, the records can be returned to the user program with good response. In particular, when the server does not pass the pre-read record to the client as it is, but converts the data type of the data in the record before passing it to the client, the time to perform the data type conversion process is also hidden, preventing the response from deteriorating. Is done.
[0021]
BEST MODE FOR CARRYING OUT THE INVENTION
Next, a first embodiment of the present invention will be described in detail with reference to the drawings.
[0022]
Referring to FIG. 1, in a first embodiment of the present invention, a client computer 101 and a server computer 501 are communicably connected to each other through a network 401 such as a LAN, a WAN, a telephone line, and the Internet. The computer 101 includes a user program 201 and a DB client system 301, and the server computer 501 includes a DB server system 601, a DBMS 701, and a DB 801. Note that DB is an abbreviation for database, and DBMS is an abbreviation for database management system.
[0023]
The DB client system 301 is a system that provides a client-side function when the user program 201 accesses the DB 801 by the client-server method. Information such as a record reading request via the network 401 with the DB server system 601 is provided. Transmitting means 302 and receiving means 303 for transmitting information such as a record of a search result record and the like, a communication buffer 304 having a capacity capable of storing a plurality of records received from the DB server system 601, and a DB client system 301. And a control unit 305 having a record prefetch result division function of dividing a plurality of records prefetched in the communication buffer 304 into record units and returning them to the user program 201.
[0024]
The DB server system 601 is a system that provides a server-side function when the user program 201 accesses the DB 801 by the client-server method. A transmitting unit 602 and a receiving unit 603 for transmitting information and receiving information such as a record reading request; a communication buffer 604 having a capacity capable of storing a plurality of records to be transmitted to the DB client system 301; and a DB server system 601 And control means 605 having a record prefetch function for prefetching a record from the DB 801 through the DBMS 701.
[0025]
Next, a schematic operation of the present embodiment will be described with reference to FIG.
[0026]
Now, consider that the user program 201 of the client computer 101 reads a series of records from the DB 801 one by one and processes them. In this case, when a first record read request R11 to the DB 801 is generated from the user program 201, the DB client system 301 transmits the first read request R21 to the DB server system 601 of the server computer 501 via the network 401.
[0027]
Upon receiving the read request R21, the DB server system 601 sends a search request R31 to the DBMS 701, collectively receives a plurality of records from the DB 801 through the DBMS 701, and temporarily stores the records in the communication buffer 604. Next, all records stored in the communication buffer 604 are transmitted to the client computer 101 via the network 401 as responses to the read request R21. Then, the communication buffer 604 is emptied by this transmission. If the last record has not yet been acquired from the DB 801, the search request R 32 is sent to the DBMS 701 to read a plurality of records from the DB 801. And stored in the communication buffer 604.
[0028]
On the other hand, the DB client system 301 of the client computer 101 temporarily stores a plurality of records sent from the DB server system 601 in the communication buffer 304, extracts one record from the stored plurality of records, and issues a read request R11. As a response to the user program 201. When a read request R12 for the next one record is generated from the user program 201, one record is extracted from the records remaining in the communication buffer 304 and returned to the user program 201 as a response to the read request R12. Such an operation is repeated until there are no more records stored in the communication buffer 304. When all records in the communication buffer 304 have been returned, the read request R1n issued from the user program 201 immediately thereafter returns a read request for requesting the DB server system 601 for the next plurality of records. R22 is transmitted via the network 401.
[0029]
In response to the read request R22, the DB server system 601 transmits, via the network 401, the DB client system 301 a plurality of records that have been read ahead in the communication buffer 604. The plurality of transmitted records are temporarily stored in the communication buffer 304 of the DB client system 301, are divided for each record, and are returned to the user program 201 as described above.
[0030]
Next, the processing content of the DB server system 601 will be described in detail with reference to FIG. Upon receiving the first read request (corresponding to R21 in FIG. 2) from the DB client system 301, the control means 605 in the DB server system 601 starts the processing in FIG. 3 (1100). First, a variable BUF used internally is initialized to 0, and a variable DAT is initialized to 1 (1101). Here, the variable BUF is for managing whether or not the record group to be transmitted has been stored in the communication buffer 604, and 0 indicates that the record group to be transmitted does not exist in the communication buffer 604, and 1 indicates that the record group does not exist. To do so. The variable DAT manages whether or not the last record has been taken out. 0 indicates that the last record has been taken out, and 1 indicates that it has not been taken out.
[0031]
Next, the control unit 605 monitors a read request from the DB client system 301 (1102). If a read request has been issued (YES in 1103), the process branches to step 1104 to manage the presence or absence of the read request. The variable REQ is set to 1 for reading, and if there is no read request (NO in 1103), the flow branches to step 1105 to set the value of the variable REQ to 0.
[0032]
Next, the control unit 605 determines the value of the variable BUF (1105). If it is not equal to 1, that is, if there is no record group to be transmitted in the communication buffer 604, the process branches to step 1107, and if it is equal to 1, That is, if a record group to be transmitted is stored in the communication buffer 604, the process branches to step 1112.
[0033]
When the process branches to step 1107, the control unit 605 requests a predetermined amount of records satisfying the request from the DBMS 701 in accordance with a search condition or the like requested from the DB client system 301. Here, the predetermined amount is defined in advance by the system. In this example, the record is, for example, 8 KB. Of course, instead of being defined by the capacity, it may be defined by the number of records. Next, it is determined whether or not the last record is included in the record group returned from the DBMS 701 (1108). If the last record is included (YES in 1108), the variable DAT is set to 0. This is managed (1109), and the process proceeds to step 1110. If the last record is not included, step 1109 is skipped and the process proceeds to step 1110. In step 1110, the record group returned from the DBMS 701 is stored in the communication buffer 604. Then, 1 is set to the variable BUF (1111), and the process proceeds to step 1112.
[0034]
In step 1112, the control unit 605 determines the value of the variable REQ, and if it is equal to 1, that is, if a read request is issued from the DB client system 301, the process branches to step 1113, and if it is not equal to 1, that is, if If a read request has not been issued from the client system 301, the flow branches to step 1102 to repeat the above-described processing.
[0035]
When the process branches to step 1113, the control unit 605 transmits all the contents of the communication buffer 604 to the DB client system 301 via the transmission unit 602 via the network 401. Since this transmission empties the communication buffer 604, the variable BUF is set to 0 (1114). Then, the value of the variable DAT is determined (1115), and if it is equal to 0, that is, if the last record has been fetched and all the records have been transmitted to the client, the process ends (1116), and If it is not equal to, that is, if the retrieval of the last record has not been completed, the flow branches to step 1102 to repeat the above processing.
[0036]
Next, the processing content of the DB client system 301 will be described in detail with reference to FIG. The control unit 305 in the DB client system 301 starts the processing in FIG. 4 when a first read request (corresponding to R11 in FIG. 2) is received from the user program 201 (1200). First, a variable EMPTY, which is an internal variable, is initialized to 1. Here, the variable EMPTY is for managing whether or not no record exists in the communication buffer 304. 1 indicates that no record exists, and 0 indicates that at least one record exists. .
[0037]
Next, the control unit 305 monitors a read request from the user program 201 (1202). If a read request has been issued (YES in 1203), the process branches to step 1204, and if no read request has been issued (1203). NO), the flow branches to step 1202 to continue monitoring the read request.
[0038]
When the flow branches to step 1204 due to a read request, the control unit 305 determines the value of the variable EMPTY. If the value is equal to 1, that is, if no record exists in the communication buffer 304, the control unit 305 branches to step 1205. Then, a read request is issued to the DB server system 601 through the transmission unit 302. Then, the process proceeds to step 1206. By issuing this read request, a maximum of 8 KB of records is returned from the DB server system 601, and the record group is stored in the communication buffer 304 through the receiving unit 303. On the other hand, if the value of the variable EMPTY is not equal to 1, that is, if at least one record exists in the communication buffer 304, the process skips step 1205 and proceeds to step 1206.
[0039]
In step 1206, the control means 305 reads one record from the communication buffer 304, and returns this one record to the user program 305 in the next step 1207. Then, it is determined whether or not the record returned this time is the last record (1208). If it is not the last record (NO in 1208), the process branches to step 1209. If it is the last record (YES in 1208), the process ends. (1212). In step 1209, it is determined whether or not the communication buffer 304 is empty. If the communication buffer 304 is empty (YES in 1209), the variable EMPTY is set to 1 and the fact is managed (1210). If is not empty (NO in 1209), the variable EMPTY is set to 0 to manage this, and the process returns to step 1202 to repeat the above processing.
[0040]
Next, a specific operation of the present embodiment will be described. As an example, a case where the DB 801 is a relational database and the user program 201 reads a plurality of records that satisfy the search condition specified by the cursor definition using the SQL statement in the user program 201 one by one using the FETCH statement will be taken.
[0041]
FIG. 5 is a source image showing a content example 1300 of the user program 201 for accessing the DBMS 701 via the DB client system 301 and the DB server system 601 using an embedded SQL statement. Note that an embedded SQL sentence is usually prefixed with “EXEC SQL”, but is omitted in FIG.
[0042]
In FIG. 5, reference numeral 1301 denotes a cursor declaration statement indicating an inquiry condition to the DBMS 701, which associates a search condition (after the SELECT section) with a cursor name “CSR1”. Here, it is assumed that the columns COL1 and COL2 of the table TBL1 in which the value of the column C1 is 100 are searched. When the cursor declaration statement 1301 is executed, the contents of the cursor declaration statement are sent from the DB client system 301 to the DB server system 601 and registered in the DBMS 701. Reference numeral 1302 denotes an OPEN statement indicating the start of use of the cursor CSR1 declared in the cursor declaration statement 1301. When the OPEN statement 1302 is executed, the DB client system 301 instructs the DB server system 601 to open the cursor CSR1. The DBMS 701 stores a virtual search result record group based on the search condition defined by the cursor definition statement 1301. A table is generated in the DB 801. Reference numeral 1303 denotes a loop process indicating that the process is repeatedly executed until SQLCODE = 100 indicating the end of data, and is described in a host language such as COBOL and C. Reference numeral 1304 denotes an FETCH statement for reading one row (one record) from the virtual table. Here, H1 and H2 are specified as host variables, and the values of the searched columns COL1 and COL2 are set to H1 and H2, respectively, and are returned to the user program 201. One record is a pair of the values of the columns COL1 and COL2. Reference numeral 1305 denotes a CLOSE statement indicating the end of use of the cursor CSR1.
[0043]
Since the processes related to the cursor declaration statement 1301, the open statement 1302, and the close statement 1305 are the same as those in the related art, the operation related to the WHILE statement 1303 and the FETCH statement 1304 will be described below. For convenience of explanation, it is assumed that the total capacity of records satisfying the search condition specified by the cursor declaration statement 1301 is 20 KB, and the capacity of one searched record is 1 KB. That is, it is assumed that a total of 20 records (20 rows) have been searched.
[0044]
First, the operation of the DB client system 301 will be described.
[0045]
When the first FETCH statement 1304 is executed in the user program 201, the control unit 305 in the DB client system 301 starts the processing in FIG. 4 (1200). First, the control unit 305 sets 1 to a variable EMPTY (1201) and monitors a read request (1202). At this point, since the first read request has been issued from the user program 201, the determination of the read request in step 1203 is YES, and the process branches to step 1204.
[0046]
Since the determination of the variable EMPTY == 1 in step 1204 is YES, the control unit 305 issues a read request to the DB server system 601 specifying the cursor name CSR1 and passing the next record group ( 1205). In response to this read request, a search result for 8 KB, that is, eight search records is returned from the DB server system 601, which is stored in the communication buffer 304 by the receiving unit 303. The control unit 305 reads one record from the communication buffer 304 (1206), and returns this one record to the user program 201 (1207).
[0047]
In the user program 201, when the first processing of the FETCH statement 1304 ends, the processing of the FETCH statement 1304 is repeated again by the loop processing of the WHILE statement 1303.
[0048]
On the other hand, the control unit 305 of the DB client system 301 sets the variable EMPTY to 0 because the previously returned record is not the last record in the DBMS 701 (NO in 1208) and the communication buffer 304 is not empty (NO in 1209). It sets (1211) and branches to step 1202. Then, in step 1202, a read request from the user program 201 is monitored. If the next read request is executed by the FETCH statement 1304 of the user program 201, the process branches from step 1203 to step 1204, and the value of the variable EMPTY is Since it is 0, the process branches to step 1206, and the next one record (the second record) is read from the communication buffer 304 as a search result. As described above, while the communication buffer 304 is not empty, the next record is read from the communication buffer 304 without making a read request to the DB server system 601 and returned to the user program 201. Then, the eighth record is returned to the user program 201. When the communication buffer 304 becomes empty, the process branches from step 1209 to step 1210, sets 1 to the variable EMPTY, and branches to step 1202.
[0049]
Therefore, when the next read request is issued from the user program 201, since the variable EMPTY is 1, the control means 305 issues a second read request to the DB server system 601 (1205). In response to this read request, the DB server system 601 returns a search result for the next 8 KB, that is, eight search records. The search result is stored in the communication buffer 304 by the receiving unit 303 and one of the search records is returned. Is retrieved and returned to the user program 201 (1207). Thereafter, when there is a search request from the user program 201, records are read from the communication buffer 304 one by one and returned until the communication buffer 304 becomes empty.
[0050]
When the communication buffer 304 becomes empty again, the control unit 305 issues a third read request to the DB server system 601 because the return of the last record has not been completed yet (1205). In response to this read request, a search result of 4 KB including the last record, that is, four records, is returned from the DB server system 601, and the result is stored in the communication buffer 304 of the DB client system 301. One record is taken out and returned to the user program 201 (1207). Thereafter, every time there is a read request from the user program 201, one record is taken out from the communication buffer 304 and returned (1207). Then, when the return of the last record is completed, the control unit 305 ends the processing (1212).
[0051]
Next, the operation of the DB server system 601 will be described.
[0052]
In the DB server system 601, when the first read request is issued from the DB client system 301, the processing in FIG. 3 is started (1100). First, the control unit 605 initializes the variable BUF to 0 and the variable DAT to 1 (1101), recognizes the first read request from the DB client system 301 in steps 1102 and 1103, and sets the variable REQ to 1 (1104). Then, since the value of the variable BUF is 0 (NO in 1105), the control unit 605 executes a request to the DBMS 701 and collectively receives a plurality of records satisfying the search condition for a maximum of 8 KB. Since the last record is not included in the received eight records (NO in 1108), the control unit 605 skips step 1109 and proceeds to step 1110, and stores the received eight records in the communication buffer 604. Then, the variable BUF is set to 1 (1111). Then, since the value of REQ is 1 (YES in 1112), the contents of the communication buffer 604 are transmitted to the DB client system 301 by the transmission means 602 (1113), the variable BUF is set to 0 (1114), and the variable DAT is set. Is not 0 (NO in 1115), the flow branches to step 1102.
[0053]
Next, the control unit 605 monitors the second read request from the DB client system 301. Immediately after the transmission, the control unit 605 sets 0 to the variable REQ because the second read request has not been made yet (1105). Proceed to 1105. In this step 1105, it is determined whether the value of the variable BUF is 1 or not. Since the value of the variable BUF is 1, the flow branches to step 1107 and waits for the next second read request from the DB client system 301. Instead, the search of the DBMS 701 is performed (1107). That is, the control unit 605 collectively receives a plurality of remaining records satisfying the search condition for a maximum of 8 KB from the DBMS 701. Again, since the last record is not included in the eight records received (NO in 1108), the process skips step 1109 and proceeds to step 1110, where the eight records received are stored in the communication buffer 604. , The variable BUF is set to 1 (1111). Then, it is determined whether the value of the variable REQ is 1 or not. However, since the second read request has not been issued from the DB client system 301 and the variable REQ has not become 1, the control unit 605 determines in step 1102 Branch to While the state where the second read request is not issued from the DB client system 301 continues, the value of the variable REQ does not become 1 and the variable BUF becomes 1, so that the control means 605 executes steps 1102 → 1103 → 1105 → It is in a loop of 1106 → 1112 → 1102.
[0054]
Then, when a second read request is issued from the DB client system 301, the control unit 605 detects this in steps 1102 and 1103, and sets the variable REQ to 1 (1104). As a result, the process exits the above-described loop and proceeds to step 1113, where the search result for 8 KB previously read in the communication buffer 604 is transmitted to the DB client system 301. Then, the variable BUF is set to 0 (1114), and since the variable DAT is still 1, the flow branches to step 1102.
[0055]
The control unit 605 monitors the next read request from the DB client system 301. Immediately after the transmission, the third read request has not been made yet, so that the variable REQ is set to 0 (1105), and the process proceeds to step 1105. In this step 1105, it is determined whether the value of the variable BUF is 1 or not. Since the value of the variable BUF is 0, the process branches to step 1107 and waits for the next third read request from the DB client system 301. In order to perform the record prefetching process, the remaining 4 KB records satisfying the search condition are collectively received from the DBMS 701. This time, since the last record is included in the received search results (YES in 1108), the variable DAT is set to 0 in step 1109, and the process proceeds to step 1110, where the four search results received are stored in the communication buffer. Then, the variable BUF is set to 1 (1111). Then, it is determined whether the value of the variable REQ is 1 or not. Since the third read request has not been issued yet from the DB client system 301 and the variable REQ has not become 1, the control unit 605 determines in step 1102 Branch to While the state where the third read request is not issued from the DB client system 301 continues, the value of the variable REQ does not become 1 and the variable BUF becomes 1, so that the control means 605 executes steps 1102 → 1103 → 1105 → The loop is from 1106 to 1112 to 1102.
[0056]
Then, when the third read request is issued from the DB client system 301, the control unit 605 detects it in steps 1102 and 1103, and sets the variable REQ to 1 (1104). As a result, the process exits the above-described loop and proceeds to step 1113, in which the 4 KB record previously read in the communication buffer 604 is transmitted to the DB client system 301. Next, the variable BUF is set to 0 (1114), and the value of the variable DAT is determined (1115). This time, since the variable DAT is set to 0, the control means 605 ends the processing (1116).
[0057]
Another embodiment of the present invention
Next, a second embodiment of the present invention will be described in detail with reference to the drawings.
[0058]
Referring to FIG. 6, the second embodiment of the present invention is different from the first embodiment in that a record buffer 606 and a data conversion processing unit 607 are provided between the control unit 605 and the communication buffer 604 in the DB server system 601. This embodiment is different from the above embodiment.
[0059]
Referring to FIG. 7, the processing of DB server system 601 in the present embodiment is different from the processing shown in FIG. 3 in that the processing content of step 1110 stores search results in record buffer 606 instead of communication buffer 604. It differs in that it is changed and steps 1117 and 1118 are added immediately after step 1110.
[0060]
The record buffer 606 has a capacity capable of storing a plurality of records of search results. In the first embodiment, the control unit 605 stores a plurality of records retrieved from the DB 801 through the DBMS 701 in the communication buffer 604. In the present embodiment, the control unit 605 stores the records in the record buffer 606 (1110).
[0061]
The data conversion processing means 607 converts the data type of each search result stored in the record buffer 606 into a data type required by the DB client system 301, and stores each search result after this conversion processing in the communication buffer 604. It has a function to do. The data type to be converted is specified by the user program 201. This designation can be performed, for example, in the cursor declaration statement 1300 in FIG. 5. In this case, when the contents of the cursor declaration statement 1300 are notified to the DB server system 601, information on the data type to be converted is converted into data conversion processing means 607. Is set to When a record has a plurality of fields (columns), the presence or absence of conversion and the data type can be specified for each field.
[0062]
Next, the operation of the present embodiment will be described focusing on the differences from the first embodiment.
[0063]
Upon receiving a plurality of records from the DBMS 701 in response to the search request issued to the DBMS 701 in step 1107, the control means 605 of the DB server system 601 stores them in the record buffer 606 (1110). Next, the data conversion processing means 607 sequentially reads the records from the record buffer 606, converts the data type of the requested field in the record into the requested data type, and stores the data in the communication buffer 604. A plurality of records after the conversion processing stored in this way are transmitted to the DB client system 301 collectively as in the first embodiment. Since this conversion processing is performed in the course of the pre-read processing, the conversion processing time can be concealed, and the throughput is improved.
[0064]
In the above description, a relational database is taken as an example of a data storage device for retrieving records. However, other types of databases may be used. Similarly, it may be a file.
[0065]
Although the embodiments of the present invention have been described above, the present invention is not limited to the above embodiments, and various other additions and changes are possible. For example, although the server computer 501 is connected to one client computer 101 in the above embodiment, it can be generally connected to a plurality of client computers. In that case, a plurality of DB server systems 601 are provided in the server computer 501, and these operate in parallel.
[0066]
Further, the DB server system 601 and the DB client system 301 according to the present invention may be realized by hardware, or may be realized by a program operating on a computer. In the latter case, the server program and the client program are provided by being recorded on a computer-readable recording medium such as a magnetic disk or a semiconductor memory, or are provided through a network. The server program is read by the server computer and controls the operation of the computer, thereby realizing the DB server system 601 in each of the above-described embodiments on the computer. Similarly, the client program is read by a client computer and controls the operation of the computer, thereby realizing the DB client system 301 in each of the above-described embodiments on the computer.
[0067]
【The invention's effect】
As described above, according to the present invention, a record can be returned to the user program with good response even when the number of records to be passed to the user program is large and it is necessary to pre-read the buffer on the client side many times. The reason is that when receiving a record reading request from the client computer, the server computer prefetches a plurality of records from the data storage device and transmits them collectively to the client computer, and then the final record is still not received from the data storage device. When not retrieved, a plurality of records to be transmitted to the client computer are pre-read from the data storage device without waiting for a request from the client computer, and stored in the server-side communication buffer which has become empty by transmission. Therefore, the next plurality of records can be immediately transmitted to the client when the client actually requests.
[0068]
According to the present invention, a record can be returned to a user program with good response even when a record read by a server is not passed to a client as it is, but the data type of the data in the record is converted and then passed to the client. it can. The reason is that the conversion processing time is hidden because the data type conversion processing is performed in the process of the pre-reading processing.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration of a first exemplary embodiment of the present invention.
FIG. 2 is an explanatory diagram of a schematic operation according to the first embodiment of the present invention.
FIG. 3 is a flowchart illustrating a processing example of a DB server system according to the first embodiment of the present invention.
FIG. 4 is a flowchart illustrating a processing example of a DB client system according to the first embodiment of the present invention.
FIG. 5 is a diagram illustrating an example of a user program according to the first embodiment of the present invention.
FIG. 6 is a block diagram showing a configuration of a second exemplary embodiment of the present invention.
FIG. 7 is a flowchart illustrating a processing example of a DB server system according to a second embodiment of the present invention.
[Explanation of symbols]
101 Client computer
201 User program
301 DB Client System
302 Transmission means
303 receiving means
304 communication buffer
305 control means
401 Network
501 server computer
601 DB server system
602 transmission means
603 receiving means
604 Communication buffer
605 control means
606 record buffer
607 Data conversion processing means
701 DBMS
801 DB