JP4189374B2

JP4189374B2 - 処理システム

Info

Publication number: JP4189374B2
Application number: JP2004336274A
Authority: JP
Inventors: 津敏加藤
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2004-11-19
Filing date: 2004-11-19
Publication date: 2008-12-03
Anticipated expiration: 2024-11-19
Also published as: JP2006146589A

Description

本発明は、複数のクライアントから依頼された大量のバッチ処理を複数のサーバで分担して処理するクライアントサーバシステムに関する。

病院における電子カルテシステムなどでは、例えば、処方オーダ発行処理、検査オーダ発行処理、マスタ更新処理など多種類でかつ大量のバッチ処理を効率よく処理する必要がある。そのため、従来から大型コンピュータシステムが広く用いられているが、最近はコスト面で有利な、複数のサーバからなる分散システムが多用されるようになりつつある。

通常、この分散システムにおいては、各サーバの処理効率を高めるために、各サーバごとに分担する業務を割り振り、それぞれの業務専用のサーバとして並列する方式が採用されることが多い。この方式では、予め各業務ごとの業務量をできるだけ正確に見積もった上で各サーバに処理を分担させる必要があるが、実際の業務量は絶えず変動していることが多く、各サーバの負荷にアンバランスが生じやすく、極端な場合には一部のサーバは遊休状態であるにもかかわらず、他のサーバに大量の処理依頼が集中しそのために全体としてシステムダウンに陥ることがある。

そこで、各サーバの役割分担を固定せずに、複数のサーバが全ての業務を処理できるようにしておくとともに、複数のクライアントからの業務の処理依頼をこれら複数のサーバに分配して処理を実行させる処理方式が考案されている。

例えば、一般的な数値演算処理、事務計算処理、あるいは画像解析や画像処理などの分野において利用可能な、複数処理演算器それぞれがそれぞれの処理を独立して実行可能であるとともに、処理データの受渡しを伴う独立した処理間の同期を考慮した複数処理演算器の処理方法が開示されている（例えば、特許文献１参照。）。
特開平６−０２８１８６号公報（第１−３頁、図１）

上記のような処理方法においては、各処理演算器で行われる処理間の同期や処理データの受渡しをどのように行うかが重要な問題であり、その解決するための種々の提案がなされている。

特に、前述の電子カルテシステムなどでは、全体の業務量が多いだけでなく業務の種類が多岐にわたりかつ各業務ごとの処理量の変動も多く、処理を依頼する複数のクライアントと、処理を実行する複数のサーバとの間の連絡の仕組みに不備がある場合には正確かつ円滑な運用を行うことはできない。すなわち、クライアントから依頼された処理は全て漏れなく実行されなければならず、また、クライアントから依頼された処理が重複して実行されることは許されない。

さらに、複数のサーバで処理される互いに関連のある処理は論理的に整合性がとられた状態で処理されなければならない。例えば、あるクライアントからの処方オーダに関する処理依頼をサーバＳ１が受け、その処理が完了しないうちに何らかの原因でサーバＳ１による処理が中断している間に、クライアント側において、先に処理依頼した処方オーダの内容に誤りが発見され、その誤りのある処方オーダに代わり正しい処方オーダの処理依頼が出されたとする。その処理依頼を他のサーバ、例えばサーバＳ２が受けて処理を実行したとする。その後、サーバＳ１における中断の原因が解消され中断していた処理が再開されその処理が完了すると、サーバＳ１による処理結果（誤りのある処方オーダ）によってサーバＳ２による処理結果（正しい処方オーダ）が上書きされてしまい、薬局では誤りのある処方オーダに基づく処方が行われ、場合によっては重大な医療事故を惹き起こすこととなる。このように、複数の処理を単に時系列的に実行するだけではなく、互いに論理的に関連のある処理を複数の処理サーバで実行する場合には、論理的に整合性のとれた処理が行われる必要がある。

本発明は、上記事情に鑑み、複数のクライアントからの処理依頼を、複数の処理サーバにより、重複や漏れがなくかつ論理的に整合性のとれた処理を行うことのできる処理システム、およびそのために用いられる調停サーバを提供することを目的とする。

