JP2004094711A - 負荷バランス機能を有するプログラム制御方法及びシステム - Google Patents
負荷バランス機能を有するプログラム制御方法及びシステム Download PDFInfo
- Publication number
- JP2004094711A JP2004094711A JP2002256493A JP2002256493A JP2004094711A JP 2004094711 A JP2004094711 A JP 2004094711A JP 2002256493 A JP2002256493 A JP 2002256493A JP 2002256493 A JP2002256493 A JP 2002256493A JP 2004094711 A JP2004094711 A JP 2004094711A
- Authority
- JP
- Japan
- Prior art keywords
- processing
- online
- batch
- processing service
- requests
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】オンライン処理とバッチ処理を効率よく同時に実行することが可能なプログラム制御方法及びシステムを提供することを目的とする。
【解決手段】ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上でオンライン処理サービスまたはバッチ処理サービスに処理を振り分けるプログラム制御方法であって、オンライン処理サービスへの要求数のしきい値を定義し、前記しきい値とオンライン処理サービスへの要求数を比較し、オンライン処理サービスへの要求数が前記しきい値を超えた場合にバッチ処理サービスを一時的に停止させる。オンライン処理サービスへの要求数が前記しきい値より小さくなったとき、バッチ処理再開の指示を出す。また、1つのプログラムでオンライン処理とバッチ処理の両サービスを処理させ、要求数に応じてサービスを切り替えて実行させる。
【選択図】 図1
【解決手段】ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上でオンライン処理サービスまたはバッチ処理サービスに処理を振り分けるプログラム制御方法であって、オンライン処理サービスへの要求数のしきい値を定義し、前記しきい値とオンライン処理サービスへの要求数を比較し、オンライン処理サービスへの要求数が前記しきい値を超えた場合にバッチ処理サービスを一時的に停止させる。オンライン処理サービスへの要求数が前記しきい値より小さくなったとき、バッチ処理再開の指示を出す。また、1つのプログラムでオンライン処理とバッチ処理の両サービスを処理させ、要求数に応じてサービスを切り替えて実行させる。
【選択図】 図1
Description
【0001】
【発明の属する技術分野】
本発明は、ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上で該当するサービスプログラムに処理を振り分けるプログラム制御方法及びシステムに関する。
【0002】
【従来の技術】
従来、リアルタイム性を求められるオンライン処理は昼間に行い、リアルタイム性を求められないバッチ処理はオンライン処理が停止する夜間に行われていた。こうすることで、日中はバッチ処理の負荷を気にすることなく、オンラインサービスだけの処理に集中させ、レスポンスを確保していた。
【0003】
【発明が解決しようとする課題】
ところで、上記従来技術によれば、オンラインサービスが停止している時間だけバッチ処理を実行できるが、オンラインサービスが停止する時間が短いか、あるいは24時間オンラインサービスを提供するケースを考慮しておらず、バッチサービスを実行する時間が限られてしまっていた。また、オンライン処理中にバッチ処理を実行すると、オンラインサービスの性能が劣化するという問題があった。企業の国際化などの動きの中で、オンライン処理の24時間連続運転化が急速に進展しているため、従来のように夜間や休日だけバッチ処理を行うわけにはいかなくなってきている。
【0004】
また、オンライン処理の24時間連続運転化に伴い、オンラインの処理状況を考慮して、バッチ処理を起動するタイミングを人が決めることが難しくなってきている。
【0005】
本発明の目的は、上記の従来型における問題点に鑑み、オンライン処理とバッチ処理を効率よく同時に実行することが可能なプログラム制御方法及びシステムを提供することにある。
【0006】
【課題を解決するための手段】
上記の目的を達成するため、本発明は、ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上でオンライン処理サービスまたはバッチ処理サービスに処理を振り分けるプログラム制御方法であって、オンライン処理サービスへの要求に関し、前記サーバ上でそれらの要求を処理する際の負荷を判断する指標となるしきい値を定義し、前記しきい値を指標として、オンライン処理サービスへの要求にかかる負荷が大きいかどうかを判定し、オンライン処理サービスへの要求にかかる負荷が大きいと判定されたとき、バッチ処理サービスを一時的に停止させることを特徴とする。
【0007】
【発明の実施の形態】
以下、図面を用いて本発明の実施の形態を説明する。
【0008】
図1に、本発明を適用した処理システムの全体構成を示す。ネットワーク160に、オンラインクライアント100,110、バッチクライアント120、及びサーバ130が接続されている。サーバ130は、要求受付機能131、トランザクション管理機能132、キュー133、定義ファイル134、オンラインアプリケーション141、バッチアプリケーション142、及びデータベース150を有する。
【0009】
図2に、キュー133の詳細を示す。ここでは、キュー133は、種別201、会員コード202、商品コード203、数量204、データファイル205、及び処理の状況206の各項目を有するものとする。種別201が“ON”であるレコードは、オンラインクライアント100,110からの要求を示す。オンライン要求には、会員コード、商品コード、及び数量のデータが含まれる。種別201が“BA”のレコードは、バッチクライアント120からの要求を示す。種別201が“PR”のレコードは、バッチクライアント120からの要求で、現在処理が中断されているものを示す。種別201が“BA”または“PR”の場合、バッチ処理すべきデータファイルの格納先がデータファイル205の欄に記載される。処理の状況206は、バッチ処理が中断されたとき(“PR”のとき)の処理中の場所、すなわちバッチ処理しているデータファイルのどこまで処理したかを示す位置である。
【0010】
図3に、データファイル205の項目で指される格納先に存在するバッチ処理用のデータファイルの内容例を示す。データファイルは、図3に示すように、会員コード301と、商品コード302と、数量303の組み合わせを複数記述したテキスト形式のデータファイル300である。バッチ処理を行う際には、このデータファイルのレコードを読み出してデータベースに格納する。
【0011】
図4に、データベース150のテーブル構造を示す。テーブル400は、会員コード401と、商品コード402と、数量403の項目を備えている。音来所理やバッチ処理によって、このデータベースにデータが格納されていく。
【0012】
図5に、定義ファイル134の詳細を示す。定義ファイル134の内容500は、項目501と、値502からなる。例えば、項目501は「しきい値」であり、値502は「5」であるとき、しきい値の値を「5」と定義したことを意味する。しきい値の意味については後述する。
【0013】
図6に、要求受付機能131の処理フローチャート600を示す。要求受付機能131では、ステップ601でクライアントからのリクエストを受け付け、ステップ602でデータをキュー133に格納する。これらの処理を繰り返し実行する。
【0014】
図7に、トランザクション管理機能132の処理フローチャート700を示す。トランザクション管理機能132では、まずステップ701で、定義ファイル134からしきい値の値を取得し、キュー133から該キュー133に現在格納されているデータの個数(詳しくは、全体のデータ数のほか、種別“ON”のデータの個数、及び種別“PR”のデータがあるかどうか)を取得する。次に、ステップ702で、ステップ701で得たしきい値の値とキュー133に格納されている種別が“ON”であるデータの個数とを比較する。種別“ON”のデータの個数がしきい値以上であるときは、オンライン処理要求の数がしきい値以上ということであるから、ステップ703でバッチ処理に停止指示を出し、ステップ701に戻る。例えば、図5に示したようにしきい値の値が5である場合は、オンライン処理要求の個数が5個以上のときにバッチ処理が停止され、オンライン処理が優先的に実行される。
【0015】
ステップ702でしきい値の値のほうが大きい場合、ステップ704で、キュー133に格納されたデータの個数が0であるかどうかを判断する。データの個数が0であれば、処理要求がないということであるから、ステップ701に戻る。データの個数が0でない場合、ステップ705で、キュー133に処理中のバッチ処理があるかどうか、すなわち種別“PR”のデータがあるかどうかを判断する。処理中のバッチ処理がある場合、ステップ706で、その種別“PR”のデータをキュー133から取り出し、そのデータに基づいてバッチ処理(図9)を起動し、ステップ701に戻る。キュー133に処理中のバッチ処理がない場合は、ステップ707に進む。
【0016】
ステップ707で、キュー133(図2)からデータ(1レコード)を取得する(取り出す)。ステップ708で、取得したデータの種別が“ON”であるかどうかを判断する。データの種別が“ON”である場合は、ステップ709で、取得したデータに基づいてオンライン処理(図8)を起動し、ステップ701に戻る。キュー133から取得したデータの種別が“ON”でない場合は、取得したデータがバッチ処理要求(種別“BA”)であるということである。この場合は、ステップ710で、しきい値とキュー133のデータ中の種別が“ON”であるデータの個数とを比較する。種別“ON”の個数がしきい値の値以上のときは、オンライン処理要求が多いということであるから、ステップ711でデータ(ステップ707で取り出した種別“BA”のデータ)をキュー133に戻して、ステップ701に戻る。ステップ710でしきい値の値のほうが大きい場合は、オンライン処理要求が少ないということであるから、ステップ712で前記取得したデータに基づいてバッチ処理(図9)を起動し、ステップ701に戻る。
【0017】
図8に、オンラインアプリケーション141の処理(ステップ709)のフローチャートを示す。ステップ801で、トランザクションを開始する。ステップ802で、与えられたデータ(会員コードと商品コードと数量)をデータベース150に格納する。ステップ803で、コミット(Commit)処理、すなわちデータベース150へのデータ変更を確定する処理を行う。ステップ804で、トランザクションを終了する。
【0018】
図9に、バッチアプリケーション142の処理(ステップ706,712)のフローチャートを示す。ステップ901で、トランザクションを開始する。ステップ902で、バッチ処理するデータファイル(図3)から1レコード取り出しデータベース150(図4)に格納する。ステップ903で、バッチ処理停止指示(ステップ703の指示)が出ているかどうかを判断する。バッチ処理停止指示が出ている場合は、ステップ905に進み、データベースをコミットしてそれまでの処理を確定させる。その後、ステップ906でトランザクションを終了(中断)し、ステップ907で処理を中断したデータファイルを特定する種別“PR”のレコードをキュー133(図2)に戻す。このとき、処理の状況206には、処理を中断した位置を格納しておくものとする。
【0019】
ステップ903でバッチ処理停止指示が出ていない場合は、ステップ904で、バッチ処理が終了したかどうか(すなわち、データファイル(図3)の内容をすべてデータベース(図4)に格納したかどうか)を判断する。バッチ処理が終了していない場合は、ステップ902に戻る。バッチ処理が終了した場合は、ステップ905でデータベースをコミットして処理を確定させ、ステップ906でトランザクションを終了する。この場合、ステップ907は行わない。
【0020】
次に、上述の本実施形態のシステムの全体の動きを具体例で説明する。
【0021】
オンラインクライアント100,110は商品コードと数量を指定して、またバッチクライアント120は図3のようなデータファイルを指定して、それぞれ要求受付機能131に要求を発行する。要求を受けた要求受付機能131は、図6に示したフローチャートに示す通り、要求を待ち受け、受け付けた要求の内容をキュー133(図2)に格納する。オンラインクライアント100,110からの要求を受け付けた場合は種別201を“ON”とし、バッチクライアント120からの要求を受け付けた場合は種別201を“BA”とする。オンラインクライアント100,110は、要求時に会員コードと商品コードと数量を伝えるものとし、要求受付機能131は受け取った会員コードと商品コードと数量をキュー133(図2)の該当する欄ににそれぞれ格納する。バッチクライアント120は、図3に示すデータファイル300を要求受付機能131に渡すものとし、要求受付機能131は受け取ったデータファイル300の格納先をキュー133のデータファイル205の欄に書き込む。
【0022】
トランザクション管理機能132は、図7に示す通り、定期的にキュー133を監視し、キュー133に要求があれば、種別に応じたアプリケーションに処理を依頼する。オンラインアプリケーション141及びバッチアプリケーション142はそれぞれマルチスレッドで複数の要求を同時に処理することが可能であるものとする。オンラインアプリケーション141は、図8に示す通り、要求に応じてデータベース150にデータを格納する。バッチアプリケーション142は、図9に示す通り、要求と同時に受け取ったデータファイルの内容に従って、データベース150に複数のデータを格納する。
【0023】
本実施形態のトランザクション管理機能132は、キュー133に格納された要求のうち種別が“ON”の要求の数が、定義ファイル134のしきい値で定義された数よりも多いかどうかを判定する。多い場合には、オンライン処理要求が多いということであるから、バッチアプリケーション142に一時停止の指示を出す。一時停止の指示を受けたバッチアプリケーション142は、データファイル300の読み込みを中止し、一度データベース150をコミットする。そして、当該処理途中のデータファイルについては、種別“PR”のレコードをキュー133に戻して、バッチアプリケーション142を一時的に停止させる。なお、データファイル300のどこまで処理したかを、処理の状況206の欄に格納しておくものとする。
【0024】
トランザクション管理機能132は、再びキュー133の監視を継続し、キュー133に格納された要求のうち種別が“ON”になっているものの数が、定義ファイル134のしきい値で定義された数よりも少なくなったとき、キュー133に処理途中のバッチ処理があるかどうかを調べ、あればそのバッチ処理の再開の指示をバッチアプリケーション142に出す。再開の指示を受けたバッチアプリケーション142は、中断していたデータファイル300の読み込みを再開し、処理を続行する。
【0025】
さらに、トランザクション管理機能132はキュー133を監視し、キュー133から取得したデータの種別が“BA”であり、キュー133に格納された要求のうち種別が“ON”になっているものの数が定義ファイル134のしきい値で定義された数より多ければ、データをキュー133に格納し、バッチサービスを後に回し、オンラインサービスを優先して処理する。
【0026】
なお、上記実施形態では、図1に示すように、オンラインアプリケーション141とバッチアプリケーション142とを分けた例で説明した。これらのアプリケーションは共通する処理を行う部分が多いので、両機能を備えた1つのアプリケーションとすることもできる。図10に、図1のオンラインアプリケーション141とバッチアプリケーション142の両方を兼ね備えたオンライン・バッチアプリケーション143を有するプログラム制御システムの構成を示す。他の部分は、上記実施形態と同様である。図7に示したトランザクション管理機能132の処理のフローチャートに従うことで、図10に示すように1つのプログラムでオンライン・バッチアプリケーション143を実現することが可能となる。
【0027】
また、上記実施の形態では、項目501としてオンライン要求数についてのしきい値だけを定義したが、バッチ処理数、オンライン処理の実行数、実行可能最大数、あるいは実行可能最小数などをしきい値として定義して、オンライン処理とバッチ処理とを効率よく同時に実行させることも可能である。複数のしきい値の判別を組み合わせることも可能である。
【0028】
上記のようにすることによって、オンラインクライアントの要求が多いときにはオンラインアプリケーションの処理を優先し、逆にオンラインクライアントの要求が少ないときにはバッチ処理を行わせることが可能となる。
【0029】
【発明の効果】
以上説明したように、本発明によれば、オンライン処理とバッチ処理を効率よく同時に実行することができる。また、オンラインの処理状況を考慮し、バッチ処理を起動することができる。
【図面の簡単な説明】
【図1】本発明の実施形態に係るシステムの全体構成を示す図である。
【図2】キューの詳細図である。
【図3】データファイルの詳細図である。
【図4】データベースのテーブル構造図である。
【図5】定義ファイルの詳細図である。
【図6】要求受付機能の処理の流れを示すフローチャートである。
【図7】トランザクション管理機能の処理の流れを示すフローチャートである。
【図8】オンラインアプリケーションの処理の流れを示すフローチャートである。
【図9】バッチアプリケーションの処理の流れを示すフローチャートである。
【図10】本発明の変形例の構成を示す図である。
【符号の説明】
100,110……オンラインクライアント
120……バッチクライアント
130……サーバ
131……要求受付機能
132……トランザクション管理機能
133……キュー
134……定義ファイル
141……オンラインアプリケーション
142……バッチアプリケーション
143……オンライン・バッチアプリケーション
150……データベース
160……ネットワーク
【発明の属する技術分野】
本発明は、ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上で該当するサービスプログラムに処理を振り分けるプログラム制御方法及びシステムに関する。
【0002】
【従来の技術】
従来、リアルタイム性を求められるオンライン処理は昼間に行い、リアルタイム性を求められないバッチ処理はオンライン処理が停止する夜間に行われていた。こうすることで、日中はバッチ処理の負荷を気にすることなく、オンラインサービスだけの処理に集中させ、レスポンスを確保していた。
【0003】
【発明が解決しようとする課題】
ところで、上記従来技術によれば、オンラインサービスが停止している時間だけバッチ処理を実行できるが、オンラインサービスが停止する時間が短いか、あるいは24時間オンラインサービスを提供するケースを考慮しておらず、バッチサービスを実行する時間が限られてしまっていた。また、オンライン処理中にバッチ処理を実行すると、オンラインサービスの性能が劣化するという問題があった。企業の国際化などの動きの中で、オンライン処理の24時間連続運転化が急速に進展しているため、従来のように夜間や休日だけバッチ処理を行うわけにはいかなくなってきている。
【0004】
また、オンライン処理の24時間連続運転化に伴い、オンラインの処理状況を考慮して、バッチ処理を起動するタイミングを人が決めることが難しくなってきている。
【0005】
本発明の目的は、上記の従来型における問題点に鑑み、オンライン処理とバッチ処理を効率よく同時に実行することが可能なプログラム制御方法及びシステムを提供することにある。
【0006】
【課題を解決するための手段】
上記の目的を達成するため、本発明は、ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上でオンライン処理サービスまたはバッチ処理サービスに処理を振り分けるプログラム制御方法であって、オンライン処理サービスへの要求に関し、前記サーバ上でそれらの要求を処理する際の負荷を判断する指標となるしきい値を定義し、前記しきい値を指標として、オンライン処理サービスへの要求にかかる負荷が大きいかどうかを判定し、オンライン処理サービスへの要求にかかる負荷が大きいと判定されたとき、バッチ処理サービスを一時的に停止させることを特徴とする。
【0007】
【発明の実施の形態】
以下、図面を用いて本発明の実施の形態を説明する。
【0008】
図1に、本発明を適用した処理システムの全体構成を示す。ネットワーク160に、オンラインクライアント100,110、バッチクライアント120、及びサーバ130が接続されている。サーバ130は、要求受付機能131、トランザクション管理機能132、キュー133、定義ファイル134、オンラインアプリケーション141、バッチアプリケーション142、及びデータベース150を有する。
【0009】
図2に、キュー133の詳細を示す。ここでは、キュー133は、種別201、会員コード202、商品コード203、数量204、データファイル205、及び処理の状況206の各項目を有するものとする。種別201が“ON”であるレコードは、オンラインクライアント100,110からの要求を示す。オンライン要求には、会員コード、商品コード、及び数量のデータが含まれる。種別201が“BA”のレコードは、バッチクライアント120からの要求を示す。種別201が“PR”のレコードは、バッチクライアント120からの要求で、現在処理が中断されているものを示す。種別201が“BA”または“PR”の場合、バッチ処理すべきデータファイルの格納先がデータファイル205の欄に記載される。処理の状況206は、バッチ処理が中断されたとき(“PR”のとき)の処理中の場所、すなわちバッチ処理しているデータファイルのどこまで処理したかを示す位置である。
【0010】
図3に、データファイル205の項目で指される格納先に存在するバッチ処理用のデータファイルの内容例を示す。データファイルは、図3に示すように、会員コード301と、商品コード302と、数量303の組み合わせを複数記述したテキスト形式のデータファイル300である。バッチ処理を行う際には、このデータファイルのレコードを読み出してデータベースに格納する。
【0011】
図4に、データベース150のテーブル構造を示す。テーブル400は、会員コード401と、商品コード402と、数量403の項目を備えている。音来所理やバッチ処理によって、このデータベースにデータが格納されていく。
【0012】
図5に、定義ファイル134の詳細を示す。定義ファイル134の内容500は、項目501と、値502からなる。例えば、項目501は「しきい値」であり、値502は「5」であるとき、しきい値の値を「5」と定義したことを意味する。しきい値の意味については後述する。
【0013】
図6に、要求受付機能131の処理フローチャート600を示す。要求受付機能131では、ステップ601でクライアントからのリクエストを受け付け、ステップ602でデータをキュー133に格納する。これらの処理を繰り返し実行する。
【0014】
図7に、トランザクション管理機能132の処理フローチャート700を示す。トランザクション管理機能132では、まずステップ701で、定義ファイル134からしきい値の値を取得し、キュー133から該キュー133に現在格納されているデータの個数(詳しくは、全体のデータ数のほか、種別“ON”のデータの個数、及び種別“PR”のデータがあるかどうか)を取得する。次に、ステップ702で、ステップ701で得たしきい値の値とキュー133に格納されている種別が“ON”であるデータの個数とを比較する。種別“ON”のデータの個数がしきい値以上であるときは、オンライン処理要求の数がしきい値以上ということであるから、ステップ703でバッチ処理に停止指示を出し、ステップ701に戻る。例えば、図5に示したようにしきい値の値が5である場合は、オンライン処理要求の個数が5個以上のときにバッチ処理が停止され、オンライン処理が優先的に実行される。
【0015】
ステップ702でしきい値の値のほうが大きい場合、ステップ704で、キュー133に格納されたデータの個数が0であるかどうかを判断する。データの個数が0であれば、処理要求がないということであるから、ステップ701に戻る。データの個数が0でない場合、ステップ705で、キュー133に処理中のバッチ処理があるかどうか、すなわち種別“PR”のデータがあるかどうかを判断する。処理中のバッチ処理がある場合、ステップ706で、その種別“PR”のデータをキュー133から取り出し、そのデータに基づいてバッチ処理(図9)を起動し、ステップ701に戻る。キュー133に処理中のバッチ処理がない場合は、ステップ707に進む。
【0016】
ステップ707で、キュー133(図2)からデータ(1レコード)を取得する(取り出す)。ステップ708で、取得したデータの種別が“ON”であるかどうかを判断する。データの種別が“ON”である場合は、ステップ709で、取得したデータに基づいてオンライン処理(図8)を起動し、ステップ701に戻る。キュー133から取得したデータの種別が“ON”でない場合は、取得したデータがバッチ処理要求(種別“BA”)であるということである。この場合は、ステップ710で、しきい値とキュー133のデータ中の種別が“ON”であるデータの個数とを比較する。種別“ON”の個数がしきい値の値以上のときは、オンライン処理要求が多いということであるから、ステップ711でデータ(ステップ707で取り出した種別“BA”のデータ)をキュー133に戻して、ステップ701に戻る。ステップ710でしきい値の値のほうが大きい場合は、オンライン処理要求が少ないということであるから、ステップ712で前記取得したデータに基づいてバッチ処理(図9)を起動し、ステップ701に戻る。
【0017】
図8に、オンラインアプリケーション141の処理(ステップ709)のフローチャートを示す。ステップ801で、トランザクションを開始する。ステップ802で、与えられたデータ(会員コードと商品コードと数量)をデータベース150に格納する。ステップ803で、コミット(Commit)処理、すなわちデータベース150へのデータ変更を確定する処理を行う。ステップ804で、トランザクションを終了する。
【0018】
図9に、バッチアプリケーション142の処理(ステップ706,712)のフローチャートを示す。ステップ901で、トランザクションを開始する。ステップ902で、バッチ処理するデータファイル(図3)から1レコード取り出しデータベース150(図4)に格納する。ステップ903で、バッチ処理停止指示(ステップ703の指示)が出ているかどうかを判断する。バッチ処理停止指示が出ている場合は、ステップ905に進み、データベースをコミットしてそれまでの処理を確定させる。その後、ステップ906でトランザクションを終了(中断)し、ステップ907で処理を中断したデータファイルを特定する種別“PR”のレコードをキュー133(図2)に戻す。このとき、処理の状況206には、処理を中断した位置を格納しておくものとする。
【0019】
ステップ903でバッチ処理停止指示が出ていない場合は、ステップ904で、バッチ処理が終了したかどうか(すなわち、データファイル(図3)の内容をすべてデータベース(図4)に格納したかどうか)を判断する。バッチ処理が終了していない場合は、ステップ902に戻る。バッチ処理が終了した場合は、ステップ905でデータベースをコミットして処理を確定させ、ステップ906でトランザクションを終了する。この場合、ステップ907は行わない。
【0020】
次に、上述の本実施形態のシステムの全体の動きを具体例で説明する。
【0021】
オンラインクライアント100,110は商品コードと数量を指定して、またバッチクライアント120は図3のようなデータファイルを指定して、それぞれ要求受付機能131に要求を発行する。要求を受けた要求受付機能131は、図6に示したフローチャートに示す通り、要求を待ち受け、受け付けた要求の内容をキュー133(図2)に格納する。オンラインクライアント100,110からの要求を受け付けた場合は種別201を“ON”とし、バッチクライアント120からの要求を受け付けた場合は種別201を“BA”とする。オンラインクライアント100,110は、要求時に会員コードと商品コードと数量を伝えるものとし、要求受付機能131は受け取った会員コードと商品コードと数量をキュー133(図2)の該当する欄ににそれぞれ格納する。バッチクライアント120は、図3に示すデータファイル300を要求受付機能131に渡すものとし、要求受付機能131は受け取ったデータファイル300の格納先をキュー133のデータファイル205の欄に書き込む。
【0022】
トランザクション管理機能132は、図7に示す通り、定期的にキュー133を監視し、キュー133に要求があれば、種別に応じたアプリケーションに処理を依頼する。オンラインアプリケーション141及びバッチアプリケーション142はそれぞれマルチスレッドで複数の要求を同時に処理することが可能であるものとする。オンラインアプリケーション141は、図8に示す通り、要求に応じてデータベース150にデータを格納する。バッチアプリケーション142は、図9に示す通り、要求と同時に受け取ったデータファイルの内容に従って、データベース150に複数のデータを格納する。
【0023】
本実施形態のトランザクション管理機能132は、キュー133に格納された要求のうち種別が“ON”の要求の数が、定義ファイル134のしきい値で定義された数よりも多いかどうかを判定する。多い場合には、オンライン処理要求が多いということであるから、バッチアプリケーション142に一時停止の指示を出す。一時停止の指示を受けたバッチアプリケーション142は、データファイル300の読み込みを中止し、一度データベース150をコミットする。そして、当該処理途中のデータファイルについては、種別“PR”のレコードをキュー133に戻して、バッチアプリケーション142を一時的に停止させる。なお、データファイル300のどこまで処理したかを、処理の状況206の欄に格納しておくものとする。
【0024】
トランザクション管理機能132は、再びキュー133の監視を継続し、キュー133に格納された要求のうち種別が“ON”になっているものの数が、定義ファイル134のしきい値で定義された数よりも少なくなったとき、キュー133に処理途中のバッチ処理があるかどうかを調べ、あればそのバッチ処理の再開の指示をバッチアプリケーション142に出す。再開の指示を受けたバッチアプリケーション142は、中断していたデータファイル300の読み込みを再開し、処理を続行する。
【0025】
さらに、トランザクション管理機能132はキュー133を監視し、キュー133から取得したデータの種別が“BA”であり、キュー133に格納された要求のうち種別が“ON”になっているものの数が定義ファイル134のしきい値で定義された数より多ければ、データをキュー133に格納し、バッチサービスを後に回し、オンラインサービスを優先して処理する。
【0026】
なお、上記実施形態では、図1に示すように、オンラインアプリケーション141とバッチアプリケーション142とを分けた例で説明した。これらのアプリケーションは共通する処理を行う部分が多いので、両機能を備えた1つのアプリケーションとすることもできる。図10に、図1のオンラインアプリケーション141とバッチアプリケーション142の両方を兼ね備えたオンライン・バッチアプリケーション143を有するプログラム制御システムの構成を示す。他の部分は、上記実施形態と同様である。図7に示したトランザクション管理機能132の処理のフローチャートに従うことで、図10に示すように1つのプログラムでオンライン・バッチアプリケーション143を実現することが可能となる。
【0027】
また、上記実施の形態では、項目501としてオンライン要求数についてのしきい値だけを定義したが、バッチ処理数、オンライン処理の実行数、実行可能最大数、あるいは実行可能最小数などをしきい値として定義して、オンライン処理とバッチ処理とを効率よく同時に実行させることも可能である。複数のしきい値の判別を組み合わせることも可能である。
【0028】
上記のようにすることによって、オンラインクライアントの要求が多いときにはオンラインアプリケーションの処理を優先し、逆にオンラインクライアントの要求が少ないときにはバッチ処理を行わせることが可能となる。
【0029】
【発明の効果】
以上説明したように、本発明によれば、オンライン処理とバッチ処理を効率よく同時に実行することができる。また、オンラインの処理状況を考慮し、バッチ処理を起動することができる。
【図面の簡単な説明】
【図1】本発明の実施形態に係るシステムの全体構成を示す図である。
【図2】キューの詳細図である。
【図3】データファイルの詳細図である。
【図4】データベースのテーブル構造図である。
【図5】定義ファイルの詳細図である。
【図6】要求受付機能の処理の流れを示すフローチャートである。
【図7】トランザクション管理機能の処理の流れを示すフローチャートである。
【図8】オンラインアプリケーションの処理の流れを示すフローチャートである。
【図9】バッチアプリケーションの処理の流れを示すフローチャートである。
【図10】本発明の変形例の構成を示す図である。
【符号の説明】
100,110……オンラインクライアント
120……バッチクライアント
130……サーバ
131……要求受付機能
132……トランザクション管理機能
133……キュー
134……定義ファイル
141……オンラインアプリケーション
142……バッチアプリケーション
143……オンライン・バッチアプリケーション
150……データベース
160……ネットワーク
Claims (6)
- ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上でオンライン処理サービスまたはバッチ処理サービスに処理を振り分けるプログラム制御方法であって、
オンライン処理サービスへの要求に関し、前記サーバ上でそれらの要求を処理する際の負荷を判断する指標となるしきい値を定義するステップと、
前記しきい値を指標として、オンライン処理サービスへの要求にかかる負荷が大きいかどうかを判定するステップと、
オンライン処理サービスへの要求にかかる負荷が大きいと判定されたとき、バッチ処理サービスを一時的に停止させるステップと
を備えることを特徴とする負荷バランス機能を有するプログラム制御方法。 - 請求項1に記載のプログラム制御方法において、
オンライン処理サービスへの要求数とバッチ処理サービスへの要求数に応じて、オンライン処理サービスとバッチ処理サービスを切り替えて実行するステップをさらに備えたことを特徴とする負荷バランス機能を有するプログラム制御方法。 - ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上でオンライン処理サービスまたはバッチ処理サービスに処理を振り分けるプログラム制御方法であって、
オンライン処理サービスへの要求数のしきい値を定義するステップと、
前記しきい値とオンライン処理サービスへの要求数を比較するステップと、
オンライン処理サービスへの要求数が前記しきい値を超えた場合にバッチ処理サービスを一時的に停止させるステップと
を備えることを特徴とする負荷バランス機能を有するプログラム制御方法。 - 請求項3に記載のプログラム制御方法において、
前記バッチ処理を一時的に停止させるとき、処理を中断したデータファイルを処理中のバッチ処理として保持しておくステップと、
オンライン処理サービスへの要求数が前記しきい値より小さくなったとき、バッチ処理再開の指示を出すステップと、
再開の指示を受けたバッチアプリケーションが、前記保持してあった処理中のバッチ処理のデータファイルの読み込みを再開し、バッチ処理を行うステップと
を備えたことを特徴とする負荷バランス機能を有するプログラム制御方法。 - 請求項3に記載のプログラム制御方法であって、
前記オンライン処理サービスを行うプログラムと前記バッチ処理サービスを行うプログラムとが1つのプログラムで実現されていることを特徴とする負荷バランス機能を有するプログラム制御方法。 - ネットワークに接続されたクライアントシステムからの要求に応じて、サーバ上でオンライン処理サービスまたはバッチ処理サービスに処理を振り分けるプログラム制御システムであって、
オンライン処理サービスへの要求に関し、前記サーバ上でそれらの要求を処理する際の負荷を判断する指標となるしきい値を定義する手段と、
前記しきい値を指標として、オンライン処理サービスへの要求にかかる負荷が大きいかどうかを判定する手段と、
オンライン処理サービスへの要求にかかる負荷が大きいと判定されたとき、バッチ処理サービスを一時的に停止させる手段と
を備えることを特徴とする負荷バランス機能を有するプログラム制御システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002256493A JP2004094711A (ja) | 2002-09-02 | 2002-09-02 | 負荷バランス機能を有するプログラム制御方法及びシステム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002256493A JP2004094711A (ja) | 2002-09-02 | 2002-09-02 | 負荷バランス機能を有するプログラム制御方法及びシステム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004094711A true JP2004094711A (ja) | 2004-03-25 |
Family
ID=32061704
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002256493A Pending JP2004094711A (ja) | 2002-09-02 | 2002-09-02 | 負荷バランス機能を有するプログラム制御方法及びシステム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004094711A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007179304A (ja) * | 2005-12-28 | 2007-07-12 | Hitachi Ltd | 実行ユーザ数によるバッチ処理とオンライン処理の排他制御方法 |
WO2007125942A1 (ja) * | 2006-04-26 | 2007-11-08 | Nippon Telegraph And Telephone Corporation | 負荷制御装置およびその方法 |
WO2013171854A1 (ja) * | 2012-05-16 | 2013-11-21 | 株式会社日立製作所 | 計算機、スレッド割当管理方法及びプログラム |
JP2014049112A (ja) * | 2012-08-29 | 2014-03-17 | Fujitsu Ltd | 情報処理装置、プログラム、およびジョブ制御方法 |
-
2002
- 2002-09-02 JP JP2002256493A patent/JP2004094711A/ja active Pending
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007179304A (ja) * | 2005-12-28 | 2007-07-12 | Hitachi Ltd | 実行ユーザ数によるバッチ処理とオンライン処理の排他制御方法 |
WO2007125942A1 (ja) * | 2006-04-26 | 2007-11-08 | Nippon Telegraph And Telephone Corporation | 負荷制御装置およびその方法 |
CN102684988A (zh) * | 2006-04-26 | 2012-09-19 | 日本电信电话株式会社 | 负荷控制装置及其方法 |
JP5189974B2 (ja) * | 2006-04-26 | 2013-04-24 | 日本電信電話株式会社 | 負荷制御装置およびその方法 |
US8667120B2 (en) | 2006-04-26 | 2014-03-04 | Nippon Telegraph And Telephone Corporation | Load control device and method thereof for controlling requests sent to a server |
CN102684988B (zh) * | 2006-04-26 | 2015-02-11 | 日本电信电话株式会社 | 负荷控制装置及其方法 |
WO2013171854A1 (ja) * | 2012-05-16 | 2013-11-21 | 株式会社日立製作所 | 計算機、スレッド割当管理方法及びプログラム |
JP2014049112A (ja) * | 2012-08-29 | 2014-03-17 | Fujitsu Ltd | 情報処理装置、プログラム、およびジョブ制御方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3944154B2 (ja) | マルチスレッド・サーバ内のスレッド・プールを動的に調整する方法およびシステム | |
US8276146B2 (en) | Grid non-deterministic job scheduling | |
CN107370667B (zh) | 多线程并行处理方法和装置、可读介质和存储控制器 | |
US9424077B2 (en) | Throttle control on cloud-based computing tasks utilizing enqueue and dequeue counters | |
US6349321B1 (en) | Data processing system and scheduling method | |
US10089142B2 (en) | Dynamic task prioritization for in-memory databases | |
US6453313B1 (en) | Database management system and method for dequeuing rows published to a database table | |
JP4694595B2 (ja) | スリープキュー管理 | |
US6397227B1 (en) | Database management system and method for updating specified tuple fields upon transaction rollback | |
US7051330B1 (en) | Generic application server and method of operation therefor | |
US8438282B2 (en) | Information processing system and load sharing method | |
JP3987384B2 (ja) | 実行キュー管理 | |
US20030233392A1 (en) | Method and system for managing the execution of threads and the processing of data | |
KR20040062410A (ko) | 응답 시간에 기초하여 프로그램적으로 작업 부하를분산시키는 기술 | |
JP2000029815A (ja) | スレッド・サ―バのパフォ―マンス強化方法および装置 | |
US8082307B2 (en) | Redistributing messages in a clustered messaging environment | |
US20040202165A1 (en) | Message processing apparatus, method and program | |
CN107368324A (zh) | 一种组件升级方法、装置和系统 | |
US8612597B2 (en) | Computing scheduling using resource lend and borrow | |
CN101114984A (zh) | 一种多线程网络负载控制方法 | |
JP2004094711A (ja) | 負荷バランス機能を有するプログラム制御方法及びシステム | |
KR100848323B1 (ko) | 임베디드 운영체제 커널의 실시간 성능을 향상시키는 방법 | |
JP2020135189A (ja) | データベース管理システム、及び、データベース管理方法 | |
Shanker et al. | Priority assignment heuristic to cohorts executing in parallel | |
JP2519792B2 (ja) | ジョブ優先度設定方式 |