上記課題を解決する本発明の処理システムは、
処理を依頼する複数のクライアントからの処理依頼を受け付けて受付順に並べる受付サーバと、
上記受付サーバが受け付けた処理依頼に係る処理を実行する複数の処理サーバと、
上記複数の処理サーバによる処理の実行を調停する調停サーバとを備え、
上記受付サーバが、上記複数のクライアントから受け付けた処理依頼のうちの、上記複数の処理サーバのいずれかから処理の終了報告を受けた処理依頼を処理済として区別するものであり、
上記調停サーバが、上記複数の処理サーバそれぞれから当該処理サーバで実行予定の処理の登録要求を受けて同一処理の重複登録を排除して処理の登録を受け付けるとともに、受け付けた登録の要求元の処理サーバによる該登録に係る処理の実行を監視し実行中断時には該登録を取り消すものであり、
上記複数の処理サーバそれぞれが、上記受付サーバにより受け付けられている処理依頼のうちの処理済の処理依頼を除く処理依頼を受付順に一つずつ取り出して、上記調停サーバへの、取り出した処理依頼に係る処理の登録を試み、該調停サーバに登録が受け付けられた処理を実行して該処理の実行終了時に上記受付サーバに該処理の終了報告を行うものであることを特徴とする。

本発明の処理システムによれば、上記のような受付サーバ、処理サーバ、および調停サーバを備えたことにより、複数のクライアントからの処理依頼を、複数の処理サーバにより、重複や漏れがなくかつ論理的に整合性のとれた処理を行うことができる。

ここで、上記調停サーバは、受け付けた登録の要求元の処理サーバによる該登録に係る処理の実行を監視し実行中断時に該登録を取り消すとともに、該処理の終了時にも該処理の登録を抹消するものであってもよい。

本発明の処理システムを上記のように構成した場合は、複数のクライアントからの処理依頼を、複数の処理サーバによってより確実な処理を行うことができる。

また、上記調停サーバは、処理の登録の受付けにあたり該登録を要求した処理サーバとの通信を確立するとともに該処理の実行終了時に該通信を切断するものであって、通信を確立した後、処理実行終了を待たずに通信が切断されたことをもって、該処理に実行が中断されたものとして該処理の登録を取り消すものであってもよい。

また、上記受付サーバが、ハードウェア上は上記調停サーバを兼ねたものであってもよい。

本発明の処理システムを上記のように構成した場合は、効率的な処理システムを形成することができる。

また、上記課題を解決する本発明の調停サーバは、
処理を実行する複数の処理サーバによる処理の実行を、これら複数の処理サーバで複数の処理が分担して実行されるように調停する調停サーバであって、
上記複数の処理サーバそれぞれから当該処理サーバで実行予定の処理の登録要求を受けて同一処理の重複登録を排除して処理の登録を受け付けるとともに、受け付けた登録の要求元の処理サーバによる該登録に係る処理の実行を監視し実行中断時には該登録を取り消すものであることを特徴とする。

本発明の調停サーバによれば、複数のクライアントからの処理依頼を、複数の処理サーバにより、重複や漏れがなくかつ論理的に整合性のとれた処理を行うことのできる処理システムを形成することができる。

以上説明したように、本発明の処理システムおよび調停サーバによれば、上記のような構成としたことにより、複数のクライアントからの処理依頼を、複数の処理サーバにより、重複や漏れがなくかつ論理的に整合性のとれた処理を行うことの可能な処理システムおよび調停サーバを実現することができる。

以下図面を参照して本発明の処理システムおよび調停サーバの実施の形態を説明する。

図１は、本発明の処理システムの一実施形態を示す概略構成図である。

図１に示すように、本実施形態の処理システム１０は、処理を依頼する複数のクライアント２０からの処理依頼を受け付けて受付順に並べる受付サーバ３０と、受付サーバ３０が受け付けた処理依頼に係る処理を実行する複数の処理サーバ５０Ａ，５０Ｂ，…５０Ｎと、複数の処理サーバ５０Ａ，５０Ｂ，…５０Ｎによる処理の実行を調停する調停サーバ４０とを備えている。これらの各クライアントおよび各サーバは通信回線６０により相互に接続されている。

受付サーバ３０は、上記複数のクライアント２０から受け付けた処理依頼のうちの、上記複数の処理サーバ５０Ａ，５０Ｂ，…５０Ｎのいずれかから処理の終了報告を受けた処理依頼を処理済として区別するものである。

調停サーバ４０は、上記複数の処理サーバ５０Ａ，５０Ｂ，…５０Ｎそれぞれから当該処理サーバで実行予定の処理の登録要求を受けて同一処理の重複登録を排除して処理の登録を受け付けるとともに、受け付けた登録の要求元の処理サーバによる該登録に係る処理の実行を監視し実行中断時には該登録を取り消すものである。

また、複数の処理サーバ５０Ａ，５０Ｂ，…５０Ｎそれぞれは、上記受付サーバ３０により受け付けられている処理依頼のうちの処理済の処理依頼を除く処理依頼を受付順に一つずつ取り出して、上記調停サーバ４０への、取り出した処理依頼に係る処理の登録を試み、該調停サーバ４０に登録が受け付けられた処理を実行して該処理の実行終了時に上記受付サーバ３０に該処理の終了報告を行うものである。

なお、本実施形態では、上記調停サーバ４０は、受け付けた登録の要求元の処理サーバによる該登録に係る処理の実行を監視し実行中断時に該登録を取り消すとともに、該処理の終了時にも該処理の登録を取り消すものとして構成されている。

また、本実施形態では、上記調停サーバ４０は、処理の登録の受付けにあたり該登録を要求した処理サーバとの通信を確立するとともに該処理の実行終了時に該通信を切断するものであって、通信を確立した後、処理実行終了を待たずに通信が切断されたことをもって、該処理が中断されたものとして該処理の登録を取り消すように構成されている。

また、本実施形態では、上記受付サーバ３０は、ハードウェア上は上記調停サーバ４０を兼ねたものとして構成されている。

次に、本実施形態の処理システムのハードウエアについて説明する。

図２は、本実施形態の処理システムが形成されるコンピュータシステムの概要図である。

図２には、図１に示した複数のクライアント、受付サーバ、処理サーバ、および複数の調停サーバとを備えた本実施形態の処理システム１０が形成されるコンピュータシステムの概要が示されている。

図２に示すように、複数のクライアント２０（図１参照）を構成するコンピュータ８０＿１，８０＿２，８０＿３と、受付サーバ３０（図１参照）と調停サーバ４０（図１参照）を兼ねたコンピュータ９０＿１、および複数の処理サーバ５０Ａ，５０Ｂ，…５０Ｎ（図１参照）を構成するコンピュータ９０＿２、９０＿３，…が通信回線６０によって相互に接続されている。

これらの各コンピュータ８０＿１，８０＿２，…、９０＿１，９０＿２，…は、ＣＰＵ、主記憶装置、ハードディスク、通信用ボード等が内蔵された本体部８０ａ，８０ｂ，…、９０ａ，９０ｂ，…、これら本体部からの指示により画面上に画像や文字列を表示する表示装置８１ａ，８１ｂ，…、９１ａ，９１ｂ，…、各コンピュータにオペレータからの指示を入力するためのキーボード８２ａ，８２ｂ，…、９２ａ，９２ｂ，…、および表示画面上の任意の位置を指定することにより、その指定された位置に表示されていたアイコン等に応じた指示を入力するマウス８３ａ，８３ｂ，…、９３ａ，９３ｂ，…を備えている。

本体部８０ａ，８０ｂ，…、９０ａ，９０ｂ，…は、さらに外観上、フレキシブルディスク（図示せず）、ＭＯ（光磁気ディスク）８６、９６が装填されるＦＤ装填口８４ａ，８４ｂ，…、９４ａ，９４ｂ，…、ＭＯ装填口８５ａ，８５ｂ，…、９５ａ，９５ｂ，…を有しており、それらの内部には、それらの装填口から装填されたフレキシブルディスクやＭＯをドライブしてアクセスするフレキシブルディスクドライブユニット、ＭＯドライブユニットが内蔵されている。

次に、本実施形態の処理システムに用いられる受付テーブルについて説明する。

図３は、本実施形態の処理システムに用いられる受付テーブルの概要図である。

図３に示すように、この受付テーブル３１は、受付サーバ３０（図１参照）に備えられるテーブルであり、クライアントから処理依頼を受け付けた日時が書き込まれる書込日時３１ａ、当該処理依頼が処理済であるか否かを区別する処理済フラグ３１ｂ、各レコードを論理的に識別する一意の連番である更新キー３１ｃ、更新されるレコード内容である更新データ３１ｄなどの項目を有しており、処理を依頼する複数のクライアント２０（図１参照）からの処理依頼がレコード３１＿１，３１＿２，…のように受付順に並んで記憶されている。

なお、上記処理済フラグ３１ｂには、この受付テーブル３１に最初に当該レコードが書き込まれた時には「未」が書き込まれ、処理サーバから当該処理の終了報告を受けた時に「済」が上書きされるようになっている。

また、一旦処理された更新データを修正する場合には、更新キー３１ｃとして元の更新データの更新キー３１ｃと同一の値が与えられる。

次に、本実施形態の処理システムの動作について説明する。

図４は、本実施形態の処理システムの動作を示すフローチャートである。

図４には、処理サーバの一例として処理サーバ５０Ａ（図１参照）の動作が受付サーバ３０および調停サーバ４０とともに示されている。

処理サーバ５０Ａは、先ず、調停サーバ４０（図１参照）上に割り当てられた自分用のサービスに対して通信回線６０を介して接続を試みる（ステップＳ０１）。

通信回線６０による調停サーバ４０との通信が確立し接続に成功すると（ステップＳ０２）、ステップＳ０３に進み、受付サーバ３０（図１参照）に備えられている受付テーブル３１（図３参照）のレコードの中から処理済フラグ３１ｂが「未」であり、かつ書込日時３１ａの最も古いレコード３１＿２を取り出す（ステップＳ０３）。

次に、取り出したレコード３１＿２に係る処理の登録を調停サーバ４０（図１参照）に対して試みる。すなわち、具体的にはレコード３１＿２の更新キー３１ｃ「１０００１００」を識別キーとして、レコード「１０００１００」のロック要求を発行する（ステップＳ０４）。

ステップＳ０５では、調停サーバ４０により、調停サーバ４０内のスレッドの検索が行われ、レコード「１０００１００」に関するスレッドが存在するか否かが判定される。図４に示す例では、レコード「１０００１００」に関するスレッドは存在していなかったので、調停サーバ４０は、処理サーバ５０Ａからのロック要求に基づきレコード「１０００１００」に関する「スレッド１」を書き込むとともに、応答「ＯＫ」を処理サーバ５０Ａに返す。こうして、「１０００１００」はロックされる。

ステップＳ０５における判定の結果、ロック要求は成功であるのでステップＳ０６に進む。なお、ステップＳ０５において、レコード「１０００１００」に関するスレッドが調停サーバ４０にすでに存在している場合には、処理サーバ５０Ａからのロック要求は拒絶され、応答「ＮＧ」が処理サーバ５０Ａに返される。その場合はステップＳ０１に戻り、ステップＳ０１以降の処理が繰り返される。

ステップＳ０６では、調停サーバ４０からの応答が「ＯＫ」か否かが判定され、「ＯＫ」の場合はステップＳ０７に進み、「ＯＫ」ではない場合はステップＳ０３に戻り、受付テーブルから次の未処理レコードの取り出し処理が繰り返されることになるが、この例では応答は「ＯＫ」であるので、ステップＳ０７に進み、ＯＫとなったレコードに対する処理が実行される。処理が終了すると受付サーバ３０に当該処理の終了報告が行われた後、ステップＳ０３に戻り、次の未処理レコードの処理が行われる。

図５は、本実施形態における他の処理サーバの動作を示すフローチャートである。

図５に示すように処理サーバ５０Ｂは、調停サーバ４０（図１参照）上に割り当てられた自分用のサービスに対して通信回線６０を介して接続を試みる（ステップＳ１１）。

通信回線６０による調停サーバ４０との通信が確立し接続に成功すると（ステップＳ１２）、ステップＳ１３に進み、受付サーバ３０（図１参照）に備えられている受付テーブル３１（図３参照）のレコードの中から処理済フラグ３１ｂが「未」であり、かつ書込日時３１ａの最も古いレコード３１＿２を取り出す（ステップＳ１３）。

次に、取り出したレコード３１＿２に係る処理の登録を調停サーバ４０（図１参照）に対して試みる。すなわち、具体的にはレコード３１＿２の更新キー３１ｃ「１０００１００」を識別キーとして、レコード「１０００１００」のロック要求を発行する（ステップＳ１４）。

ステップＳ１５では、調停サーバ４０により、調停サーバ４０内のスレッドの検索が行われ、レコード「１０００１００」に関するスレッドが存在するか否かが判定される。図５に示す例では、処理サーバ５０Ａにより「１０００１００」に関する「スレッド１」がすでに書き込まれているので、調停サーバ４０は、処理サーバ５０Ｂからのロック要求を拒絶し、応答「ＮＧ」が処理サーバ５０Ｂに返される。こうして、処理サーバ５０Ａによりロックされている「１０００１００」の重複処理が排除される。

ステップＳ１５における判定の結果、ロック要求は不成功であるのでステップＳ１１に戻り、ステップＳ１１以降の処理が繰り返される。なお、ステップＳ１５における判定の結果、ロック要求が成功の場合には、図4に示したのと同様、ステップＳ１６、ステップＳ１７以降の処理が続けられる。

調停サーバ４０は、上記図４および５に例示したような方法で、複数の処理サーバによる処理の実行を調停する。

なお、本実施形態における調停サーバのサービスは、本発明にいう調停サーバの登録に相当するものであり、また、本実施形態における処理サーバによるロック要求は、本発明にいう処理サーバによる処理の登録要求に相当するものであり、また、本実施形態におけるスレッドは、本発明にいう処理の登録により調停サーバに記憶された記憶内容に相当するものである。

図６は、本実施形態の処理システムの動作を示すタイムチャートである。

図６には、例として、調停サーバの処理サーバＡに対するサービス１、および処理サーバＢに対するサービス２のタイムチャートが示されている。

図４を参照して説明した通り、処理サーバＡからの処理依頼を受けて、調停サーバが、時刻ｔ１に、処理サーバＡに対する「サービス１」を開始し、その処理が長時間続いている様子が示されている。この「サービス１」は、図３に示した受付テーブル３１の上から２つ目の未処理レコード、すなわち、書込日時：「２００４／１０／３０１３：００：１０」、更新キー：「１０００１００」なるレコード３１＿２に対応する調停サーバのサービスである。

前述のように、この「サービス１」により「１０００１００」はロックされ、同一処理の重複登録が排除されている。処理サーバＡによる処理が長時間を要するものであってもその処理が終了するまでは、図５を参照して説明した通り、処理サーバＢは更新キー「１０００１００」に対してサービスを受けることはできない。

そこで、処理サーバＢは、受付テーブル３１（図３参照）の中からレコード３１＿２：「１０００１００」の次の未処理のレコード３１＿３：書込日時「２００４／１０／３０１３：００：２０」、更新キー「１０００１０１」を取り出し、調停サーバ４０に登録（サービス）を要求し、その要求に基づき、調停サーバ４０は時刻ｔ２に処理サーバＢに対し「サービス２」を開始する。

この処理サーバＢによる「１０００１０１」の処理は短時間、すなわち時刻ｔ３に完了したとすると、処理サーバＢは受付テーブル３１（図３参照）の中から処理済ではない次のレコード３１＿４を取り出し、ｔ４の時点で調停サーバ４０に登録（サービス）を要求する。しかし、このレコード３１＿４は、レコード３１＿２の修正レコードであり互いに論理的に関連があるので、レコード３１＿２の更新キー：「１０００１００」と同一の更新キーが付されている。

時刻ｔ４の時点では「サービス１」によるレコード３１＿２（更新キー：「１０００１００」）の処理は継続中であり、この継続中のレコード３１＿２の更新キー：「１０００１００」は「サービス１」によりロックされており、処理サーバＢからのレコード３１＿４に対するサービス要求は拒絶される。そこで、処理サーバＢは、レコード３１＿４の次の未処理のレコードを探すこととなる。

ここで、上記のレコード３１＿２が、例えば誤りのある処方オーダであり、レコード３１＿４が正しい処方オーダである場合に、レコード３１＿４に係る処理はレコード３１＿２によってロックされているので実行されることはない。従って、レコード３１＿４（正しい処方オーダ）が先に処理完了し、その後に、誤りのある処方オーダの処理結果によって正しい処方オーダの処理結果が上書きされてしまうようなことが未然に防止され、医療事故を未然に防止することができる。

なお、本実施形態では、調停サーバは、処理サーバによる処理が継続している間、すなわち、例えば処理サーバＡについては時刻ｔ１以降、処理サーバＢについては時刻ｔ２から時刻ｔ３まではサービス（登録）の要求元の処理サーバによる該登録に係る処理の実行を監視し、実行中断時には該登録を取り消すように構成されている。この監視は、通信回線６０の接続状態を監視することにより行われる。

なお、本実施形態では、処理の終了時、例えば時刻ｔ３、すなわち処理サーバＢによる処理終了時にも該処理の登録を抹消するように構成されている。

本実施形態の処理システムはこのように構成されているので、複数の処理サーバにより、重複や漏れがなくかつ論理的に整合性のとれた処理を行うことができる。

本発明の処理システムの一実施形態を示す概略構成図である。本実施形態の処理システムが形成されるコンピュータシステムの概要図である。本実施形態の処理システムに用いられる受付テーブルの概要図である。本実施形態の処理システムの動作を示すフローチャートである。本実施形態における他の処理サーバの動作を示すフローチャートである。本実施形態の処理システムの動作を示すタイムチャートである。

符号の説明

１０処理システム
２０クライアント
３０受付サーバ
４０調停サーバ
５０Ａ，５０Ｂ，…５０Ｎ処理サーバ
６０通信回線

Claims

処理を依頼する複数のクライアントからの処理依頼を受け付ける受付サーバと、前記受付サーバが受け付けた処理依頼に係る処理を実行する複数の処理サーバと、前記複数の処理サーバによる処理の実行を調停する調停サーバとを備えた処理システムであって、
前記受付サーバは、
前記クライアントから、論理的に関係のある複数の処理依頼を識別するための更新キーを含む処理依頼情報を受信して、受付順に受付テーブルに記録する手段を備え、
前記調停サーバは、
前記処理サーバからの前記更新キーのロック要求を受け付ける手段と、
前記ロック要求に対応する更新キーが、自身のスレッドに存在するか否かを判定し、存在する場合にはＮＧ応答を前記処理サーバに返し、存在しない場合には前記更新キーを前記スレッドに書き込むとともにＯＫ応答を前記処理サーバに返す手段と、を備え、
前記処理サーバは、
前記受付サーバの前記受付テーブルの未処理の処理依頼情報のうち、最も古い処理依頼情報を取り出す取出し手段と、
前記取出し手段において取り出された処理依頼情報に含まれる更新キーのロック要求を、前記調停サーバに発行する発行手段と、
前記発行手段において発行されたロック要求に対する前記調停サーバからの応答がＯＫ応答であった場合には前記取出し手段において取り出された処理依頼情報に対する処理を実行し、ＮＧ応答であった場合には、前記受付テーブルの未処理の処理依頼情報を古い順に取り出して、前記調停サーバからＯＫ応答を受け付けるまで前記発行手段による処理を繰り返す手段と、を備えることを特徴とする処理システム。