JPH04157541A - 分散処理システムの多重データ処理方法 - Google Patents
分散処理システムの多重データ処理方法Info
- Publication number
- JPH04157541A JPH04157541A JP2283777A JP28377790A JPH04157541A JP H04157541 A JPH04157541 A JP H04157541A JP 2283777 A JP2283777 A JP 2283777A JP 28377790 A JP28377790 A JP 28377790A JP H04157541 A JPH04157541 A JP H04157541A
- Authority
- JP
- Japan
- Prior art keywords
- file
- message
- access request
- data
- processing system
- 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.)
- Granted
Links
- 238000012545 processing Methods 0.000 title claims abstract description 205
- 238000003672 processing method Methods 0.000 title claims description 30
- 230000004044 response Effects 0.000 claims description 157
- 238000000034 method Methods 0.000 claims description 130
- 230000005540 biological transmission Effects 0.000 claims description 56
- 238000004891 communication Methods 0.000 claims description 25
- 238000012905 input function Methods 0.000 abstract 1
- 238000010586 diagram Methods 0.000 description 8
- 230000004043 responsiveness Effects 0.000 description 7
- 230000007423 decrease Effects 0.000 description 4
- 230000000593 degrading effect Effects 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 3
- 238000007796 conventional method Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/161—Computing infrastructure, e.g. computer clusters, blade chassis or hardware partitioning
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Mathematical Physics (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Multi Processors (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Computer And Data Communications (AREA)
Abstract
(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。
め要約のデータは記録されません。
Description
【発明の詳細な説明】
〔産業上の利用分野〕
本発明は、それぞれ多重に配置したリソースを有する複
数のプロセッサをネットワークにより結合し、各プロセ
ッサで役割を分担して、多重リソースから発生するデー
タの処理を行なう分散処理システムの多重データ処理方
法に係り、特に、処理を進めながら各ファイルの整合性
を確認し、信頼性の高い分散処理を効率良く行なうのに
好適な分散処理システムの多重データ処理方法に関する
ものである。
数のプロセッサをネットワークにより結合し、各プロセ
ッサで役割を分担して、多重リソースから発生するデー
タの処理を行なう分散処理システムの多重データ処理方
法に係り、特に、処理を進めながら各ファイルの整合性
を確認し、信頼性の高い分散処理を効率良く行なうのに
好適な分散処理システムの多重データ処理方法に関する
ものである。
[従来の技術1
現在、コンピュータは、広い分野で利用され、その高速
性、信頼性の向上を主目的として、様々な研究開発がな
されている。
性、信頼性の向上を主目的として、様々な研究開発がな
されている。
特に、分散処理システムは、1960年代中期〜197
o代中期のメインフレーム、1970代中期〜1980
代初期のミニコンピユータ、そして、1980年代のパ
ーソナルコンピュータに続く第4の波として、コンピュ
ータ産業における成長が期待されている。
o代中期のメインフレーム、1970代中期〜1980
代初期のミニコンピユータ、そして、1980年代のパ
ーソナルコンピュータに続く第4の波として、コンピュ
ータ産業における成長が期待されている。
分散処理システムとは、複数のコンピュータを接続した
ネットワーク全体を、あたかも−台のコンピュータであ
るかの様に利用するものである。
ネットワーク全体を、あたかも−台のコンピュータであ
るかの様に利用するものである。
また、分散処理とは、通信回線で結ばれた複数のコンピ
ュータが協力しあって、一つのジョブを処理する処理形
態であり、各コンピュータには、そのジョブの一部を実
行するプロセッサが設けられ、それらがメツセージを授
受しあって処理を進める。
ュータが協力しあって、一つのジョブを処理する処理形
態であり、各コンピュータには、そのジョブの一部を実
行するプロセッサが設けられ、それらがメツセージを授
受しあって処理を進める。
分散処理の目的は、従来、−台のコンピュータに集中し
て処理させていた全ての仕事を、複数のコンピュータで
分散して処理することにより、機能分散、負荷分散、地
域分散、そして、高信頼化を得るものである。
て処理させていた全ての仕事を、複数のコンピュータで
分散して処理することにより、機能分散、負荷分散、地
域分散、そして、高信頼化を得るものである。
すなわち、それぞれのコンピュータに、それぞれ必要な
機能のみを持たせて、機能を分散することにより、それ
ぞれのコンピュータを小型化し、経済性を良くする。し
かも、各コンピュータが有する機能は高機能なものであ
り、全体として高機能のシステムが構築できる。
機能のみを持たせて、機能を分散することにより、それ
ぞれのコンピュータを小型化し、経済性を良くする。し
かも、各コンピュータが有する機能は高機能なものであ
り、全体として高機能のシステムが構築できる。
また、−台のコンピュータの計算速度、記憶容量、入出
力速度の能力以上の仕事に対しても、複数台のコンピュ
ータに分散して処理し、負荷の増減に柔軟に対応できる
。
力速度の能力以上の仕事に対しても、複数台のコンピュ
ータに分散して処理し、負荷の増減に柔軟に対応できる
。
また、すべての大量のデータを、遠距離にある一台のコ
ンピュータに送り処理していたのでは、データの伝送に
時間がかかる。しかし、地域分散により、簡単な前処理
を地域のコンピュータで行ない、その結果のみを中央に
送れば、一部の処理結果がその場で得られる。さらに、
伝送するデータの量が少なくて済む。
ンピュータに送り処理していたのでは、データの伝送に
時間がかかる。しかし、地域分散により、簡単な前処理
を地域のコンピュータで行ない、その結果のみを中央に
送れば、一部の処理結果がその場で得られる。さらに、
伝送するデータの量が少なくて済む。
また、−台のコンピュータですべての処理を行なうと、
そのコンピュータが故障した場合には、システム全体が
止まってしまう。しかし、分散処理により、複数のコン
ピュータに仕事を分担しておけば、その内の一台が故障
しても、多少性能は落ちても、残りのもので処理の続行
が可能であり、システムの信頼性が向上する。
そのコンピュータが故障した場合には、システム全体が
止まってしまう。しかし、分散処理により、複数のコン
ピュータに仕事を分担しておけば、その内の一台が故障
しても、多少性能は落ちても、残りのもので処理の続行
が可能であり、システムの信頼性が向上する。
このような、分散処理に関しては、電子情報通信学会編
「電子情報通信ハンドブックJ (1988年、オー
ム社発行)のpp、tsi5〜1626に記載されてい
る。
「電子情報通信ハンドブックJ (1988年、オー
ム社発行)のpp、tsi5〜1626に記載されてい
る。
さらに、近年の分散処理では、「日経エレクトロニクス
1990 6−11 no、502」(1990年
、日経BP社発行)のpp、i2i〜148に記載のよ
うに、異なるメーカの製品をネットワークで結ぶ異機種
間分散処理をサポートするものもある。
1990 6−11 no、502」(1990年
、日経BP社発行)のpp、i2i〜148に記載のよ
うに、異なるメーカの製品をネットワークで結ぶ異機種
間分散処理をサポートするものもある。
従来、分散処理システムにおけるファイルの管理、およ
び、制御方法に、重要なファイルのみを任意の多重度で
多重化して管理する方法がある。
び、制御方法に、重要なファイルのみを任意の多重度で
多重化して管理する方法がある。
そして、このような多重化されたファイルの信頼性に係
るものとして、多重化されたファイルからの出力データ
を、それを使用するコンピュータで一定期間の間収集し
、収集したデータ間の整合性をチェックするものがある
。
るものとして、多重化されたファイルからの出力データ
を、それを使用するコンピュータで一定期間の間収集し
、収集したデータ間の整合性をチェックするものがある
。
しかし、このような従来の分散処理システムにおける多
重ファイルの制御方法では、内容の不一致状態が発生し
た場合の回復の方法に関しての配慮がなされておらず、
不一致状態の発生時には、そのファイルをアクセスして
いた処理が停止するという問題があった。
重ファイルの制御方法では、内容の不一致状態が発生し
た場合の回復の方法に関しての配慮がなされておらず、
不一致状態の発生時には、そのファイルをアクセスして
いた処理が停止するという問題があった。
また、多重化されたファイルからの出力データの整合性
のチェックを、一定期間の間収集してから行なうために
、その間、処理が遅れるなどの問題があった。
のチェックを、一定期間の間収集してから行なうために
、その間、処理が遅れるなどの問題があった。
本発明の目的は、これら従来技術の課題を解決し、任意
の多重度に多重化された多重ファイルに対し、多重ファ
イル間に不整合が発生した場合でも、ファイルアクセス
している処理を中断することなく、不整合状態を自動的
に回復し、かつ、多重ファイル間に発生する不整合状態
の検出処理を、ファイルアクセス応答性能を低下させる
ことなく行ない、分散処理システムの処理性能と信頼性
を向上させる分散処理システムの多重データ処理方法を
提供することである。
の多重度に多重化された多重ファイルに対し、多重ファ
イル間に不整合が発生した場合でも、ファイルアクセス
している処理を中断することなく、不整合状態を自動的
に回復し、かつ、多重ファイル間に発生する不整合状態
の検出処理を、ファイルアクセス応答性能を低下させる
ことなく行ない、分散処理システムの処理性能と信頼性
を向上させる分散処理システムの多重データ処理方法を
提供することである。
上記目的を達成するため、本発明の分散処理システムの
多重データ処理方法は、(1)複数のプロセッサを共通
伝送媒体を介して接続し、複数のプロセッサは、それぞ
れのプロセッサに多重に配置したリソースから発生する
多重データを用いて処理を進める分散処理システムの多
重データ処理方法において、複数のプロセッサは、多重
データの最初に受信したデータを用いて処理を進め、以
後受信した多重データを用いて、最初に受信したデータ
の整合性のチェックを行なうことを特徴とすまた、(2
)上記(1)に記載の分散処理システムの多重データ処
理方法において、複数のプロセッサのそれぞれに接続し
た外部記憶媒体のそれぞれにファイルを多重に配置し、
複数のプロセッサの任意のプロセッサは、多重に配置し
たファイルに対するアクセス依頼を発生し、かつ、アク
セス依頼に対応する多重に配置したファイルからの多重
応答データを受信し、そして、多重応答データの最初に
受信した応答データを用いて処理を進め、以後受信した
多重応答データを用いて、最初に受信した応答データの
整合性のチェックを行なうことを特徴とする。
多重データ処理方法は、(1)複数のプロセッサを共通
伝送媒体を介して接続し、複数のプロセッサは、それぞ
れのプロセッサに多重に配置したリソースから発生する
多重データを用いて処理を進める分散処理システムの多
重データ処理方法において、複数のプロセッサは、多重
データの最初に受信したデータを用いて処理を進め、以
後受信した多重データを用いて、最初に受信したデータ
の整合性のチェックを行なうことを特徴とすまた、(2
)上記(1)に記載の分散処理システムの多重データ処
理方法において、複数のプロセッサのそれぞれに接続し
た外部記憶媒体のそれぞれにファイルを多重に配置し、
複数のプロセッサの任意のプロセッサは、多重に配置し
たファイルに対するアクセス依頼を発生し、かつ、アク
セス依頼に対応する多重に配置したファイルからの多重
応答データを受信し、そして、多重応答データの最初に
受信した応答データを用いて処理を進め、以後受信した
多重応答データを用いて、最初に受信した応答データの
整合性のチェックを行なうことを特徴とする。
また、(3)上記(2)に記載の分散処理システムの多
重データ処理方法において、アクセス依頼を発生したプ
ロセッサは、多重応答データ間のチェックが終了するま
で、次のファイルアクセス依頼を発生しないことを特徴
とする。
重データ処理方法において、アクセス依頼を発生したプ
ロセッサは、多重応答データ間のチェックが終了するま
で、次のファイルアクセス依頼を発生しないことを特徴
とする。
また、(4)上記(3)に記載の分散処理システムの多
重データ処理方法において、応答データの整合性のチェ
ックで応答データ間に不整合を検出した場合は、アクセ
ス依頼を発生したプロセッサは、アクセス依頼により生
じたファイル状態を解除する命令を発行する第1のリト
ライ処理を行ない、第1のリトライ処理によるファイル
状態の解除後、再び、アクセス依頼を発生する第2のリ
トライ処理を行ない、応答データ間の不整合がなくなる
まで、第1のリトライ処理、および、第2のリトライ処
理を繰り返すことを特徴とする。
重データ処理方法において、応答データの整合性のチェ
ックで応答データ間に不整合を検出した場合は、アクセ
ス依頼を発生したプロセッサは、アクセス依頼により生
じたファイル状態を解除する命令を発行する第1のリト
ライ処理を行ない、第1のリトライ処理によるファイル
状態の解除後、再び、アクセス依頼を発生する第2のリ
トライ処理を行ない、応答データ間の不整合がなくなる
まで、第1のリトライ処理、および、第2のリトライ処
理を繰り返すことを特徴とする。
また、(5)上記(4)に記載の分散処理システムの多
重データ処理方法において、アクセス依頼を発生したプ
ロセッサは、第1のリトライ処理、および、第2のリト
ライ処理を、応答データ間の不整合がなくなるまで繰り
返す代わりに、第2のリトライ処理を、予め設定された
任意の時間ずらして実行することを特徴とする。
重データ処理方法において、アクセス依頼を発生したプ
ロセッサは、第1のリトライ処理、および、第2のリト
ライ処理を、応答データ間の不整合がなくなるまで繰り
返す代わりに、第2のリトライ処理を、予め設定された
任意の時間ずらして実行することを特徴とする。
また、(6)上記(4)、もしくは、(5)のいずれか
に記載の分散処理システムの多重データ処理方法におい
て、アクセス依頼を発生したプロセッサは、最初に受信
した応答データを用いた処理を行なわず、多重ファイル
からの全応答データを収集し、収集した全応答データ間
の整合性のチェック、および、第1のリトライ処理と第
2のリトライ処理による応答データ間の整合性の確定後
に、処理を行なうことを特徴とする。
に記載の分散処理システムの多重データ処理方法におい
て、アクセス依頼を発生したプロセッサは、最初に受信
した応答データを用いた処理を行なわず、多重ファイル
からの全応答データを収集し、収集した全応答データ間
の整合性のチェック、および、第1のリトライ処理と第
2のリトライ処理による応答データ間の整合性の確定後
に、処理を行なうことを特徴とする。
また、(7)上記(4)〜(6)のいずれか一つに記載
の分散処理システムの多重データ処理方法において、ア
クセス依頼を発生したプロセッサは、予め任意に設定し
た時間内に収集した多重ファイルからの全応答データ間
の整合性のチェックに基づき、第1のリトライ処理、お
よび、第2のリトライ処理を行なうことを特徴とする。
の分散処理システムの多重データ処理方法において、ア
クセス依頼を発生したプロセッサは、予め任意に設定し
た時間内に収集した多重ファイルからの全応答データ間
の整合性のチェックに基づき、第1のリトライ処理、お
よび、第2のリトライ処理を行なうことを特徴とする。
また、(8)上記(7)に記載の分散処理システムの多
重データ処理方法において、アクセス依頼を発生したプ
ロセッサは、予め任意に設定した時間内に、多重ファイ
ルからの全応答データを収集できない場合、予め任意に
設定した時間内に収集した応答データを、整合性のチェ
ックの対象に限定する障害処理を行ない、障害処理の後
に、整合性のチェック、および、第1のリトライ処理と
第2のリトライ処理を行なうことを特徴とする。
重データ処理方法において、アクセス依頼を発生したプ
ロセッサは、予め任意に設定した時間内に、多重ファイ
ルからの全応答データを収集できない場合、予め任意に
設定した時間内に収集した応答データを、整合性のチェ
ックの対象に限定する障害処理を行ない、障害処理の後
に、整合性のチェック、および、第1のリトライ処理と
第2のリトライ処理を行なうことを特徴とする。
また、(9)上記(4)に記載の分散処理システムの多
重データ処理方法において、アクセス依頼を発生したプ
ロセッサは、第1のリトライ処理として、アクセス依頼
がファイル更新時のリードコマンドの場合は、リードコ
マンドの排他管理によるレコードの占有状態を解除する
フリーコマンドを、アクセス依頼が追加コマンドの場合
は、追加コマンドにより追加したレコードを削除するイ
レースコマンドを、アクセス依頼が排他オープンコマン
ドの場合は、排他オープンコマンドによるファイルの占
有状態を解除するクローズコマンドを発行することを特
徴とする。
重データ処理方法において、アクセス依頼を発生したプ
ロセッサは、第1のリトライ処理として、アクセス依頼
がファイル更新時のリードコマンドの場合は、リードコ
マンドの排他管理によるレコードの占有状態を解除する
フリーコマンドを、アクセス依頼が追加コマンドの場合
は、追加コマンドにより追加したレコードを削除するイ
レースコマンドを、アクセス依頼が排他オープンコマン
ドの場合は、排他オープンコマンドによるファイルの占
有状態を解除するクローズコマンドを発行することを特
徴とする。
そして、(10)上記(4)〜(6)のそれぞれに記載
の分散処理システムの多重データ処理方法において、複
数のプロセッサは、アクセス依頼メツセージ、および、
アクセス応答メツセージのメツセージを伝送媒体へブロ
ードキャストし、メツセージのやり取りにより分散処理
を行ない、複数のプロセッサのそれぞれは、自プロセッ
サから他プロセッサへのメツセージの伝送媒体へのブロ
ードキャスト、および、伝送媒体へブロードキャストさ
れたメツセージから、自プロセッサに関連するメツセー
ジの取り込みを行なう通信管理モジュールと、通信管理
モジュールで取り込んだメツセージを、メツセージを処
理するユーザプログラムに渡し、かつ、ユーザプログラ
ムからのファイルアクセス命令に基づき、アクセス依頼
メツセージを生成し、通信管理モジュールに送出するク
ライアントファイル管理モジュールと、クライアントフ
ァイル管理モジュールが通信管理モジュールに送出した
メツセージ情報を格納する送信情報格納手段とを有し、
アクセス依頼を発生したプロセッサは、クライアントフ
ァイル管理モジュールを用いて、通信管理モジュールを
介して伝送媒体にメツセージを送出すると同時に、整合
性のチェックに用いる予め任意に設定した収集時間を送
信情報格納手段に格納し、そして、送信情報格納手段に
格納した時間に基づき、多重ファイルからの全応答デー
タ間の整合性のチェック、および、第1のリトライ処理
と第2のリトライ処理を行なうことを特徴とする。
の分散処理システムの多重データ処理方法において、複
数のプロセッサは、アクセス依頼メツセージ、および、
アクセス応答メツセージのメツセージを伝送媒体へブロ
ードキャストし、メツセージのやり取りにより分散処理
を行ない、複数のプロセッサのそれぞれは、自プロセッ
サから他プロセッサへのメツセージの伝送媒体へのブロ
ードキャスト、および、伝送媒体へブロードキャストさ
れたメツセージから、自プロセッサに関連するメツセー
ジの取り込みを行なう通信管理モジュールと、通信管理
モジュールで取り込んだメツセージを、メツセージを処
理するユーザプログラムに渡し、かつ、ユーザプログラ
ムからのファイルアクセス命令に基づき、アクセス依頼
メツセージを生成し、通信管理モジュールに送出するク
ライアントファイル管理モジュールと、クライアントフ
ァイル管理モジュールが通信管理モジュールに送出した
メツセージ情報を格納する送信情報格納手段とを有し、
アクセス依頼を発生したプロセッサは、クライアントフ
ァイル管理モジュールを用いて、通信管理モジュールを
介して伝送媒体にメツセージを送出すると同時に、整合
性のチェックに用いる予め任意に設定した収集時間を送
信情報格納手段に格納し、そして、送信情報格納手段に
格納した時間に基づき、多重ファイルからの全応答デー
タ間の整合性のチェック、および、第1のリトライ処理
と第2のリトライ処理を行なうことを特徴とする。
本発明においては、各プロセッサは、自ら発行したアク
セス命令に基づき送られてきた多重ファイルからの複数
の応答データを受は取る。この時、多重ファイルから最
初に受信した応答データを、受信したタイミングでユー
ザプログラムに渡すと共に、自プロセッサ内に格納して
おく。
セス命令に基づき送られてきた多重ファイルからの複数
の応答データを受は取る。この時、多重ファイルから最
初に受信した応答データを、受信したタイミングでユー
ザプログラムに渡すと共に、自プロセッサ内に格納して
おく。
そして、以後に受信した応答データと、この最初に受信
した応答データとを比較し、応答データ間(すなわち、
多重ファイル間)の不整合の発生をチェックする。
した応答データとを比較し、応答データ間(すなわち、
多重ファイル間)の不整合の発生をチェックする。
ここで、応答データ間での不一致を検出した場合、アク
セス命令を発行した自プロセッサは、まず、多重ファイ
ルに対して発行したアクセス命令を解除する命令を発行
し、自プロセッサのアクセス命令により引き起こされた
ファイル状態を解除する(第1のリトライ処理)。そし
て、次に、再び、同じアクセス命令を発行する(第2の
リトライ処理)。
セス命令を発行した自プロセッサは、まず、多重ファイ
ルに対して発行したアクセス命令を解除する命令を発行
し、自プロセッサのアクセス命令により引き起こされた
ファイル状態を解除する(第1のリトライ処理)。そし
て、次に、再び、同じアクセス命令を発行する(第2の
リトライ処理)。
ここで、多重ファイル間の不整合状態は、複数のプロセ
ッサが、同時に、多重ファイルにアクセスした場合に発
生するものである。そして、アクセス命令の再発行は、
各プロセッサが、独自のタイミングで行なう。そのため
に、お互いのアクセス命令再発行のタイミングは自動的
にずれる。このことにより、再発行のアクセス命令に関
しては、不整合状態の発生は自動的に回避される。
ッサが、同時に、多重ファイルにアクセスした場合に発
生するものである。そして、アクセス命令の再発行は、
各プロセッサが、独自のタイミングで行なう。そのため
に、お互いのアクセス命令再発行のタイミングは自動的
にずれる。このことにより、再発行のアクセス命令に関
しては、不整合状態の発生は自動的に回避される。
このことにより、任意の多重度に多重化されたファイル
に対し、多重ファイル間に不整合が発生した場合でも、
ファイルアクセスしている処理を中断することなく、不
整合状態を自動的に回復する。
に対し、多重ファイル間に不整合が発生した場合でも、
ファイルアクセスしている処理を中断することなく、不
整合状態を自動的に回復する。
また、一番最初に多重ファイルからの応答を受信したタ
イミングで、ユーザプログラムに制御が戻るため、ファ
イル間整合性チェックのために、ファイルアクセス応゛
答が低下することはない。
イミングで、ユーザプログラムに制御が戻るため、ファ
イル間整合性チェックのために、ファイルアクセス応゛
答が低下することはない。
以下、本発明の実施例を、図面により詳細に説明する。
第1図は、本発明を施した分散処理システムの本発明に
係る構成の第1の実施例を示すブロック図である。
係る構成の第1の実施例を示すブロック図である。
分散処理システムは、バス型ネットワークのネットワー
ク4に、それぞれ処理を分担して実行するプロセッサ1
〜3、プロセッサ1〜3のそれぞれに接続され、処理操
作指示の入力機能および処理結果の表示機能を有するタ
ーミナル1O120,30、同じく、プロセッサ1〜3
のそれぞれに接続され、処理の対象となるデータを格納
するディスク11.21.31から構成されている。
ク4に、それぞれ処理を分担して実行するプロセッサ1
〜3、プロセッサ1〜3のそれぞれに接続され、処理操
作指示の入力機能および処理結果の表示機能を有するタ
ーミナル1O120,30、同じく、プロセッサ1〜3
のそれぞれに接続され、処理の対象となるデータを格納
するディスク11.21.31から構成されている。
さらに、プロセッサ1のディスク11と、プロセッサ2
のディスク21内には、ファイル(A)12.22を多
重に持たせている。
のディスク21内には、ファイル(A)12.22を多
重に持たせている。
また、プロセッサ1にはユーザプログラム13(以下U
Pa“13と記載)が、また、プロセッサ2にはユーザ
プログラム23(以下UPb23と記載)が存在する。
Pa“13と記載)が、また、プロセッサ2にはユーザ
プログラム23(以下UPb23と記載)が存在する。
そして、本発明に係る処理を行なうプロセッサ1〜3の
それぞれは、ネットワーク4上に送出したメツセージ5
の授受により分散処理を行なう。
それぞれは、ネットワーク4上に送出したメツセージ5
の授受により分散処理を行なう。
ここで、メツセージ5の構成に関しての説明を行なう。
メツセージ5の初めと終わりを、それぞれ示すフラグ5
1.58(図中Fと記載)、メツセージの内容を示す内
容コード52(図中CCと記載)、本メツセージを発生
したプロセッサのプロセッサ番号を格納する発生源アド
レス53(図中SAと記載)、ネットワーク4による伝
送で必要となる通番54(図中Cと記載)、ファイルを
アクセスするユーザプログラム(例えば、UPa13)
を示す発生源情報55(図中SIと記載)、伝送される
べき情報を格納するエリアであるデータ部56(図中D
ataと記載)、伝送上の誤りをチェックするための
エリアであるF CS (Frame Check
5equencer) 57から構成されている。
1.58(図中Fと記載)、メツセージの内容を示す内
容コード52(図中CCと記載)、本メツセージを発生
したプロセッサのプロセッサ番号を格納する発生源アド
レス53(図中SAと記載)、ネットワーク4による伝
送で必要となる通番54(図中Cと記載)、ファイルを
アクセスするユーザプログラム(例えば、UPa13)
を示す発生源情報55(図中SIと記載)、伝送される
べき情報を格納するエリアであるデータ部56(図中D
ataと記載)、伝送上の誤りをチェックするための
エリアであるF CS (Frame Check
5equencer) 57から構成されている。
また、内容コード52は、アクセスするファイルを示す
ファイルネーム部521 (図中FNMと記載)、ファ
イルアクセス依頼やファイルアクセス応答などのメツセ
ージの種別を示すID(IDentifier)部52
2からなる。
ファイルネーム部521 (図中FNMと記載)、ファ
イルアクセス依頼やファイルアクセス応答などのメツセ
ージの種別を示すID(IDentifier)部52
2からなる。
重篤1の実施例では、ファイル名称は、システム内でユ
ニーク(唯一)であるという前提のもとに、ファイルネ
ーム部521の内容としてファイル名称を用いる。但し
、ファイルネーム部521は、ファイル名称の代わりに
、ファイル内容に対応するコード等を用いても構わない
。
ニーク(唯一)であるという前提のもとに、ファイルネ
ーム部521の内容としてファイル名称を用いる。但し
、ファイルネーム部521は、ファイル名称の代わりに
、ファイル内容に対応するコード等を用いても構わない
。
また、発生源情報55は、ユーザプログラムを実行中の
プロセッサのプロセッサ番号を格納するエリアであるプ
ロセッサ番号情報部551(図中PNO551と記載)
、実行中プログラムを示す情報を格納するエリアである
タスク番号情報部552(図中TNOと記載)、そして
、ユーザプログラムが発生するメツセージの順番を示す
通番エリアである通番情報部553(図中SEQと記載
)からなる。
プロセッサのプロセッサ番号を格納するエリアであるプ
ロセッサ番号情報部551(図中PNO551と記載)
、実行中プログラムを示す情報を格納するエリアである
タスク番号情報部552(図中TNOと記載)、そして
、ユーザプログラムが発生するメツセージの順番を示す
通番エリアである通番情報部553(図中SEQと記載
)からなる。
このようなフォーマットのメツセージ5を、重篤1の実
施例において、各プロセッサ1〜3は、ネットワーク4
上にブロードキャストする。また、各プロセッサ1〜3
は、ネットワーク上のメツセージ5の内容コード52の
内容に基づき、そのメツセージ5が自らに必要か否かを
判定し、必要なメツセージ5のみを取1ノ込む。
施例において、各プロセッサ1〜3は、ネットワーク4
上にブロードキャストする。また、各プロセッサ1〜3
は、ネットワーク上のメツセージ5の内容コード52の
内容に基づき、そのメツセージ5が自らに必要か否かを
判定し、必要なメツセージ5のみを取1ノ込む。
次に、各プロセッサ1〜3の構成、および、その機能を
、プロセッサ1を用いて説明する。
、プロセッサ1を用いて説明する。
ネットワークインタフェースl○1は、ネットワーク4
とのインタフェースを取るためのモジュールで、ディス
クインタフェース111は、ディスク11とのインタフ
ェースを取るためのモジュールである。
とのインタフェースを取るためのモジュールで、ディス
クインタフェース111は、ディスク11とのインタフ
ェースを取るためのモジュールである。
通信管理モジュール102は、ネットワーク4より受信
したメツセージ5の内容(内容コード52)に基づき、
受信メツセージが自プロセッサに必要なものであるか否
かを判定し、必要なメツセージの場合は、それを入力メ
ツセージエリア104に格納する。また、出力メツセー
ジエリア105内のメツセージをメツセージ5として、
ネットワークインタフェースlot経由で、ネットワー
ク4にブロードキャストする。
したメツセージ5の内容(内容コード52)に基づき、
受信メツセージが自プロセッサに必要なものであるか否
かを判定し、必要なメツセージの場合は、それを入力メ
ツセージエリア104に格納する。また、出力メツセー
ジエリア105内のメツセージをメツセージ5として、
ネットワークインタフェースlot経由で、ネットワー
ク4にブロードキャストする。
尚、この際、通信管理モジュール102は、送出メツセ
ージに対しても、ネットワーク4からの受信メツセージ
と同じように、その送出メツセージが、自プロセッサに
必要であるか否かを判定し、必要な場合は、入力メツセ
ージエリア104に、その送出メツセージを格納する。
ージに対しても、ネットワーク4からの受信メツセージ
と同じように、その送出メツセージが、自プロセッサに
必要であるか否かを判定し、必要な場合は、入力メツセ
ージエリア104に、その送出メツセージを格納する。
また、入力メツセージエリア104、出力メツセージエ
リア105には、それぞれ、受信メツセージと送信メツ
セージが、内容コーh”52対応に格納されている。
リア105には、それぞれ、受信メツセージと送信メツ
セージが、内容コーh”52対応に格納されている。
内容コードテーブル103には、自プロセッサで必要と
するメツセージ5の内容コードが登録される。具体的に
は、メツセージSのファイルネーム部521には、自デ
ィスク11内ファイルの「ファイル名称」が、また、I
D部522には、「アクセス依頼」を示すコードが設定
された内容コードが、例えば、プロセッサ立ち上げ時に
登録される。また、ユーザプログラムの実行状況に応じ
て、ID部522にアクセス応答を示すコードが設定さ
れた内容コードも登録される。
するメツセージ5の内容コードが登録される。具体的に
は、メツセージSのファイルネーム部521には、自デ
ィスク11内ファイルの「ファイル名称」が、また、I
D部522には、「アクセス依頼」を示すコードが設定
された内容コードが、例えば、プロセッサ立ち上げ時に
登録される。また、ユーザプログラムの実行状況に応じ
て、ID部522にアクセス応答を示すコードが設定さ
れた内容コードも登録される。
通信管理モジュール102は、受信したメツセージ5内
の内容コード52と、内容コードテーブル103に登録
されている内容コードとを比較し、一致するメツセージ
5を取り込む。
の内容コード52と、内容コードテーブル103に登録
されている内容コードとを比較し、一致するメツセージ
5を取り込む。
クライアントファイル管理モジュール106は、入力メ
ツセージエリア104内のメツセージをUPa13に渡
すと共に、UPa13からの送出メツセージを、出力メ
ツセージエリア105に格納する処理を行なう。
ツセージエリア104内のメツセージをUPa13に渡
すと共に、UPa13からの送出メツセージを、出力メ
ツセージエリア105に格納する処理を行なう。
送信S I (Source I nfor+*at
ion、発生源情報)テーブル107は、クライアント
ファイル管理モジュール106が、出力メツセージエリ
ア105に格納するメツセージ5の発生源情報55の内
容を、内容コード52対応に格納しておくテーブルであ
る。
ion、発生源情報)テーブル107は、クライアント
ファイル管理モジュール106が、出力メツセージエリ
ア105に格納するメツセージ5の発生源情報55の内
容を、内容コード52対応に格納しておくテーブルであ
る。
ユーザプログラム実行エリア(図中LIP実行エリアと
記載)108は、UPa13などのユーザプログラムを
実行するエリアである。
記載)108は、UPa13などのユーザプログラムを
実行するエリアである。
ファイル管理テーブル110、および、サーバファイル
管理モジュール109は、自プロセッサ1に接続された
ディスクll内のファイル(A)12のアクセスを管理
するためのものである。
管理モジュール109は、自プロセッサ1に接続された
ディスクll内のファイル(A)12のアクセスを管理
するためのものである。
次に、送信SI子テーブル07、および、ファイル管理
テーブル110のフォーマットに関して説明する。
テーブル110のフォーマットに関して説明する。
送信SI子テーブル07は、ファイルアクセス依頼を示
すメツセージ5の発生源情報55に対応した行1071
〜1o72を有する。そして、これら各行1071〜1
o72のそれぞれにおいては、アクセス依頼メツセージ
の発生源情報55の内容を格納する発生源情報エリア(
図中SIエリアと記載)10711に、アクセス依頼に
対する応答のタイムアウトを検出するための身イマエリ
ア10712と、アクセス依頼に対するアクセス応答を
示すメツセージの個数を格納するための個数エリア10
713と、受信したアクセス応答メツセージを格納する
ための受信メツセージエリア10714とが対応付けら
れている。
すメツセージ5の発生源情報55に対応した行1071
〜1o72を有する。そして、これら各行1071〜1
o72のそれぞれにおいては、アクセス依頼メツセージ
の発生源情報55の内容を格納する発生源情報エリア(
図中SIエリアと記載)10711に、アクセス依頼に
対する応答のタイムアウトを検出するための身イマエリ
ア10712と、アクセス依頼に対するアクセス応答を
示すメツセージの個数を格納するための個数エリア10
713と、受信したアクセス応答メツセージを格納する
ための受信メツセージエリア10714とが対応付けら
れている。
ファイル管理テーブル110は、自ディスク11内のフ
ァイルに対応する行1 lot〜1102を有する。そ
して、各行1101〜1102には、各ファイルに対応
するコード(木簡1の実施例ではファイル名称)を格納
するファイルネームエリア(図中FNMエリアと記載)
11011、そのファイルが格納されているディスク、
および、ディスク内での位置を示す情報を格納する物理
情報エリア11012、および、そのファイルに対する
アクセス依頼メツセージの発生源情報(メツセージ5に
おける発生源情報55)の内容を格納するための発生源
情報エリア(図中SIエリアと記載)11013よりな
る。
ァイルに対応する行1 lot〜1102を有する。そ
して、各行1101〜1102には、各ファイルに対応
するコード(木簡1の実施例ではファイル名称)を格納
するファイルネームエリア(図中FNMエリアと記載)
11011、そのファイルが格納されているディスク、
および、ディスク内での位置を示す情報を格納する物理
情報エリア11012、および、そのファイルに対する
アクセス依頼メツセージの発生源情報(メツセージ5に
おける発生源情報55)の内容を格納するための発生源
情報エリア(図中SIエリアと記載)11013よりな
る。
このうち、ファイルネームエリア11011と、物理情
報エリア11012は、ファイルアロケート時に、前も
って設定されているものとする。
報エリア11012は、ファイルアロケート時に、前も
って設定されているものとする。
以下、このような構成からなる木簡1の実施例の分散処
理システムにおいて、各プロセッサ1〜3間で行なわれ
るメツセージ5の送受信の基本的な動作を説明する。
理システムにおいて、各プロセッサ1〜3間で行なわれ
るメツセージ5の送受信の基本的な動作を説明する。
まず、メツセージ5の送信動作を、UPa13がファイ
ルアクセス命令を発行した時のクライアントファイル管
理モジュール106の処理動作に基づき説明する。
ルアクセス命令を発行した時のクライアントファイル管
理モジュール106の処理動作に基づき説明する。
UPa13は、アクセスするファイル名称、および、ア
クセス内容を指定してファイルアクセス命令を発行する
。
クセス内容を指定してファイルアクセス命令を発行する
。
このアクセス命令は、クライアントファイル管理モジュ
ール106が取り込み、メツセージ5のフォーマットで
示した内容コード52、発生源情報55、データ部56
を以下のように設定したメツセージを作成し、出力メツ
セージエリア105に格納する。
ール106が取り込み、メツセージ5のフォーマットで
示した内容コード52、発生源情報55、データ部56
を以下のように設定したメツセージを作成し、出力メツ
セージエリア105に格納する。
すなわち、内容コード52のファイルネーム部521に
はUPa13で指定されたファイル名称が、そして、I
D部522にはアクセス依頼を示すコードが設定されて
いる。
はUPa13で指定されたファイル名称が、そして、I
D部522にはアクセス依頼を示すコードが設定されて
いる。
発生源情報55のプロセッサ番号部551には自プロセ
ッサ番号が、また、タスク番号552にはファイルアク
セス命令を発行したUPa 13に割り当てられている
番号、例えば、タスク番号などが、そして、メツセージ
順番部553にはアクセス命令の発行された順番を示す
通番が設定されている。さらに、データ部56には%U
Pa l 3が指定したアクセス内容が設定されている
。
ッサ番号が、また、タスク番号552にはファイルアク
セス命令を発行したUPa 13に割り当てられている
番号、例えば、タスク番号などが、そして、メツセージ
順番部553にはアクセス命令の発行された順番を示す
通番が設定されている。さらに、データ部56には%U
Pa l 3が指定したアクセス内容が設定されている
。
また、この際、設定した発生源情報55の内容を、送信
SI子テーブル07の発生源情報エリア10711に設
定し、さらに、対応するタイマエリア10712にタイ
マを設定する。
SI子テーブル07の発生源情報エリア10711に設
定し、さらに、対応するタイマエリア10712にタイ
マを設定する。
以上の処理により、出力メツセージエリア105に格納
されたメツセージは、通信管理モジュール102により
、ネットワーク4に、メツセージ5としてブロードキャ
ストされる。
されたメツセージは、通信管理モジュール102により
、ネットワーク4に、メツセージ5としてブロードキャ
ストされる。
このようなメツセージを、アクセス依頼メツセージと呼
ぶ。
ぶ。
次に、メツセージの受信動作を、サーバファイル管理モ
ジュール109の処理動作に基づき説明する。
ジュール109の処理動作に基づき説明する。
例えば、プロセッサ2のクライアントファイル管理モジ
ュールが、UPb23の要求に基づいて、アクセス依頼
メツセージを、プロセッサ2の通信管理モジュール経由
でネットワーク4に、メツセージ5で示したフォーマッ
トでブロードキャストする。
ュールが、UPb23の要求に基づいて、アクセス依頼
メツセージを、プロセッサ2の通信管理モジュール経由
でネットワーク4に、メツセージ5で示したフォーマッ
トでブロードキャストする。
そのアクセス依頼メツセージは、そのメツセージ5内の
内容コード52に指定されたファイル、例えば、ファイ
ル(A)12を自ディスク内に持つプロセッサ、ここで
は、プロセッサlにより取り込まれる。そして、プロセ
ッサ1内の通信管理モジュール102は、このファイル
(A)12へのアクセス依頼メツセージを、入力メツセ
ージエリア104に格納する。
内容コード52に指定されたファイル、例えば、ファイ
ル(A)12を自ディスク内に持つプロセッサ、ここで
は、プロセッサlにより取り込まれる。そして、プロセ
ッサ1内の通信管理モジュール102は、このファイル
(A)12へのアクセス依頼メツセージを、入力メツセ
ージエリア104に格納する。
サーバファイル管理モジュール109は、入力メツセー
ジエリア104より、このメツセージを取り込み、取り
込んだメツセージ内の発生源情報55の内容を、ファイ
ル管理テーブル110の発生源情報エリア11013に
格納する。
ジエリア104より、このメツセージを取り込み、取り
込んだメツセージ内の発生源情報55の内容を、ファイ
ル管理テーブル110の発生源情報エリア11013に
格納する。
そして、サーバファイル管理モジュール109は、メツ
セージ5内のデータ部56で指定されるファイルアクセ
ス処理を、ファイル管理テーブル110内の物理情報エ
リア11012の内容に基づき実行する。
セージ5内のデータ部56で指定されるファイルアクセ
ス処理を、ファイル管理テーブル110内の物理情報エ
リア11012の内容に基づき実行する。
さらに、サーバファイル管理モジュールl○9は、この
ファイルアクセス処理の結果に基づき、メツセージの内
容コード52、発生源情報55、データ部56を以下の
様に設定したアクセス応答を示すメツセージを作成し、
出力メツセージエリア105に格納する。尚、このメツ
セージをアクセス応答メツセージと呼ぶ。
ファイルアクセス処理の結果に基づき、メツセージの内
容コード52、発生源情報55、データ部56を以下の
様に設定したアクセス応答を示すメツセージを作成し、
出力メツセージエリア105に格納する。尚、このメツ
セージをアクセス応答メツセージと呼ぶ。
アクセス応答メツセージにおいては、ファイルネーム部
521にはアクセスしたファイルの名称が、ID部52
2にはアクセス応答を示すコードが設定されている。ま
た、発生源情報55には、アクセス依頼メツセージ内の
発生源情報の値(ファイル管理テーブル発生源情報エリ
ア110 ’l 3の内容)が設定される。そして、デ
ータ部56にはファイルアクセスの結果内容が設定され
ている。
521にはアクセスしたファイルの名称が、ID部52
2にはアクセス応答を示すコードが設定されている。ま
た、発生源情報55には、アクセス依頼メツセージ内の
発生源情報の値(ファイル管理テーブル発生源情報エリ
ア110 ’l 3の内容)が設定される。そして、デ
ータ部56にはファイルアクセスの結果内容が設定され
ている。
ここで、ファイルアクセスの結果内容とは、アクセスが
正常終了したか否か、および、異常終了した場合には、
異常の内容を示す情報のことである。
正常終了したか否か、および、異常終了した場合には、
異常の内容を示す情報のことである。
以後、この情報をステータス情報と呼ぶ。また、リード
(READ、読み取り)コマンドの場合は、リードした
内容も含む。
(READ、読み取り)コマンドの場合は、リードした
内容も含む。
以上の処理により出力メツセージエリア105に格納さ
れたファイルアクセス応答メツセージは、通信管理モジ
ュール102により、ネットワーク4に、メツセージ5
としてブロードキャストされる。
れたファイルアクセス応答メツセージは、通信管理モジ
ュール102により、ネットワーク4に、メツセージ5
としてブロードキャストされる。
そして、このアクセス応答メツセージは、アクセス依頼
を発生したユーザプログラム、すなわち、UPb23を
実行中のプロセッサ2により取り込まれる。
を発生したユーザプログラム、すなわち、UPb23を
実行中のプロセッサ2により取り込まれる。
このようにして、水弟1の実施例の分散処理システムは
、各プロセッサ1〜3間でメツセージ5の授受を行ない
、分散処理を進めて行く。
、各プロセッサ1〜3間でメツセージ5の授受を行ない
、分散処理を進めて行く。
以上のような構成からなる第1の実施例の分散処理シス
テムにおいては、以下に示す問題に対処して、本発明に
係る処理動作を行なう。
テムにおいては、以下に示す問題に対処して、本発明に
係る処理動作を行なう。
まず、その問題点を説明する。
例えば、二つのUPa13、Upb23が、同時に、多
重化されたファイル(A)12.22をアクセスする場
合を想定する。
重化されたファイル(A)12.22をアクセスする場
合を想定する。
UPa 13が、ファイルアクセスコマンドを発行し、
アクセス依頼すると、このファイルアクセスコマンドは
、自プロセッサ1のディスクll内のファイル(A)1
2と、プロセッサ2のディスク21内のファイル(A)
22に送られる。
アクセス依頼すると、このファイルアクセスコマンドは
、自プロセッサ1のディスクll内のファイル(A)1
2と、プロセッサ2のディスク21内のファイル(A)
22に送られる。
この場合、ネットワーク4を介さないで済む自プロセッ
サ1内のファイル(A)12の方が先に処理される。そ
して、ファイル(A)12のファイルアクセスコマンド
に対する処理結果が、UPa13に送られ、アクセス応
答がなされる。
サ1内のファイル(A)12の方が先に処理される。そ
して、ファイル(A)12のファイルアクセスコマンド
に対する処理結果が、UPa13に送られ、アクセス応
答がなされる。
一方、UPa13がファイルアクセスコマンドを発行し
たのと同時に、UPb23が、UPa13と同一レコー
ドに対するファイルアクセスコマンドを発行したものと
する。
たのと同時に、UPb23が、UPa13と同一レコー
ドに対するファイルアクセスコマンドを発行したものと
する。
すると、UPb23のファイルアクセスコマンドも、U
Pa13のファイルアクセスコマンドと同様に、自プロ
セッサ2のディスク21内のファイル(A)22と、プ
ロセッサ1のディスク11内のファイル(A)12に送
られる。
Pa13のファイルアクセスコマンドと同様に、自プロ
セッサ2のディスク21内のファイル(A)22と、プ
ロセッサ1のディスク11内のファイル(A)12に送
られる。
この場合は、自プロセッサ2内のファイル(A)22の
方が先に処理される。
方が先に処理される。
そして、ファイル(A)22に対するファイルアクセス
コマンドの処理結果が、UPb23に送られる。
コマンドの処理結果が、UPb23に送られる。
すなわち、ファイル(A)12に対しては、UPa13
がアクセスし、ファイル(A)22に対しては、UPb
23がアクセスしている状態が発生する。
がアクセスし、ファイル(A)22に対しては、UPb
23がアクセスしている状態が発生する。
この状態で、ファイル(A)12には、UPb23のア
クセスコマンドが、また、ファイル(A)22には、T
JPa13のアクセスコマンドが到達する。この場合、
アクセスコマンドの内容によっては、ハード的には全く
障害がなくても、例えば、以下に示すような状態が発生
する。
クセスコマンドが、また、ファイル(A)22には、T
JPa13のアクセスコマンドが到達する。この場合、
アクセスコマンドの内容によっては、ハード的には全く
障害がなくても、例えば、以下に示すような状態が発生
する。
(1)アクセスコマンドがファイル更新のためのリード
(RE A D)コマンドの場合:ファイル更新の場合
は、ファイルアクセス排他管理を行なうため、リード(
READ、読み取り)受は付は時から、ライト(WRI
TE、書き込み)処理完了時まで、ファイル内の対象と
なるレコードへの他ユーザプログラムからのアクセスを
禁止する。そのために、UPa13がリード(READ
)状態のファイル(A)12のレコードに対する、UP
b23のアクセスコマンド(READ)は、排他エラー
としてはねられ、受は付けられない。
(RE A D)コマンドの場合:ファイル更新の場合
は、ファイルアクセス排他管理を行なうため、リード(
READ、読み取り)受は付は時から、ライト(WRI
TE、書き込み)処理完了時まで、ファイル内の対象と
なるレコードへの他ユーザプログラムからのアクセスを
禁止する。そのために、UPa13がリード(READ
)状態のファイル(A)12のレコードに対する、UP
b23のアクセスコマンド(READ)は、排他エラー
としてはねられ、受は付けられない。
同様に、ファイル(A)22に到達したUPa13のリ
ード(READ)コマンドも排他エラーとしてはねられ
る。
ード(READ)コマンドも排他エラーとしてはねられ
る。
この状態で、UPa 13、および、UPb23がライ
ト(WRITE)処理を行なうと、ファイル(A)12
の対象レコードはUPa 13により、また、ファイル
(A)22の対象レコードはUPb23により、それぞ
れ更新される。そのために、ファイル(A)12とファ
イル(A)22の内容が食い違うことになる。
ト(WRITE)処理を行なうと、ファイル(A)12
の対象レコードはUPa 13により、また、ファイル
(A)22の対象レコードはUPb23により、それぞ
れ更新される。そのために、ファイル(A)12とファ
イル(A)22の内容が食い違うことになる。
(it)アクセスコマンドがレコード追加のための追加
(ADD)コマンドの場合: アクセスコマンドがファイルの同一レコードに対する追
加(ADD)コマンドの場合は、ファイル(A)12に
対してはLJPa 13の追加内容が、また、ファイル
(A)22に対しては、LI P b 23の追加内容
が反映されている。このことにより、ファイル(A)1
2とファイル(A)22の内容が食い違うことになる。
(ADD)コマンドの場合: アクセスコマンドがファイルの同一レコードに対する追
加(ADD)コマンドの場合は、ファイル(A)12に
対してはLJPa 13の追加内容が、また、ファイル
(A)22に対しては、LI P b 23の追加内容
が反映されている。このことにより、ファイル(A)1
2とファイル(A)22の内容が食い違うことになる。
(itt)アクセスコマンドが排他オーブン(OPEN
)コマンドの場合: アクセスコマンドが排他オーブン(OPEN)コマンド
の場合は、ファイル(A)12に対してはUPa13の
アクセスコマンドのみが、また、ファイル(A)22に
対してはUPb23のアクセスコマンドのみが受は付け
られ状態となる。このために、ファイル(A)12とフ
ァイル(A)22の内容が食い違う二とになる。
)コマンドの場合: アクセスコマンドが排他オーブン(OPEN)コマンド
の場合は、ファイル(A)12に対してはUPa13の
アクセスコマンドのみが、また、ファイル(A)22に
対してはUPb23のアクセスコマンドのみが受は付け
られ状態となる。このために、ファイル(A)12とフ
ァイル(A)22の内容が食い違う二とになる。
以上のような問題を解決するために、木簡1の実施例の
分散処理システムにおいて、各プロセッサ1〜3は、そ
れぞれの多重ファイルからの応答データ間のチェックを
行なう。そして、応答データ間での不一致を検出した場
合は、自プロセッサが、多重ファイルに対して発行した
アクセス命令を解除する命令を発行しく第1のリトライ
処1り、さらに、再び、最初のアクセス命令を発行する
(第2のリトライ処理)。
分散処理システムにおいて、各プロセッサ1〜3は、そ
れぞれの多重ファイルからの応答データ間のチェックを
行なう。そして、応答データ間での不一致を検出した場
合は、自プロセッサが、多重ファイルに対して発行した
アクセス命令を解除する命令を発行しく第1のリトライ
処1り、さらに、再び、最初のアクセス命令を発行する
(第2のリトライ処理)。
この時、アクセス命令の再発行は、各プロセッサが独自
のタイミングで行なうために、お互いのアクセス命令再
発行のタイミングは自動的にずれ、不整合状態の発生は
自動的に回避される。
のタイミングで行なうために、お互いのアクセス命令再
発行のタイミングは自動的にずれ、不整合状態の発生は
自動的に回避される。
このように、ファイル間の不整合が発生した場合は、発
行したアクセス命令を解除する命令を発行した後(第1
のリトライ処理)に、最初のアクセス命令と同じアクセ
ス命令を再び発行する(第2の゛リトライ処理)、この
ことにより、処理を中断することなく、不整合状態を自
動的に回復することができる。
行したアクセス命令を解除する命令を発行した後(第1
のリトライ処理)に、最初のアクセス命令と同じアクセ
ス命令を再び発行する(第2の゛リトライ処理)、この
ことにより、処理を中断することなく、不整合状態を自
動的に回復することができる。
以上のようにして、本第゛1の実施例の分散処理システ
ムにおける各プロセッサ1〜3は、多重化したファイル
に対し“−その整合性を保ったまま、各ユーザプログラ
ムが、同時にアクセスすることを可能とする。
ムにおける各プロセッサ1〜3は、多重化したファイル
に対し“−その整合性を保ったまま、各ユーザプログラ
ムが、同時にアクセスすることを可能とする。
尚、木簡1の実施例及び、以下に示す第2.第3の実施
例のネットワーク構成は、バス型ネットワークであるが
、これに限らず、任意の形態のネットワークで構成可能
である。
例のネットワーク構成は、バス型ネットワークであるが
、これに限らず、任意の形態のネットワークで構成可能
である。
また、各プロセッサ1〜3には、ターミナルl0120
.30およびディスク11.21.31が複数台接続さ
れていても良いし、−台も接続されていなくとも良い。
.30およびディスク11.21.31が複数台接続さ
れていても良いし、−台も接続されていなくとも良い。
さらに、木簡1の実施例では、ファイルは二重化ファイ
ルの例を示しているが、本発明は、任意の多重度に多重
化したファイルにも適用できる。
ルの例を示しているが、本発明は、任意の多重度に多重
化したファイルにも適用できる。
以下、第1の実施例の分散処理システムにおける各プロ
セッサの本発明に係る動作を、さらに詳しぐ説明する。
セッサの本発明に係る動作を、さらに詳しぐ説明する。
第2図は、第1図における分散処理システムの本発明に
係る処理動作の第1の実施例を示すフローチャートであ
る。
係る処理動作の第1の実施例を示すフローチャートであ
る。
第1図におけるクライアントファイル管理モジュール1
06の処理動作に関するものであり、特に、アクセス応
答メツセージの受信時、および、本発明の第1のリトラ
イ処理(以下、リトライ処理(1)と記載)と、第2の
リトライ処理(以下、すトライ処理(2)と記載)の動
作を示すものである。
06の処理動作に関するものであり、特に、アクセス応
答メツセージの受信時、および、本発明の第1のリトラ
イ処理(以下、リトライ処理(1)と記載)と、第2の
リトライ処理(以下、すトライ処理(2)と記載)の動
作を示すものである。
尚、この実施例は、多重化されたファイルからの応答を
一定時間の間収集し、その結果に基づき多重ファイル間
の整合性をチェックする方法である。
一定時間の間収集し、その結果に基づき多重ファイル間
の整合性をチェックする方法である。
第2図(a)は、受信したアクセス応答メツセージの読
みだしからリトライ処理(1)、(2)からなるリトラ
イチェック処理の開始までのフローを示し、第2図(b
)は、リトライチェック処理のフロー、そして、第2図
(c)、(d)は、それぞれ、リトライ処理(1)と、
リトライ処理(2)の処理の一実施例を示している。
みだしからリトライ処理(1)、(2)からなるリトラ
イチェック処理の開始までのフローを示し、第2図(b
)は、リトライチェック処理のフロー、そして、第2図
(c)、(d)は、それぞれ、リトライ処理(1)と、
リトライ処理(2)の処理の一実施例を示している。
まず、第2図(a)に基づき読切する。
クライアント管理モジュールは、ネットワークから受信
し、入力メツセージエリアに格納されたアクセス応答メ
ツセージを読みだしくステップ201)、送信SI子テ
ーブルチェックし、アクセス応答メツセージ内の発生源
情報部の値が、送信SI子テーブル発生源情報エリアに
登録されているか否かを判定する(ステップ202)。
し、入力メツセージエリアに格納されたアクセス応答メ
ツセージを読みだしくステップ201)、送信SI子テ
ーブルチェックし、アクセス応答メツセージ内の発生源
情報部の値が、送信SI子テーブル発生源情報エリアに
登録されているか否かを判定する(ステップ202)。
登録されていない場合は、自プロセッサが発生したアク
セス依頼に対する応゛答ではないため、そのメツセージ
を廃棄しくステップ2o3)、次のアクセス応答メツセ
ージを待つ。
セス依頼に対する応゛答ではないため、そのメツセージ
を廃棄しくステップ2o3)、次のアクセス応答メツセ
ージを待つ。
登録されている場合は、受信したアクセス応答メツセー
ジを、送信SI子テーブル対応する(メツセージ内の発
生源情報部の内容が登録されている)行の受信メツセー
ジエリアに格納する(ステップ204)。尚、この時、
個数エリアの値を一つ増加させる。
ジを、送信SI子テーブル対応する(メツセージ内の発
生源情報部の内容が登録されている)行の受信メツセー
ジエリアに格納する(ステップ204)。尚、この時、
個数エリアの値を一つ増加させる。
次に、アクセス依頼メツセージ発生時にセットしたタイ
マがタイムアウトしているか否かを、送信SI子テーブ
ルタイマエリアに基づき判定する(ステップ205)。
マがタイムアウトしているか否かを、送信SI子テーブ
ルタイマエリアに基づき判定する(ステップ205)。
タイムアウトしていない場合は、次のメツセージ受信の
待ち状態となる。
待ち状態となる。
タイムアウトの場合は、本発明のリトライ処理(1)、
(2)からなるリトライチェック処理を行なう(ステッ
プ206)。
(2)からなるリトライチェック処理を行なう(ステッ
プ206)。
以下、第2図(b)に基づき、リトライチェック処理を
説明する。
説明する。
送信SI子テーブル格納したアクセス応答メツセージが
、リトライ処理(1)に対応するメツセージか否かをチ
ェックする(ステップ207)。
、リトライ処理(1)に対応するメツセージか否かをチ
ェックする(ステップ207)。
リトライ処理(1)に対応するメツセージでなければ、
送信SI子テーブル受信メツセージエリア内に格納され
たアクセス応答メツセージ間で、その内容を比較する(
ステップ208)。
送信SI子テーブル受信メツセージエリア内に格納され
たアクセス応答メツセージ間で、その内容を比較する(
ステップ208)。
尚、その内容の比較の方法としては、メツセージの全内
容を比較する方法もあるが、ここでは、応答メツセージ
間で、アクセス処理の終了状態を示すステータス情報の
みを比較する方法とする。
容を比較する方法もあるが、ここでは、応答メツセージ
間で、アクセス処理の終了状態を示すステータス情報の
みを比較する方法とする。
さて、応答メツセージ間で、ステータス情報が一致する
場合は、多重化されている各ファイル間の整合性が保証
されているので、受信したファイルアクセス応答メツセ
ージをユーザプログラム、例えば、第1図のファイル(
A)12に渡すぐステップ209)。
場合は、多重化されている各ファイル間の整合性が保証
されているので、受信したファイルアクセス応答メツセ
ージをユーザプログラム、例えば、第1図のファイル(
A)12に渡すぐステップ209)。
その後、送信SI子テーブル対応するエリアをリセット
して(ステップ21o)、処理を終了する。
して(ステップ21o)、処理を終了する。
尚、ここで、受信した応答メツセージ数が「0」の場合
は、ユーザプログラムにファイル障害を示す情報を渡す
。
は、ユーザプログラムにファイル障害を示す情報を渡す
。
一方、ステップ208において、ファイルアクセス応答
メツセージ間で、終了ステータス情報が一致しない場合
は、多重化ファイル間の整合性が保証できないため、送
信SI子テーブル対応するエリアをリセットしくステッ
プ211)、応答メツセージを要求したファイルアクセ
ス依頼コマンド内容に応じて、次のリトライ処理(1)
を行なう(ステップ212)。
メツセージ間で、終了ステータス情報が一致しない場合
は、多重化ファイル間の整合性が保証できないため、送
信SI子テーブル対応するエリアをリセットしくステッ
プ211)、応答メツセージを要求したファイルアクセ
ス依頼コマンド内容に応じて、次のリトライ処理(1)
を行なう(ステップ212)。
また、ステップ207において、アクセス応答メツセー
ジが、リトライ処理(’1 )に対応するメツセージで
あれば、リトライ処理(2)を行なう(ステップ213
)。
ジが、リトライ処理(’1 )に対応するメツセージで
あれば、リトライ処理(2)を行なう(ステップ213
)。
以下、第2図(C)に基づき、リトライ処理(1)を説
明する。
明する。
まず、アクセス依頼がリード(READ)コマンドの場
合(ステップ214)、排他管理によりレコードを占有
している状態を解除するためのフリー(FREE)コマ
ンドをデータ部に持つアクセス依頼メツセージを作成し
、出力メツセージエリアに格納する(ステップ215)
。
合(ステップ214)、排他管理によりレコードを占有
している状態を解除するためのフリー(FREE)コマ
ンドをデータ部に持つアクセス依頼メツセージを作成し
、出力メツセージエリアに格納する(ステップ215)
。
アクセス依頼が追加(ADD)コマンドの場合には(ス
テップ216)、追加(ADD)コマンドにより追加し
たコードを削除するためのイレース(ERA S E)
コマンドをデータ部に持つアクセス依頼メツセージを作
成し、出力メツセージエリアに格納する(ステップ21
7)。
テップ216)、追加(ADD)コマンドにより追加し
たコードを削除するためのイレース(ERA S E)
コマンドをデータ部に持つアクセス依頼メツセージを作
成し、出力メツセージエリアに格納する(ステップ21
7)。
アクセス依頼が排他オーブン(OPEN)コマンドの場
合には(ステップ218)、排他オーブン(OPEN)
コマンドによりファイルを占有している状態となってい
るため、この状態を解除するためのクローズ(CLOS
E)コマンドをデータ部に持つアクセス依頼メツセージ
を作成して、出力メツセージエリアに格納する(ステッ
プ219)。
合には(ステップ218)、排他オーブン(OPEN)
コマンドによりファイルを占有している状態となってい
るため、この状態を解除するためのクローズ(CLOS
E)コマンドをデータ部に持つアクセス依頼メツセージ
を作成して、出力メツセージエリアに格納する(ステッ
プ219)。
このように、それぞれのアクセス依頼メツセージに対応
しくステップ220)、それぞれのアクセス依頼メツセ
ージによるファイルの占有状態を解除するためのコマン
ドをデータ部に持つアクセス依頼メツセージを作成し、
出力メツセージエリアに格納する(ステップ221)。
しくステップ220)、それぞれのアクセス依頼メツセ
ージによるファイルの占有状態を解除するためのコマン
ドをデータ部に持つアクセス依頼メツセージを作成し、
出力メツセージエリアに格納する(ステップ221)。
尚、これらのメツセージ(FREE、ERASE、CL
O8Eコマンドなど)は、通信管理モジュールにより、
第1図のネットワーク4にブロードキャストされる。
O8Eコマンドなど)は、通信管理モジュールにより、
第1図のネットワーク4にブロードキャストされる。
そして、このようなリトライ処理(1)により発行され
たアクセス依頼メツセージに対するアクセス応答メツセ
ージの受信を待つ。
たアクセス依頼メツセージに対するアクセス応答メツセ
ージの受信を待つ。
このリトライ処理(1)に対する応答メツセージに関し
ても、ステップ201〜206の処理フローに従う、そ
して、ステップ207において、受信メツセージが、リ
トライ処理(1)により発生されたコマンドに対するア
クセス応答メツセージであると確認されれば、リトライ
処理(2)を行なう(ステップ213)。
ても、ステップ201〜206の処理フローに従う、そ
して、ステップ207において、受信メツセージが、リ
トライ処理(1)により発生されたコマンドに対するア
クセス応答メツセージであると確認されれば、リトライ
処理(2)を行なう(ステップ213)。
以下、第2図(d)に基づき、リトライ処理(2)を説
明する。
明する。
このリトライ処理(2)では、リトライ処理(1)を行
なうトリガとなったアクセス依頼コマンドをデータ部に
持つアクセス依頼メツセージを作成し、出力メツセージ
エリアに格納する。
なうトリガとなったアクセス依頼コマンドをデータ部に
持つアクセス依頼メツセージを作成し、出力メツセージ
エリアに格納する。
すなわち、リトライ処理(1)でフリー(F RE E
)コマンドが発行されていれば(ステップ222)、す
、−ド(READ)コマンドをデータ部に持つアクセス
依頼メツセージを作成し、出力メツセージエリアに格納
する(ステップ223)。
)コマンドが発行されていれば(ステップ222)、す
、−ド(READ)コマンドをデータ部に持つアクセス
依頼メツセージを作成し、出力メツセージエリアに格納
する(ステップ223)。
また、リトライ処理(1)でイレース(ERASE)コ
マンドをデータ部に持つアクセス依頼メツセージを作成
していれば(ステップ224)、追加(ADD)’コマ
ンドをデータ部に持つアクセス依頼メツセージを作成し
、出力メツセージエリアに格納する(ステップ225)
。
マンドをデータ部に持つアクセス依頼メツセージを作成
していれば(ステップ224)、追加(ADD)’コマ
ンドをデータ部に持つアクセス依頼メツセージを作成し
、出力メツセージエリアに格納する(ステップ225)
。
また、リトライ処理(1)でクローズ(CLOSE)コ
マンドをデータ部に持つアクセス依頼メツセージを作成
していれば(ステップ226)、排他オーブン(OP
E N)コマンドをデータ部に持つアクセス依頼メツセ
ージを作成して、出力メツセージエリアに格納する(ス
テップ227)。
マンドをデータ部に持つアクセス依頼メツセージを作成
していれば(ステップ226)、排他オーブン(OP
E N)コマンドをデータ部に持つアクセス依頼メツセ
ージを作成して、出力メツセージエリアに格納する(ス
テップ227)。
このように、リトライ処理(1)によりファイルの占有
状態を解除されたそれぞれのアクセス依頼メツセージに
対応しくステップ228)、同じ、アクセス依頼メツセ
ージを再度作成し、出力メツセージエリアに格納する(
ステップ229)。
状態を解除されたそれぞれのアクセス依頼メツセージに
対応しくステップ228)、同じ、アクセス依頼メツセ
ージを再度作成し、出力メツセージエリアに格納する(
ステップ229)。
そして、これらのメツセージ(READ1ADD1徘他
0PENコマンドなど)は、通信管理モジュールにより
、第1図のネットワーク4にブロードキャストされる。
0PENコマンドなど)は、通信管理モジュールにより
、第1図のネットワーク4にブロードキャストされる。
尚、このリトライ処理(2)と同じ内容のリトライ処理
(2)が、他のプロセッサでも発行されるが、この時は
、それぞれの発行タイミングが異なる。
(2)が、他のプロセッサでも発行されるが、この時は
、それぞれの発行タイミングが異なる。
そのために、リトライ処理(2)により発りされるメツ
セージによるファイル間の不整合は、発生しない、そし
て、このリトライ処理(2)に対応する受信メツセージ
は、ステップ208における不整合チェックでOK(r
整合」)となり、正常に終了することができる。
セージによるファイル間の不整合は、発生しない、そし
て、このリトライ処理(2)に対応する受信メツセージ
は、ステップ208における不整合チェックでOK(r
整合」)となり、正常に終了することができる。
このように、本実施例の分散処理システムによれば、多
重ファイル間に不整合が発生した状況でも、リトライ処
理(1)により不整合状態を解除し、その後、リトライ
処理(2)によりアクセス処理が再実行されるため、フ
ァイル間の整合性は、自動的に保証された状態になる。
重ファイル間に不整合が発生した状況でも、リトライ処
理(1)により不整合状態を解除し、その後、リトライ
処理(2)によりアクセス処理が再実行されるため、フ
ァイル間の整合性は、自動的に保証された状態になる。
尚、各プロセッサによるリトライ処理(2)の実行タイ
ミングをずらす目的で、それぞれのリトライ処理(2〕
のリトライコマンドを発行する前に、ランダムな待ち時
間をいれても良い。
ミングをずらす目的で、それぞれのリトライ処理(2〕
のリトライコマンドを発行する前に、ランダムな待ち時
間をいれても良い。
以下、さらに、第1図における実線矢印(a)と点線矢
印(b)で示す2つのファイルアクセスに基づき、本発
明に係る処理動作を説明する。
印(b)で示す2つのファイルアクセスに基づき、本発
明に係る処理動作を説明する。
第3図は、第1図における分散処理システムの本発明に
係る処理動作の一実施例を示すタイムチャートである。
係る処理動作の一実施例を示すタイムチャートである。
第2図で示した処理動作に基づくタイムチャートであり
、第1図の二つのユーザプログラム、UPa13とL7
Pb23が、それぞれ同時に多重化されたファイル(A
)12.22をリードCREAD〕アクセスする場合を
示す。
、第1図の二つのユーザプログラム、UPa13とL7
Pb23が、それぞれ同時に多重化されたファイル(A
)12.22をリードCREAD〕アクセスする場合を
示す。
UF’a13が、ファイルアクセスコマンド(READ
)300を発行してアクセス依頼すると、プロセッサl
のクライアントファイル管理モジュール106は、ファ
イルアクセスコマンド(READ)300に対応するア
クセス依頼メツセージ(READ)301を、自プロセ
ッサディスク内のファイル(A)12と、第1図のプロ
セッサ2のディスク21内のファイル(A)22に送る
。
)300を発行してアクセス依頼すると、プロセッサl
のクライアントファイル管理モジュール106は、ファ
イルアクセスコマンド(READ)300に対応するア
クセス依頼メツセージ(READ)301を、自プロセ
ッサディスク内のファイル(A)12と、第1図のプロ
セッサ2のディスク21内のファイル(A)22に送る
。
この場合、第1図のネットワーク4を介さないで済む自
プロセッサ内のファイル(A)12の方が先に処理され
る。そして、ファイル(A)12のファイルアクセスコ
マンド(READ)300に対する処理結果を示すステ
ータス情報302が、UPa13に送られ、アクセス応
答がなされる。
プロセッサ内のファイル(A)12の方が先に処理され
る。そして、ファイル(A)12のファイルアクセスコ
マンド(READ)300に対する処理結果を示すステ
ータス情報302が、UPa13に送られ、アクセス応
答がなされる。
UPa13がファイルアクセスコマンド(READ)3
00を発行したのと同時に、UPb23が、UPa 1
3と同一レコードに対する同様なファイルアクセスコマ
ンド(READ)320を発行したものとする。
00を発行したのと同時に、UPb23が、UPa 1
3と同一レコードに対する同様なファイルアクセスコマ
ンド(READ)320を発行したものとする。
すると、プロセッサ2内のクライアントファイル管理モ
ジュール126は、UPb23が発生したファイルアク
セスコマンド(READ)320に対応するアクセス依
頼メツセージ(READ)321を、同様に、自プロセ
ッサディスク内のファイル(A)22と、プロセッサl
のディスク内のファイル(A)12に送る。
ジュール126は、UPb23が発生したファイルアク
セスコマンド(READ)320に対応するアクセス依
頼メツセージ(READ)321を、同様に、自プロセ
ッサディスク内のファイル(A)22と、プロセッサl
のディスク内のファイル(A)12に送る。
この場合、自プロセッサ内のファイル(A)22の方が
先に処理される。そして、ファイル(A)22のファイ
ルアクセスコマンド(READ)320に対する処理結
果を示すステータス情報322が、UPb23に送られ
る。
先に処理される。そして、ファイル(A)22のファイ
ルアクセスコマンド(READ)320に対する処理結
果を示すステータス情報322が、UPb23に送られ
る。
ここでは、ファイル(A)12に対しては、UPa13
がアクセスし、ファイル(A)22に対しては、UPb
23がアクセスしている状態が発生する。
がアクセスし、ファイル(A)22に対しては、UPb
23がアクセスしている状態が発生する。
この状態で、ファイル(A)12には、UPb23から
のファイルアクセスコマンド(READ)320に対応
するアクセス依頼メツセージ321が、一方、ファイル
(A)22には、UPa 13がらのファイルアクセス
コマンド(READ)300に対応するアクセス依頼メ
ツセージ301が到達する。この場合、ファイルアクセ
スコマンド300.320の内容によっては、ハード的
には全く障害がなくても、第1図の説明において述べた
ような状態が発生する。
のファイルアクセスコマンド(READ)320に対応
するアクセス依頼メツセージ321が、一方、ファイル
(A)22には、UPa 13がらのファイルアクセス
コマンド(READ)300に対応するアクセス依頼メ
ツセージ301が到達する。この場合、ファイルアクセ
スコマンド300.320の内容によっては、ハード的
には全く障害がなくても、第1図の説明において述べた
ような状態が発生する。
すなわち、ファイルアクセスコマンド300.320が
、ファイル更新のためのリード(READ)コマンドで
あり、ファイルアクセス排他管理を行なうため、UPa
13がリード状態のファイル(A)12のレコードに
対するUPb23のファイルアクセスコマンド(REA
D)320に対応するアクセス依頼メツセージ321は
、排他エラーとしてはねられ、受は付けられない。
、ファイル更新のためのリード(READ)コマンドで
あり、ファイルアクセス排他管理を行なうため、UPa
13がリード状態のファイル(A)12のレコードに
対するUPb23のファイルアクセスコマンド(REA
D)320に対応するアクセス依頼メツセージ321は
、排他エラーとしてはねられ、受は付けられない。
同様に、ファイル(A)22に到達したUPa 13の
ファイルアクセスコマンド(READ)300に対応す
るアクセス依頼メツセージ301も排他エラーとしては
ねられる。
ファイルアクセスコマンド(READ)300に対応す
るアクセス依頼メツセージ301も排他エラーとしては
ねられる。
二の状態で、UPa 13、および、UPb23が書き
込み処理を行なうと、ファイル(A’) 12の対象レ
コードはUP’a13により、また、ファイル(A)2
2の対象レコードはUPb23により更新されるため、
ファイル(A)12とファイル(A)22の内容が食い
違うことになる。
込み処理を行なうと、ファイル(A’) 12の対象レ
コードはUP’a13により、また、ファイル(A)2
2の対象レコードはUPb23により更新されるため、
ファイル(A)12とファイル(A)22の内容が食い
違うことになる。
このようなファイルの不整合状態の問題を解決するため
に、第1図における分散処理システムの各プロセッサは
、それぞれの多重ファイルからの応答データ間のチェッ
クを行ない、かつ、応答データ間での不一致を検出した
場合は、自プロセッサが、多重ファイルに対して発行し
たアクセス命令を解除する命令を発行し、その後、再び
、同じアクセス命令を発行する。
に、第1図における分散処理システムの各プロセッサは
、それぞれの多重ファイルからの応答データ間のチェッ
クを行ない、かつ、応答データ間での不一致を検出した
場合は、自プロセッサが、多重ファイルに対して発行し
たアクセス命令を解除する命令を発行し、その後、再び
、同じアクセス命令を発行する。
すなわち、UPa 13を実行しているプロセッサlの
クライアントファイル管理モジュール106は、UPa
13が発生したファイルアクセスコマンド(READ)
300に対応するファイル(A)12.22からのアク
セス応答メツセージのステータス情報302,303が
食い違っていることにより、第2図で説明したリトライ
処理(1)304を実行し、アクセス依頼メツセージ(
READ)301を解除する解除依頼メツセージ(F
RE E)305を発行する。
クライアントファイル管理モジュール106は、UPa
13が発生したファイルアクセスコマンド(READ)
300に対応するファイル(A)12.22からのアク
セス応答メツセージのステータス情報302,303が
食い違っていることにより、第2図で説明したリトライ
処理(1)304を実行し、アクセス依頼メツセージ(
READ)301を解除する解除依頼メツセージ(F
RE E)305を発行する。
この解除依頼メツセージ(FREE)305により、U
Pa 13によるファイル(A)12の占有状態が解除
される。
Pa 13によるファイル(A)12の占有状態が解除
される。
同様に、クライアントファイル管理モジュール126は
、UPb23が発生したファイルアクセスコマンド(R
EAD)320に対するファイル(A)12.22から
のアクセス応答メツセージのステータス情報322.3
23が食い違っていることにより、第2図におけるリー
トライ処理(1)324を実行し、アクセス依頼メツセ
ージ(READ)321を解除する解除依頼メツセージ
(FREE)325を発行する。
、UPb23が発生したファイルアクセスコマンド(R
EAD)320に対するファイル(A)12.22から
のアクセス応答メツセージのステータス情報322.3
23が食い違っていることにより、第2図におけるリー
トライ処理(1)324を実行し、アクセス依頼メツセ
ージ(READ)321を解除する解除依頼メツセージ
(FREE)325を発行する。
この解除依頼メツセージ(FREE)325により、フ
ァイル(A)22のUPb23による占有状態が解除さ
れる。
ァイル(A)22のUPb23による占有状態が解除さ
れる。
これらの占有状態の解除が、応答メツセージ306.3
07.326.327により、それぞれのクライアント
ファイル管理モジュール106.126に通知される。
07.326.327により、それぞれのクライアント
ファイル管理モジュール106.126に通知される。
そして、ファイル(A)12.22の両ファイルとも占
有されていない状態で、UPa13、UPb23が実行
されている各プロセッサ1.2のクライアントファイル
管理モジュール1806.126は、第2図で説明した
リトライ処理(2)308.328により、アクセス依
頼メツセージ(READ)301,321とそれぞれ同
じアクセス依頼メツセージ(READ)309.329
を再発行する。
有されていない状態で、UPa13、UPb23が実行
されている各プロセッサ1.2のクライアントファイル
管理モジュール1806.126は、第2図で説明した
リトライ処理(2)308.328により、アクセス依
頼メツセージ(READ)301,321とそれぞれ同
じアクセス依頼メツセージ(READ)309.329
を再発行する。
以上のリトライ処理(1)304.324およびリトラ
イ処理(2)308.328は、アクセス処理が成功す
るまで繰り返される。
イ処理(2)308.328は、アクセス処理が成功す
るまで繰り返される。
しかし、リトライ処理(2)308.328によ。
るアクセス依頼メツセージ(READ)309,329
の発行は、プロセッサ1.2が、独自のタイミングで行
なう、そのために、アクセス依頼メツセージ(READ
)309.329の発行のタイミングは自動的にずれ、
リトライ処理(2)308.328により発行されるア
クセス依頼メツセージ(READ)309.329に関
しては、その不整合状態の発生は自動的に回避される。
の発行は、プロセッサ1.2が、独自のタイミングで行
なう、そのために、アクセス依頼メツセージ(READ
)309.329の発行のタイミングは自動的にずれ、
リトライ処理(2)308.328により発行されるア
クセス依頼メツセージ(READ)309.329に関
しては、その不整合状態の発生は自動的に回避される。
また、UPa13、UPb23でのリトライ実行タイミ
ングをずらすため、リトライ処理(2)308.328
において、リトライコマンド(アクセス依頼メツセージ
(READ)309.329を発行する前に、それぞれ
にランダムな待ち時間をいれても良い。このことにより
、リトライ処理(2)308.328に基づくファイル
アクセスを、確実に実行することができる。
ングをずらすため、リトライ処理(2)308.328
において、リトライコマンド(アクセス依頼メツセージ
(READ)309.329を発行する前に、それぞれ
にランダムな待ち時間をいれても良い。このことにより
、リトライ処理(2)308.328に基づくファイル
アクセスを、確実に実行することができる。
以上示した方法は、多重化されたファイルからの応答を
一定時間の間収集し、その結果に基づき多重ファイル間
の整合性をチェックする方法である。
一定時間の間収集し、その結果に基づき多重ファイル間
の整合性をチェックする方法である。
これに対して、多重ファイルからの応答を一定時間では
なく、予め決められた多重度数分を収集する方法も可能
である。以下、この方法による本発明の第2の実施例を
説明する。
なく、予め決められた多重度数分を収集する方法も可能
である。以下、この方法による本発明の第2の実施例を
説明する。
水弟2の実施例を行なうために、第1図で示した送信S
Iテーブル107、および、ファイル管理テーブル11
0にファイルの多重度を示す多重度エリアを設定する。
Iテーブル107、および、ファイル管理テーブル11
0にファイルの多重度を示す多重度エリアを設定する。
第4図は、第1図における送信Slテーブルおよびファ
イル管理テーブルの構成の第2の実施例を示す説明図で
ある。
イル管理テーブルの構成の第2の実施例を示す説明図で
ある。
第4図(a)における送信Slテーブル407は、各行
4071〜4072に、第1図のSIエリア10711
、タイマエリア10712、個数エリア10713、受
信メツセージエリア10714に、多重度エリア400
を付与して構成され、また、第4図(b)におけるファ
イル管理テーブル410は、各行4101〜4102に
、第1図のFNMエリア11011.物理情報エリア1
1012、S I工1,1711013ニ、多重度エリ
ア401を付与して構成されている。
4071〜4072に、第1図のSIエリア10711
、タイマエリア10712、個数エリア10713、受
信メツセージエリア10714に、多重度エリア400
を付与して構成され、また、第4図(b)におけるファ
イル管理テーブル410は、各行4101〜4102に
、第1図のFNMエリア11011.物理情報エリア1
1012、S I工1,1711013ニ、多重度エリ
ア401を付与して構成されている。
ファイル管理テーブル410の多重度エリア401は、
各プロセッサにおいて、ファイルアロケート時に設定さ
れるものとする。
各プロセッサにおいて、ファイルアロケート時に設定さ
れるものとする。
また、第1図におけるサーバファイル管理モジュール1
09は、アクセス依頼に対するアクセス応答メツセージ
内に、ファイル管理テーブル41Oの多重度エリア40
1の内容を多重度情報として設定する。
09は、アクセス依頼に対するアクセス応答メツセージ
内に、ファイル管理テーブル41Oの多重度エリア40
1の内容を多重度情報として設定する。
一方、第1図のクライアントファイル管理モジュール1
06は、0PENコマンドに対応する応答メツセージ受
信時に、メツセージ内の多重度を、送信SI子テーブル
07の多重度エリア4o○に設定する。
06は、0PENコマンドに対応する応答メツセージ受
信時に、メツセージ内の多重度を、送信SI子テーブル
07の多重度エリア4o○に設定する。
この送信Slテーブル407とファイル管理テーブル4
10を有する第2の実施例の分散処理システムでは、第
1図のクライアントファイル管理モジュール106は、
アクセス応答メツセージ受信時において、これら送信S
I子テーブル07、および、ファイル管理テーブル41
0に付与された多重度二リア400.401に基づき、
受信メツセージエリアに格納したアクセス応答メツセー
ジ間の整合性をチェックする。
10を有する第2の実施例の分散処理システムでは、第
1図のクライアントファイル管理モジュール106は、
アクセス応答メツセージ受信時において、これら送信S
I子テーブル07、および、ファイル管理テーブル41
0に付与された多重度二リア400.401に基づき、
受信メツセージエリアに格納したアクセス応答メツセー
ジ間の整合性をチェックする。
このように、ある一定の時間前に、必要な数分のアクセ
ス応答メツセージが返ってきた時点で、アクセス応答メ
ツセージ間の整合性のチェックを行なうことにより、第
2図のフローチャートで示した処理よりも効率の良いリ
トライチェック処理等を行なうことができる。
ス応答メツセージが返ってきた時点で、アクセス応答メ
ツセージ間の整合性のチェックを行なうことにより、第
2図のフローチャートで示した処理よりも効率の良いリ
トライチェック処理等を行なうことができる。
第5図は、第1図における分散処理システムの本発明に
係る処理動作の第2の実施例を示すフローチャートであ
る。
係る処理動作の第2の実施例を示すフローチャートであ
る。
第4図における送信SI子テーブル07、および、ファ
イル管理テーブル410を有する分散処理システムの動
作であり、特に、第1図に示すクライアントファイル管
理モジュール106が行なう処理フローを示す。
イル管理テーブル410を有する分散処理システムの動
作であり、特に、第1図に示すクライアントファイル管
理モジュール106が行なう処理フローを示す。
まず、クライアント管理モジュールは、ネットワークか
ら受信し、入力メツセージエリアに格納されたアクセス
応答メツセージを読みだしくステップ501)、送信S
エテーブルをチェックし、アクセス応答メツセージ内の
発生源情報部の値が、送信SI子テーブル発生源情報エ
リアに登録されているか否かを判定する(ステップ50
2)。
ら受信し、入力メツセージエリアに格納されたアクセス
応答メツセージを読みだしくステップ501)、送信S
エテーブルをチェックし、アクセス応答メツセージ内の
発生源情報部の値が、送信SI子テーブル発生源情報エ
リアに登録されているか否かを判定する(ステップ50
2)。
登録されていない場合は、自プロセッサが発生したアク
セス依頼に対する応答ではないため、そのメツセージを
廃棄しくステップ503)、次のアクセス応答メツセー
ジを待つ。
セス依頼に対する応答ではないため、そのメツセージを
廃棄しくステップ503)、次のアクセス応答メツセー
ジを待つ。
登録されている場合は、このアクセス応答メツセージを
、送信SI子テーブル対応する(メツセージ内の発生源
情報部の内容が登録されている)行の受信メツセージエ
リアに格納する(ステップ504)。尚、この時、個数
エリアの値を一つ増加させる。
、送信SI子テーブル対応する(メツセージ内の発生源
情報部の内容が登録されている)行の受信メツセージエ
リアに格納する(ステップ504)。尚、この時、個数
エリアの値を一つ増加させる。
ここまでの処理は、第2図の第1の実施例におけるステ
ップ201〜204と同じである。
ップ201〜204と同じである。
次に、送信SIテーブル内の個数エリアの値、すなわち
、受信したアクセス応答メツセージの数と、第4図にお
ける多重度エリア400の値とが一致するか否かを判定
する(ステップ505)。
、受信したアクセス応答メツセージの数と、第4図にお
ける多重度エリア400の値とが一致するか否かを判定
する(ステップ505)。
受信したアクセス応答メツセージの数と、多重度エリア
の値とが一致する場合、すなわち、多重化ファイルの全
てから応答が戻ってきたならば、第2図におけるステッ
プ206と同じリトライチェック処理を行なう(ステッ
プ506)。
の値とが一致する場合、すなわち、多重化ファイルの全
てから応答が戻ってきたならば、第2図におけるステッ
プ206と同じリトライチェック処理を行なう(ステッ
プ506)。
一致しない場合は、第2111のステップ205と同じ
タイムアウトチェックを行なう(ステップ507)。す
なわち、アクセス依頼メツセージ発生時にセットしたタ
イマがタイムアウトしているが否かを、第4図における
送信SI子テーブル07のタイマエリア10712に基
づき判定する。
タイムアウトチェックを行なう(ステップ507)。す
なわち、アクセス依頼メツセージ発生時にセットしたタ
イマがタイムアウトしているが否かを、第4図における
送信SI子テーブル07のタイマエリア10712に基
づき判定する。
タイムアウトしていない場合は、次のメツセージの受信
待ち状態に戻る。
待ち状態に戻る。
タイムアウトの場合は、第4図の送信Slテーブル40
7のリセット後(ステップ508)、障害処理を行ない
(ステップ509)、その後、ステップ506のリトラ
イチェック処理を行なう。
7のリセット後(ステップ508)、障害処理を行ない
(ステップ509)、その後、ステップ506のリトラ
イチェック処理を行なう。
この障害処理では、第4図における送信SI子テーブル
07の多重度エリアの値に、個数エリア10713の値
を設定する。
07の多重度エリアの値に、個数エリア10713の値
を設定する。
このようにして、第2の実施例では、多重度数分の応答
メツセージを受信したタイミングで、リトライチェック
処理を行なうことができる。
メツセージを受信したタイミングで、リトライチェック
処理を行なうことができる。
このことにより、第1の実施例よりも、応答性が向上す
る。
る。
次に、第1@における分散処理システムの第3の実施例
を説明する。
を説明する。
末弟3の実施例では、第1図に示した配置において、プ
ロセッサlのディスクll内のファイル(A)12から
の応答が戻ったタイミングで、UPa13に制御を戻し
、かつ、多重ファイル間の整合性を保証する。
ロセッサlのディスクll内のファイル(A)12から
の応答が戻ったタイミングで、UPa13に制御を戻し
、かつ、多重ファイル間の整合性を保証する。
すなわち、第2図、および、第5図で示した、第1、第
2の実施例では、リトライチェック処理を、多重ファイ
ルからの応答が全て揃ったタイミングで行なっていた。
2の実施例では、リトライチェック処理を、多重ファイ
ルからの応答が全て揃ったタイミングで行なっていた。
そのため、応答性の面で、次の問題が生じる。
例えば、第1図において、プロセッサl内で実行中のU
Pa13が、自プロセッサディスク11と、プロセッサ
2のディスク21とに多重化されたファイル(A)12
.22をアクセスする場合、UPa l 3は、自プロ
セッサディスク11のファイル(A)12をアクセスし
ているにもかかわらず、第11および、第2の実施例で
は、アクセス応答がUPa13に戻るタイミングは、フ
ァイル(A)22の応答がネットワーク4を介して戻る
タイミングに合わされてしまう。
Pa13が、自プロセッサディスク11と、プロセッサ
2のディスク21とに多重化されたファイル(A)12
.22をアクセスする場合、UPa l 3は、自プロ
セッサディスク11のファイル(A)12をアクセスし
ているにもかかわらず、第11および、第2の実施例で
は、アクセス応答がUPa13に戻るタイミングは、フ
ァイル(A)22の応答がネットワーク4を介して戻る
タイミングに合わされてしまう。
末弟3の実施例では、このような応答性の低下を防止す
るものである。
るものである。
また、末弟3の実施例では、送信S1テーブル、および
、ファイル管理テーブルの構成は第4図に示す第2の実
施例と同一である。但し、多重化されたファイルの内の
一つを、競合発生時の優先ファイルとして使用する。
、ファイル管理テーブルの構成は第4図に示す第2の実
施例と同一である。但し、多重化されたファイルの内の
一つを、競合発生時の優先ファイルとして使用する。
この優先ファイルの指定は、ファイル70ケート時にな
っても良いし、また、ユーザが指定するのではなく、フ
ァイルオーブン時に応答を介してきた多重ファイルの内
から、そのファイルの属するプロセッサ番号の、例えば
、一番小さなものを優先ファイルとすることでも良い。
っても良いし、また、ユーザが指定するのではなく、フ
ァイルオーブン時に応答を介してきた多重ファイルの内
から、そのファイルの属するプロセッサ番号の、例えば
、一番小さなものを優先ファイルとすることでも良い。
以下、末弟3の実施例の処理動作を、第6図に基づき説
明する。
明する。
第6図は、第1図における分散処理システムの本発明に
係る処理の第3の実施例を示すフローチャートである。
係る処理の第3の実施例を示すフローチャートである。
第1、第2の実施例と同様に、第1図におけるクライア
ントファイル管理モジュール106のアクセス応答メツ
セージ受信時の処理フローを示す図である。
ントファイル管理モジュール106のアクセス応答メツ
セージ受信時の処理フローを示す図である。
第6図(a)は、受信したアクセス応答メツセージの読
みだしから、末弟3の実施例におけるリトライチェック
処理に至るまでの処理フローであり、第6図(b)は、
末弟3の実施例におけるリトライチェック処理の処理フ
ロー、そして、第6図(c)および(d)は、それぞれ
、末弟3の実施例におけるリトライ処理(3)、(4)
の処理フローを示すものである。
みだしから、末弟3の実施例におけるリトライチェック
処理に至るまでの処理フローであり、第6図(b)は、
末弟3の実施例におけるリトライチェック処理の処理フ
ロー、そして、第6図(c)および(d)は、それぞれ
、末弟3の実施例におけるリトライ処理(3)、(4)
の処理フローを示すものである。
第6図(a)に基づき、アクセス応答メツセージの読み
だしから、末弟3の実施例におけるリトライチェック処
理に至るまでの処理を説明する。
だしから、末弟3の実施例におけるリトライチェック処
理に至るまでの処理を説明する。
まず、クライアント管理モジュールは、ネットワークか
ら受信し、入力メツセージエリアに格納されたアクセス
応答メツセージを読みだしくステップ601)、送信S
I子テーブルチェックし、アクセス応答メツセージ内の
発生源情報部の値が、送信St子テーブル発生源情報エ
リアに登録されているか否かを判定する(ステップ60
2)。
ら受信し、入力メツセージエリアに格納されたアクセス
応答メツセージを読みだしくステップ601)、送信S
I子テーブルチェックし、アクセス応答メツセージ内の
発生源情報部の値が、送信St子テーブル発生源情報エ
リアに登録されているか否かを判定する(ステップ60
2)。
登録されていない場合は、自ブロセ5ツサが発生したア
クセス依頼に対する応答ではないため、そのメツセージ
を廃棄しくステップ603)、次のアクセス応答メツセ
ージを待つ。
クセス依頼に対する応答ではないため、そのメツセージ
を廃棄しくステップ603)、次のアクセス応答メツセ
ージを待つ。
ここまでの処理は、第2図、および、第5図における第
1、第2の実施例と同じである。
1、第2の実施例と同じである。
登録されている場合は、このアクセス応答メツセージが
、後述のリトライ処理(3)に対応するメツセージか否
かをチェックする(ステップ6o4)。
、後述のリトライ処理(3)に対応するメツセージか否
かをチェックする(ステップ6o4)。
リトライ処理(3)に対応するメツセージであれば、ス
テップ608に進む。
テップ608に進む。
リトライ処理(3)に対応するメツセージでない場合は
、優先ファイル(A)からの応答であるか否かを判断す
る(ステップ605)。
、優先ファイル(A)からの応答であるか否かを判断す
る(ステップ605)。
優先ファイル(A)からの応答でなければ、後述のステ
ップ608に進み、優先ファイル(A)からの応答であ
れば、そのメツセージを依頼先のユーザプログラム(こ
こでは、第1図のUPa13)に渡しくステップ606
)、リトライチェック処理モードとする(ステップ60
7)。
ップ608に進み、優先ファイル(A)からの応答であ
れば、そのメツセージを依頼先のユーザプログラム(こ
こでは、第1図のUPa13)に渡しくステップ606
)、リトライチェック処理モードとする(ステップ60
7)。
次に、このメツセージのステータス情報を送信SI子テ
ーブル格納しくステップ608)、多重度数分の応答を
受信したか否かを判断する(ステップ609)。
ーブル格納しくステップ608)、多重度数分の応答を
受信したか否かを判断する(ステップ609)。
多重度数分の応答を受信していれば、後述のステップ6
13に進みリトライチェック処理を行ない、多重度数分
の応答を受信していなければ、タイムアウトしたか否か
を判断する(ステップ610)。
13に進みリトライチェック処理を行ない、多重度数分
の応答を受信していなければ、タイムアウトしたか否か
を判断する(ステップ610)。
タイムアウトでなければ、ステップ601に戻り、次の
受信メツセージの読みだしを行なう。
受信メツセージの読みだしを行なう。
タイムアウトであれば、送信SI子テーブルリセットし
て(ステップ611)、障害処理を行ない(ステップ6
12)、リトライチェック処理613に移る。
て(ステップ611)、障害処理を行ない(ステップ6
12)、リトライチェック処理613に移る。
尚、この障害処理では、第4図における送信S■子テー
ブル07の多重度エリアの値に、個数エリア10713
の値を設定する。
ブル07の多重度エリアの値に、個数エリア10713
の値を設定する。
以上のステップ605〜607の処理により、重篤3の
実施例では、自プロセッサのファイルからの応答を受信
したタイミングで応答メツセージを依頼した第1図のU
Pa l 3に制御を戻す。また、クライアントファイ
ル管理モジュールは、リトライチェックモードの間は、
他のユーザプログラムからのアクセスコマンドを受は付
けても、リトライチェックモー−が解除されるまで、そ
の処理実行を待つ。
実施例では、自プロセッサのファイルからの応答を受信
したタイミングで応答メツセージを依頼した第1図のU
Pa l 3に制御を戻す。また、クライアントファイ
ル管理モジュールは、リトライチェックモードの間は、
他のユーザプログラムからのアクセスコマンドを受は付
けても、リトライチェックモー−が解除されるまで、そ
の処理実行を待つ。
すなわち、第illにおいて、優先ファイルであるファ
イル(A)12からのアクセス応答メツセージ受信時は
、ステップ601〜605における処理を進め、ステッ
プ606でアクセス応答メツセージをUPa 13に渡
して制御を戻し、その後、ステップ607以降の処理を
実行する。
イル(A)12からのアクセス応答メツセージ受信時は
、ステップ601〜605における処理を進め、ステッ
プ606でアクセス応答メツセージをUPa 13に渡
して制御を戻し、その後、ステップ607以降の処理を
実行する。
しかし、優先ファイルでないファイル(A)22からの
アクセス応答メツセージの受信時は、ステップ606か
ら、ステップ608に移り、ステップ609における判
断処理を行なう。
アクセス応答メツセージの受信時は、ステップ606か
ら、ステップ608に移り、ステップ609における判
断処理を行なう。
ここで、多重度数分の応答を受信している状態であれば
、ステップ613のリトライチェック処理を実施する。
、ステップ613のリトライチェック処理を実施する。
次に、第6図(b)に基づき、重篤3の実施例における
リトライチェック処理を説明する。
リトライチェック処理を説明する。
このリトライチェック処理では、まず、受信した応答メ
ツセージが、後述のリトライ処理(3)に対応するメツ
セージか否かを判断する(ステップ614)。
ツセージが、後述のリトライ処理(3)に対応するメツ
セージか否かを判断する(ステップ614)。
リトライ処理(3)に対応するメツセージでなければ、
送信SI子テーブル登録されている応答メツセージのス
テータス情報が一致するか否かをチェックする(ステッ
プ615)。
送信SI子テーブル登録されている応答メツセージのス
テータス情報が一致するか否かをチェックする(ステッ
プ615)。
一致の場合は、送信SI子テーブル該当する部分をリセ
ットしくステップ616)、さらに、ステップ607の
処理でセットしたリトライチェックモードを解除くリセ
ット)して(ステップ617)、リトライチェック処理
を終了する。
ットしくステップ616)、さらに、ステップ607の
処理でセットしたリトライチェックモードを解除くリセ
ット)して(ステップ617)、リトライチェック処理
を終了する。
一方、ステップ615の処理において、アクセス応答メ
ツセージ間でステータス情報が、それぞれ、OK、NG
と食い違っていれば、送信SI子テーブルリセットして
(ステップ618)、後述のリトライ処理(3)を実施
する(ステップ619)。
ツセージ間でステータス情報が、それぞれ、OK、NG
と食い違っていれば、送信SI子テーブルリセットして
(ステップ618)、後述のリトライ処理(3)を実施
する(ステップ619)。
また、ステップ614において、受信した応答メツセー
ジがリトライ処理(3)に対応するメッセ−ジであれば
、後述のリトライ処理(4)を行なう(ステップ620
)。
ジがリトライ処理(3)に対応するメッセ−ジであれば
、後述のリトライ処理(4)を行なう(ステップ620
)。
第6図(C)に基づき、木簡3の実施例におけるリトラ
イ処理(3)を説明する。
イ処理(3)を説明する。
このリトライ処理(3)では、以下の処理を行なう。
まず、優先ファイルからの応答の結果(OKまたはNG
)を判断する(ステップ621)。
)を判断する(ステップ621)。
優先ファイルからの応答がOKの場合には(ステップ6
22)、アクセス応答メツセージのトリガとなったコマ
ンドに対するアクセス依頼メツセージを、再度、第1図
の出力メツセージエリア105に格納して(ステップ6
23)、第1図の通信管理モジュール102による送出
に基づき、ステップ601からの受信メツセージの処理
を行なう。
22)、アクセス応答メツセージのトリガとなったコマ
ンドに対するアクセス依頼メツセージを、再度、第1図
の出力メツセージエリア105に格納して(ステップ6
23)、第1図の通信管理モジュール102による送出
に基づき、ステップ601からの受信メツセージの処理
を行なう。
一方、優先ファイルからの比容がNGの場合には、第2
図のステップ212の処理で説明したリトライ処理(1
)を行なう(ステップ624)、すなわち、アクセス応
答メツセージのトリガとなった発行コマンドに対する状
態解除コマンド(FREE、ERASE、CLOSE等
)のアクセス依頼メツセージを、第1図の出力メツセー
ジエリア105に格納し、第11!lの通信管理モジュ
ール102による送出に基づき、ステップ601からの
受信メツセージの処理を行なう。
図のステップ212の処理で説明したリトライ処理(1
)を行なう(ステップ624)、すなわち、アクセス応
答メツセージのトリガとなった発行コマンドに対する状
態解除コマンド(FREE、ERASE、CLOSE等
)のアクセス依頼メツセージを、第1図の出力メツセー
ジエリア105に格納し、第11!lの通信管理モジュ
ール102による送出に基づき、ステップ601からの
受信メツセージの処理を行なう。
このリトライ処理(3)により発生したリトライ処理依
頼メツセージに対する応答メツセージは、ステップ60
4、並びに、ステップ614で確認され、ステップ62
0のリトライ処理(4)を実行する。
頼メツセージに対する応答メツセージは、ステップ60
4、並びに、ステップ614で確認され、ステップ62
0のリトライ処理(4)を実行する。
第6WI(d)に基づき、第3の実施例におけるリトラ
イ処理(4)を説明する。
イ処理(4)を説明する。
まず、リトライ処理(3)における優先ファイルからの
応答がOKの時の応答メツセージの場合、すなわち、ス
テップ623の処理に対応する応答メツセージであり(
ステップ625)、かつ、アクセス応答メツセージのス
テータス情報がNGとなっていた全ファイルからの応答
メツセージのステータス情報がOKとなれば(ステップ
626)、ステップ607で設定したリトライチェック
モードを解除して(ステップ627)、処理を終了する
。
応答がOKの時の応答メツセージの場合、すなわち、ス
テップ623の処理に対応する応答メツセージであり(
ステップ625)、かつ、アクセス応答メツセージのス
テータス情報がNGとなっていた全ファイルからの応答
メツセージのステータス情報がOKとなれば(ステップ
626)、ステップ607で設定したリトライチェック
モードを解除して(ステップ627)、処理を終了する
。
全ファイルからの応答メツセージのステータス情報がO
Kでない場合は、ステップ623に進み、再アクセス依
頼メツセージを、もう−度、出力メツセージエリアに格
納する。
Kでない場合は、ステップ623に進み、再アクセス依
頼メツセージを、もう−度、出力メツセージエリアに格
納する。
一方、リトライ処理(3)における優先ファイルからの
応答がNGの時の応答メツセージの場合、すなわち、ス
テップ624の処理に対応する応答メツセージであり(
ステップ628)、状態解除依頼メツセージにより、ス
テータス情報がOKとなっていた全ファイルが解除され
れば(ステップ629)、ステップ607で設定したリ
トライチェックモードを解除しくステップ630)、第
2図におけ′るリトライ処理(2)を行なう(ステップ
631)、すなわ′ち、ファイルの不整合を引き起こし
た最初のアクセス依頼メツセージを、出力メツセージエ
リアに格納する。
応答がNGの時の応答メツセージの場合、すなわち、ス
テップ624の処理に対応する応答メツセージであり(
ステップ628)、状態解除依頼メツセージにより、ス
テータス情報がOKとなっていた全ファイルが解除され
れば(ステップ629)、ステップ607で設定したリ
トライチェックモードを解除しくステップ630)、第
2図におけ′るリトライ処理(2)を行なう(ステップ
631)、すなわ′ち、ファイルの不整合を引き起こし
た最初のアクセス依頼メツセージを、出力メツセージエ
リアに格納する。
また、ステップ629で、ステータス情報がOKとなっ
ていた全ファイルが解除されなければ、ステップ624
に進み一1再度、リトライ処理(1)を行なう。
ていた全ファイルが解除されなければ、ステップ624
に進み一1再度、リトライ処理(1)を行なう。
このように、第3の実施例によれば、ファイルの不整合
が発生した場合も、多重ファイル内容は、全て、優先フ
ァイル内容に一致し、ファイル間の整合性が保証できる
。さらに、優先ファイルの応答が戻ったタイミングで、
ユーザプログラムに制御を戻し、多重ファイルの整合性
チェックによる応答性の低下を防止する。
が発生した場合も、多重ファイル内容は、全て、優先フ
ァイル内容に一致し、ファイル間の整合性が保証できる
。さらに、優先ファイルの応答が戻ったタイミングで、
ユーザプログラムに制御を戻し、多重ファイルの整合性
チェックによる応答性の低下を防止する。
次に、この第3の実施例による分散処理システムの動作
を、タイミングチャートを用いて説明する。
を、タイミングチャートを用いて説明する。
第7図は、第4図)二おける送信S−エテーブルとファ
イル管理テーブルを有する分散処理システムの本発明に
係る□処理動作の一実施例の処理動作を示すタイムチャ
ートである。
イル管理テーブルを有する分散処理システムの本発明に
係る□処理動作の一実施例の処理動作を示すタイムチャ
ートである。
第7図(a)は、第1.第2の実施例によるタイムチャ
ートであり、第7図(b)は、第3の実施例によるタイ
ムチャートである。
ートであり、第7図(b)は、第3の実施例によるタイ
ムチャートである。
第1、および、第2の実施例では、第7図(a)に示す
ように、UPa13からの依頼メッセージ71に対する
ファイル(A)12.22からの応答(応答メツセージ
72.73)の両方が戻ったタイミング74でリトライ
チェック処理75を行ない、リトライチェック処理75
がOKであれば、UPa13への制御の戻し76を行な
う。
ように、UPa13からの依頼メッセージ71に対する
ファイル(A)12.22からの応答(応答メツセージ
72.73)の両方が戻ったタイミング74でリトライ
チェック処理75を行ない、リトライチェック処理75
がOKであれば、UPa13への制御の戻し76を行な
う。
これに対し、第3の実施例では、第7図(b)で示すよ
うに、まず、ファイル(A、)12を優先ファイルとす
る。そして、重篤3の実施例では、UPa13が発生し
た依頼メツセージ71に対する優先ファイル(A)12
からの応答メツセージ72が戻ってきたタイミング77
で、UPa13への制御の戻し78を行なう。
うに、まず、ファイル(A、)12を優先ファイルとす
る。そして、重篤3の実施例では、UPa13が発生し
た依頼メツセージ71に対する優先ファイル(A)12
からの応答メツセージ72が戻ってきたタイミング77
で、UPa13への制御の戻し78を行なう。
その後、ファイル(A)22からの応答メツセージ73
が戻ってきたタイミングでリトライチェック75を行な
う。
が戻ってきたタイミングでリトライチェック75を行な
う。
尚、リトライチェック75が終了する前に、UPa13
が発行したコマンド(WRITE)79は、リトライチ
ェック75終了後にアクセス依頼メツセージ70として
、ファイル(A)12.22に送出する。
が発行したコマンド(WRITE)79は、リトライチ
ェック75終了後にアクセス依頼メツセージ70として
、ファイル(A)12.22に送出する。
このように、第3の実施例によれば、優先ファイルであ
る自プロセッサのディスク内のファイルの応答メツセー
ジが戻ったタイミングで、ユーザプログラムに制御を戻
し、多重ファイルの整合性チェックによる応答性の低下
を防止する。
る自プロセッサのディスク内のファイルの応答メツセー
ジが戻ったタイミングで、ユーザプログラムに制御を戻
し、多重ファイルの整合性チェックによる応答性の低下
を防止する。
尚、第3の実施例で示した多重ファイルからの応答メツ
セージのチェック方法、すなわち、まず、先着メツセー
ジをユーザプログラムに渡し、後着メツセージの受信時
に、先着メツセージとの整合性のチェックを行なう方法
は、プログラム、プリンタなどの各種資源を多重化した
場合にも、同様に、適用可能である。
セージのチェック方法、すなわち、まず、先着メツセー
ジをユーザプログラムに渡し、後着メツセージの受信時
に、先着メツセージとの整合性のチェックを行なう方法
は、プログラム、プリンタなどの各種資源を多重化した
場合にも、同様に、適用可能である。
以上、第1〜第7図を用いて説明したように、本第1〜
第3の実施例によれば、多重ファイルの不整合が発生し
た場合においても、その不整合を自動的に解除すること
ができる。
第3の実施例によれば、多重ファイルの不整合が発生し
た場合においても、その不整合を自動的に解除すること
ができる。
さらに、最初に受信したファイルの応答メツセージで、
ユーザプログラムに制御を戻し、その後で、ファイルの
整合性をチェックする。このことにより、多重ファイル
の整合性チェックによる応答性の低下を防止する。
ユーザプログラムに制御を戻し、その後で、ファイルの
整合性をチェックする。このことにより、多重ファイル
の整合性チェックによる応答性の低下を防止する。
尚、第1〜3の実施例で行なうリトライチェックは、フ
ァイル更新時に必要なチェックであり、例えば、rRE
AD 0NLYJのモードでオープンしている場合は
不要である。従って、ファイルオープンモードを判定し
、更新モードでオープンされていない場合は、第1図の
クライアントファイル管理モジュール106で、リトラ
イチェック処理を行なわず、先に受信したアクセス応答
メツセージを、受信したタイミングで、ユーザプログラ
ムに渡してしまう方法を取ることも可能である。この際
、後から受信したアクセス応答メツセージに対しては、
これを識別し、廃棄する処理を取る。この方法により、
ファイル更新モード以外でアクセスする場合の応答性を
向上させることができる。
ァイル更新時に必要なチェックであり、例えば、rRE
AD 0NLYJのモードでオープンしている場合は
不要である。従って、ファイルオープンモードを判定し
、更新モードでオープンされていない場合は、第1図の
クライアントファイル管理モジュール106で、リトラ
イチェック処理を行なわず、先に受信したアクセス応答
メツセージを、受信したタイミングで、ユーザプログラ
ムに渡してしまう方法を取ることも可能である。この際
、後から受信したアクセス応答メツセージに対しては、
これを識別し、廃棄する処理を取る。この方法により、
ファイル更新モード以外でアクセスする場合の応答性を
向上させることができる。
このように、特に第3の実施例によれば、多重ファイル
間に発生する不整合状態を、ファイルアクセス応答を低
下させることなくチェックし、不整合状態発生時には、
ユーザプログラム側に、それを意識させることなく、自
動的に、その不整合状態を解消することが可能となる。
間に発生する不整合状態を、ファイルアクセス応答を低
下させることなくチェックし、不整合状態発生時には、
ユーザプログラム側に、それを意識させることなく、自
動的に、その不整合状態を解消することが可能となる。
このことにより1重要なファイルを任意の多重度で多重
化でき、しかも、その際、アクセス応答性が低下するこ
とがないため、ファイルの信頼性が向上するのみでなく
、ユーザに取っての使い勝手も向上する。
化でき、しかも、その際、アクセス応答性が低下するこ
とがないため、ファイルの信頼性が向上するのみでなく
、ユーザに取っての使い勝手も向上する。
【発明の効果]
本発明によれば、任意の多重度に多重化された多重ファ
イルに対し、多重ファイル間に不整合が発生した場合で
も、ファイルアクセスもている処理を中断することなく
、不整合状態を自動的に回復し、かつ、多重フ′アイル
間に発生する不整合状態の検出処理を、ファイルアクセ
ス応答性能を低下させることなく行ない、分散処理シス
テムの処理性能と信頼性を向上させることが可能である
。
イルに対し、多重ファイル間に不整合が発生した場合で
も、ファイルアクセスもている処理を中断することなく
、不整合状態を自動的に回復し、かつ、多重フ′アイル
間に発生する不整合状態の検出処理を、ファイルアクセ
ス応答性能を低下させることなく行ない、分散処理シス
テムの処理性能と信頼性を向上させることが可能である
。
第1図は本発明を施した分散処理システムの本発明に係
る構成の第1の実施例を示すブロック図、第2図は第1
図における分散処理システムの本発明に係る処理動作の
第1の実施例を示すフローチャート、第3図は第1図に
おける分散処理システムの本発明に係る処理動作の一実
施例を示すタイムチャート、第4図は第1図における送
信SI子テーブルよびファイル管理テーブルの構成の第
2の実施例を示す説明図、第5図は第1図における分散
処理システムの本発明に係る処理動作の第2の実施例を
示すフローチャート、第6FMは第1図における分散処
理システムの本発明に係る処理の第3の実施例を示すフ
ローチャート、第7図は第4!11における送信SI子
テーブルファイル管理テーブルを有する分散処理システ
ムの本発明に係る処理動作の一実施例の処理動作を示す
タイムチャートである、 1〜3:プロセッサ、4:ネットワーク、5:メッセー
ジ、10:ターミナル、11:ディスク。 12:ファイル(A)、13ニユーザブログラム(UP
a)、20:ターミナル、21:ディスク。 22:ファイル(A)、23ニユーザブログラム(UP
b)、30:ターミナル、31:ディスク。 51:フラグ、52二内容コード、53:発生源アドレ
ス、54:通番、55:発生源情報、56:データ部、
57:FC3,58:フラグ、70:アクセス依頼メツ
セージ、71:依頼メツセージ。 72〜73;応答メツセージ、74:タイミング。 75:リトライチェック処理、76:戻し制御。 77:タイミング、78:戻し制御、79:コマンド(
WRITE)、l 01 :ネットワークインタフェー
ス、102:通信管理モジュール、 103:内容コ
ードテーブル、104:入カメッセージエリア、105
:出力メッセージエリア、106:クライアントファイ
ル管理モジュール、107:送信SI子テーブル108
ニユーザブログラム実行エリア、109:サーバファイ
ル管理モジュール、110:ファイル管理テーブル、1
11:ディスクインタフェース、 3OO:ファイルア
クセスコマンド(READ)、 301 :アクセス依
頼メツセージ(READ)、302〜303:ステータ
ス情報、304:リトライ処理(1)、305:解除依
頼メツセージ(FREE)、306〜307:応答メツ
セージ、308:リトライ処理(2)。 309:アクセス依頼メツセージ(READ)。 320:ファイルアクセスコマンド(READ)。 321:アクセス依頼メツセージ(READ)。 322〜323:ステータス情報、324:リトライ処
理(1)、325:解除依頼メツセージ(FREE)、
326〜327:応答メツセージ。 328:リトライ処理(2)、329:アクセス依頼メ
ツセージ(READ)、400〜401:多重度エリア
、407:送信SI子テーブル410:ファイル管理テ
ーブル、521:ファイルネーム部、522:ID部、
551:プロセッサ番号情報部、552:タスク番号情
報部、553:通番情報部、1071〜1072:行、
1101〜1102:行、4071〜4072:行、4
101〜4102:行、10711:*先駆情報エリア
。 10712:タイマエリア、10713:個数エリア、
10714:受信メツセージエリア、11011:ファ
イルネームエリア11012:物理情報エリア、110
131生源情報エリア。 第4図 fa) 第 5 図 第 6 図(その3) (c) 第 6 図(その4) (d) 第 7 図(その1) (a] 第 7 図(その2) fb)
る構成の第1の実施例を示すブロック図、第2図は第1
図における分散処理システムの本発明に係る処理動作の
第1の実施例を示すフローチャート、第3図は第1図に
おける分散処理システムの本発明に係る処理動作の一実
施例を示すタイムチャート、第4図は第1図における送
信SI子テーブルよびファイル管理テーブルの構成の第
2の実施例を示す説明図、第5図は第1図における分散
処理システムの本発明に係る処理動作の第2の実施例を
示すフローチャート、第6FMは第1図における分散処
理システムの本発明に係る処理の第3の実施例を示すフ
ローチャート、第7図は第4!11における送信SI子
テーブルファイル管理テーブルを有する分散処理システ
ムの本発明に係る処理動作の一実施例の処理動作を示す
タイムチャートである、 1〜3:プロセッサ、4:ネットワーク、5:メッセー
ジ、10:ターミナル、11:ディスク。 12:ファイル(A)、13ニユーザブログラム(UP
a)、20:ターミナル、21:ディスク。 22:ファイル(A)、23ニユーザブログラム(UP
b)、30:ターミナル、31:ディスク。 51:フラグ、52二内容コード、53:発生源アドレ
ス、54:通番、55:発生源情報、56:データ部、
57:FC3,58:フラグ、70:アクセス依頼メツ
セージ、71:依頼メツセージ。 72〜73;応答メツセージ、74:タイミング。 75:リトライチェック処理、76:戻し制御。 77:タイミング、78:戻し制御、79:コマンド(
WRITE)、l 01 :ネットワークインタフェー
ス、102:通信管理モジュール、 103:内容コ
ードテーブル、104:入カメッセージエリア、105
:出力メッセージエリア、106:クライアントファイ
ル管理モジュール、107:送信SI子テーブル108
ニユーザブログラム実行エリア、109:サーバファイ
ル管理モジュール、110:ファイル管理テーブル、1
11:ディスクインタフェース、 3OO:ファイルア
クセスコマンド(READ)、 301 :アクセス依
頼メツセージ(READ)、302〜303:ステータ
ス情報、304:リトライ処理(1)、305:解除依
頼メツセージ(FREE)、306〜307:応答メツ
セージ、308:リトライ処理(2)。 309:アクセス依頼メツセージ(READ)。 320:ファイルアクセスコマンド(READ)。 321:アクセス依頼メツセージ(READ)。 322〜323:ステータス情報、324:リトライ処
理(1)、325:解除依頼メツセージ(FREE)、
326〜327:応答メツセージ。 328:リトライ処理(2)、329:アクセス依頼メ
ツセージ(READ)、400〜401:多重度エリア
、407:送信SI子テーブル410:ファイル管理テ
ーブル、521:ファイルネーム部、522:ID部、
551:プロセッサ番号情報部、552:タスク番号情
報部、553:通番情報部、1071〜1072:行、
1101〜1102:行、4071〜4072:行、4
101〜4102:行、10711:*先駆情報エリア
。 10712:タイマエリア、10713:個数エリア、
10714:受信メツセージエリア、11011:ファ
イルネームエリア11012:物理情報エリア、110
131生源情報エリア。 第4図 fa) 第 5 図 第 6 図(その3) (c) 第 6 図(その4) (d) 第 7 図(その1) (a] 第 7 図(その2) fb)
Claims (1)
- 【特許請求の範囲】 1、複数のプロセッサを共通伝送媒体を介して接続し、
上記複数のプロセッサは、それぞれのプロセッサに多重
に配置したリソースから発生する多重データを用いて処
理を進める分散処理システムの多重データ処理方法にお
いて、上記複数のプロセッサは、上記多重データの最初
に受信したデータを用いて上記処理を進め、以後受信し
た多重データを用いて、上記最初に受信したデータの整
合性のチェックを行なうことを特徴とする分散処理シス
テムの多重データ処理方法。 2、請求項1に記載の分散処理システムの多重データ処
理方法において、上記複数のプロセッサのそれぞれに接
続した外部記憶媒体のそれぞれにファイルを多重に配置
し、上記複数のプロセッサの任意のプロセッサは、該多
重に配置したファイルに対するアクセス依頼を発生し、
かつ、該アクセス依頼に対応する上記多重に配置したフ
ァイルからの多重応答データを受信し、そして、該多重
応答データの最初に受信した応答データを用いて上記処
理を進め、以後受信した多重応答データを用いて、上記
最初に受信した応答データの整合性のチェックを行なう
ことを特徴とする分散処理システムの多重データ処理方
法。 3、請求項2に記載の分散処理システムの多重データ処
理方法において、上記アクセス依頼を発生したプロセッ
サは、上記多重応答データ間のチェックが終了するまで
、次のファイルアクセス依頼を発生しないことを特徴と
する分散処理システムの多重データ処理方法。 4、請求項3に記載の分散処理システムの多重データ処
理方法において、上記応答データの整合性のチェックで
、上記応答データ間に不整合を検出した場合は、上記ア
クセス依頼を発生したプロセッサは、上記アクセス依頼
により生じたファイル状態を解除する命令を発行する第
1のリトライ処理を行ない、該第1のリトライ処理によ
る上記ファイル状態の解除後、再び、上記アクセス依頼
を発生する第2のリトライ処理を行ない、上記応答デー
タ間の不整合がなくなるまで、上記第1のリトライ処理
、および、第2のリトライ処理を繰り返すことを特徴と
する分散処理システムの多重データ処理方法。 5、請求項4に記載の分散処理システムの多重データ処
理方法において、上記アクセス依頼を発生したプロセッ
サは、上記第1のリトライ処理後、上記第2のリトライ
処理を、予め設定された任意の時間ずらして実行するこ
とを特徴とする分散処理システムの多重データ処理方法
。 6、請求項4、もしくは、請求項5のいずれかに記載の
分散処理システムの多重データ処理方法において、上記
アクセス依頼を発生したプロセッサは、上記多重ファイ
ルからの全応答データを収集して、該収集した全応答デ
ータ間の整合性のチェック、および、上記第1のリトラ
イ処理と第2のリトライ処理による上記応答データ間の
整合性の確定後に、上記処理を行なうことを特徴とする
分散処理システムの多重データ処理方法。 7、請求項4〜6のいずれか一つに記載の分散処理シス
テムの多重データ処理方法において、上記アクセス依頼
を発生したプロセッサは、予め任意に設定した時間内に
収集した上記多重ファイルからの全応答データ間の整合
性のチェックに基づき、上記第1のリトライ処理、およ
び、第2のリトライ処理を行なうことを特徴とする分散
処理システムの多重データ処理方法。 8、請求項7に記載の分散処理システムの多重データ処
理方法において、上記アクセス依頼を発生したプロセッ
サは、上記予め任意に設定した時間内に、上記多重ファ
イルからの全応答データを収集できない場合、上記予め
任意に設定した時間内に収集した応答データを、上記整
合性のチェックの対象に限定する障害処理を行ない、該
障害処理の後に、上記整合性のチェック、および、上記
第1のリトライ処理と第2のリトライ処理を行なうこと
を特徴とする分散処理システムの多重データ処理方法。 9、請求項4に記載の分散処理システムの多重データ処
理方法において、上記アクセス依頼を発生したプロセッ
サは、上記第1のリトライ処理として、上記アクセス依
頼がファイル更新時のリードコマンドの場合は、該リー
ドコマンドの排他管理によるレコードの占有状態を解除
するフリーコマンドを、上記アクセス依頼が追加コマン
ドの場合は、該追加コマンドにより追加したレコードを
削除するイレースコマンドを、上記アクセス依頼が排他
オープンコマンドの場合は、該排他オープンコマンドに
よるファイルの占有状態を解除するクローズコマンドを
発行することを特徴とする分散処理システムの多重デー
タ処理方法。 10、請求項4〜6のそれぞれに記載の分散処理システ
ムの多重データ処理方法において、上記複数のプロセッ
サは、アクセス依頼メッセージ、および、アクセス応答
メッセージのメッセージを上記上記伝送媒体へブロード
キャストし、該メッセージのやり取りにより分散処理を
行ない、上記複数のプロセッサのそれぞれは、自プロセ
ッサから他プロセッサへの上記メッセージの上記伝送媒
体へのブロードキャスト、および、上記伝送媒体へブロ
ードキャストされた上記メッセージから、自プロセッサ
に関連するメッセージの取り込みを行なう通信管理モジ
ュールと、該通信管理モジュールで取り込んだ上記メッ
セージを、該メッセージを処理するユーザプログラムに
渡し、かつ、該ユーザプログラムからのファイルアクセ
ス命令に基づき、上記アクセス依頼メッセージを生成し
、上記通信管理モジュールに送出するクライアントファ
イル管理モジュールと、該クライアントファイル管理モ
ジュールが上記通信管理モジュールに送出したメッセー
ジ情報を格納する送信情報格納手段とを有し、上記アク
セス依頼を発生したプロセッサは、上記クライアントフ
ァイル管理モジュールを用いて、上記通信管理モジュー
ルを介して上記伝送媒体に上記メッセージを送出すると
同時に、上記整合性のチェックに用いる予め任意に設定
した収集時間を上記送信情報格納手段に格納し、そして
、該送信情報格納手段に格納した時間に基づき、上記多
重ファイルからの全応答データ間の整合性のチェック、
および、上記第1のリトライ処理と第2のリトライ処理
を行なうことを特徴とする分散処理システムの多重デー
タ処理方法。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP28377790A JP3516344B2 (ja) | 1990-10-22 | 1990-10-22 | 分散処理システムの多重データ処理方法 |
EP91117995A EP0482582B1 (en) | 1990-10-22 | 1991-10-22 | Apparatus and method for processing replicated data in a distributed processing system |
DE69130014T DE69130014T2 (de) | 1990-10-22 | 1991-10-22 | Vorrichtung and Verfahren zur Verarbeitung replizierter Daten in einem verteilten Datenverarbeitungssystem |
US07/780,337 US5333265A (en) | 1990-10-22 | 1991-10-22 | Replicated data processing method in distributed processing system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP28377790A JP3516344B2 (ja) | 1990-10-22 | 1990-10-22 | 分散処理システムの多重データ処理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH04157541A true JPH04157541A (ja) | 1992-05-29 |
JP3516344B2 JP3516344B2 (ja) | 2004-04-05 |
Family
ID=17669992
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP28377790A Expired - Fee Related JP3516344B2 (ja) | 1990-10-22 | 1990-10-22 | 分散処理システムの多重データ処理方法 |
Country Status (4)
Country | Link |
---|---|
US (1) | US5333265A (ja) |
EP (1) | EP0482582B1 (ja) |
JP (1) | JP3516344B2 (ja) |
DE (1) | DE69130014T2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012027933A (ja) * | 2003-10-27 | 2012-02-09 | Archivas Inc | 独立ノード冗長アレイに対するポリシーに基づく管理 |
Families Citing this family (64)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7299240B1 (en) | 1992-04-10 | 2007-11-20 | Intellisync Corporation | Method for translating computer data from one record structure to another |
US5710922A (en) * | 1993-06-02 | 1998-01-20 | Apple Computer, Inc. | Method for synchronizing and archiving information between computer systems |
CA2172517C (en) * | 1993-09-24 | 2000-02-15 | Sandeep Jain | Method and apparatus for data replication |
GB2284494B (en) * | 1993-11-26 | 1998-09-09 | Hitachi Ltd | Distributed shared memory management system |
US5588147A (en) * | 1994-01-14 | 1996-12-24 | Microsoft Corporation | Replication facility |
US5796999A (en) * | 1994-04-15 | 1998-08-18 | International Business Machines Corporation | Method and system for selectable consistency level maintenance in a resilent database system |
EP0678812A1 (en) * | 1994-04-20 | 1995-10-25 | Microsoft Corporation | Replication verification |
US5434994A (en) * | 1994-05-23 | 1995-07-18 | International Business Machines Corporation | System and method for maintaining replicated data coherency in a data processing system |
US5699511A (en) * | 1995-10-10 | 1997-12-16 | International Business Machines Corporation | System and method for dynamically varying low level file system operation timeout parameters in network systems of variable bandwidth |
US5787304A (en) * | 1996-02-05 | 1998-07-28 | International Business Machines Corporation | Multipath I/O storage systems with multipath I/O request mechanisms |
US5764634A (en) * | 1996-03-13 | 1998-06-09 | International Business Machines Corporation | Lan switch with zero latency |
US6412017B1 (en) | 1996-07-01 | 2002-06-25 | Microsoft Corporation | Urgent replication facility |
US5781910A (en) * | 1996-09-13 | 1998-07-14 | Stratus Computer, Inc. | Preforming concurrent transactions in a replicated database environment |
US6049809A (en) * | 1996-10-30 | 2000-04-11 | Microsoft Corporation | Replication optimization system and method |
US6141664A (en) | 1996-11-13 | 2000-10-31 | Puma Technology, Inc. | Synchronization of databases with date range |
US7302446B1 (en) | 1996-11-13 | 2007-11-27 | Intellisync Corporation | Synchronizing databases |
US7013315B1 (en) | 1996-11-13 | 2006-03-14 | Intellisync Corporation | Synchronization of databases with record sanitizing and intelligent comparison |
US5943676A (en) | 1996-11-13 | 1999-08-24 | Puma Technology, Inc. | Synchronization of recurring records in incompatible databases |
US6212529B1 (en) | 1996-11-13 | 2001-04-03 | Puma Technology, Inc. | Synchronization of databases using filters |
US6330568B1 (en) | 1996-11-13 | 2001-12-11 | Pumatech, Inc. | Synchronization of databases |
US6405218B1 (en) | 1996-11-13 | 2002-06-11 | Pumatech, Inc. | Synchronizing databases |
US6044381A (en) * | 1997-09-11 | 2000-03-28 | Puma Technology, Inc. | Using distributed history files in synchronizing databases |
US6925477B1 (en) | 1998-03-31 | 2005-08-02 | Intellisync Corporation | Transferring records between two databases |
US7007003B1 (en) | 1998-12-04 | 2006-02-28 | Intellisync Corporation | Notification protocol for establishing synchronization mode for use in synchronizing databases |
US6279026B1 (en) * | 1998-12-04 | 2001-08-21 | Honeywell International Inc | Timeout object for object-oriented, real-time process control system and method of operation thereof |
US6484220B1 (en) * | 1999-08-26 | 2002-11-19 | International Business Machines Corporation | Transfer of data between processors in a multi-processor system |
US6820213B1 (en) | 2000-04-13 | 2004-11-16 | Stratus Technologies Bermuda, Ltd. | Fault-tolerant computer system with voter delay buffer |
US6687851B1 (en) | 2000-04-13 | 2004-02-03 | Stratus Technologies Bermuda Ltd. | Method and system for upgrading fault-tolerant systems |
US6802022B1 (en) | 2000-04-14 | 2004-10-05 | Stratus Technologies Bermuda Ltd. | Maintenance of consistent, redundant mass storage images |
US6901481B2 (en) | 2000-04-14 | 2005-05-31 | Stratus Technologies Bermuda Ltd. | Method and apparatus for storing transactional information in persistent memory |
US6691225B1 (en) | 2000-04-14 | 2004-02-10 | Stratus Technologies Bermuda Ltd. | Method and apparatus for deterministically booting a computer system having redundant components |
JP4497691B2 (ja) * | 2000-09-27 | 2010-07-07 | 株式会社日立製作所 | データベース管理方法及び管理システム |
US7359920B1 (en) | 2001-04-18 | 2008-04-15 | Intellisync Corporation | Communication protocol for synchronization of personal information management databases |
US7334004B2 (en) * | 2001-06-01 | 2008-02-19 | Oracle International Corporation | Consistent read in a distributed database environment |
WO2003017114A1 (en) * | 2001-08-20 | 2003-02-27 | Gausa, Llc | System and method for real-time multi-directional file-based data streaming editor |
US7149759B2 (en) | 2002-03-25 | 2006-12-12 | International Business Machines Corporation | Method and system for detecting conflicts in replicated data in a database network |
US8311974B2 (en) * | 2004-02-20 | 2012-11-13 | Oracle International Corporation | Modularized extraction, transformation, and loading for a database |
US7444197B2 (en) * | 2004-05-06 | 2008-10-28 | Smp Logic Systems Llc | Methods, systems, and software program for validation and monitoring of pharmaceutical manufacturing processes |
US7346633B2 (en) * | 2004-06-10 | 2008-03-18 | Sybase, Inc. | System providing methodology for replication subscription resolution |
US7496787B2 (en) * | 2004-12-27 | 2009-02-24 | Stratus Technologies Bermuda Ltd. | Systems and methods for checkpointing |
US20070028144A1 (en) * | 2005-07-29 | 2007-02-01 | Stratus Technologies Bermuda Ltd. | Systems and methods for checkpointing |
US20070038891A1 (en) * | 2005-08-12 | 2007-02-15 | Stratus Technologies Bermuda Ltd. | Hardware checkpointing system |
US8868504B2 (en) | 2007-03-07 | 2014-10-21 | Oracle International Corporation | Database system with active standby and nodes |
US7991775B2 (en) | 2008-08-08 | 2011-08-02 | Oracle International Corporation | Global checkpoint SCN |
US8838919B2 (en) | 2010-08-30 | 2014-09-16 | Oracle International Corporation | Controlling data lag in a replicated computer system |
US8589361B2 (en) | 2010-08-30 | 2013-11-19 | Oracle International Corporation | Reduced disk space standby |
US8868492B2 (en) | 2011-06-15 | 2014-10-21 | Oracle International Corporation | Method for maximizing throughput and minimizing transactions response times on the primary system in the presence of a zero data loss standby replica |
US9251002B2 (en) | 2013-01-15 | 2016-02-02 | Stratus Technologies Bermuda Ltd. | System and method for writing checkpointing data |
US9767178B2 (en) | 2013-10-30 | 2017-09-19 | Oracle International Corporation | Multi-instance redo apply |
ES2652262T3 (es) | 2013-12-30 | 2018-02-01 | Stratus Technologies Bermuda Ltd. | Método de retardar puntos de comprobación inspeccionando paquetes de red |
WO2015102875A1 (en) | 2013-12-30 | 2015-07-09 | Stratus Technologies Bermuda Ltd. | Checkpointing systems and methods of using data forwarding |
US9652338B2 (en) | 2013-12-30 | 2017-05-16 | Stratus Technologies Bermuda Ltd. | Dynamic checkpointing systems and methods |
US10747752B2 (en) | 2015-10-23 | 2020-08-18 | Oracle International Corporation | Space management for transactional consistency of in-memory objects on a standby database |
US11657037B2 (en) | 2015-10-23 | 2023-05-23 | Oracle International Corporation | Query execution against an in-memory standby database |
US10698771B2 (en) | 2016-09-15 | 2020-06-30 | Oracle International Corporation | Zero-data-loss with asynchronous redo shipping to a standby database |
US10891291B2 (en) | 2016-10-31 | 2021-01-12 | Oracle International Corporation | Facilitating operations on pluggable databases using separate logical timestamp services |
US11475006B2 (en) | 2016-12-02 | 2022-10-18 | Oracle International Corporation | Query and change propagation scheduling for heterogeneous database systems |
US10803039B2 (en) | 2017-05-26 | 2020-10-13 | Oracle International Corporation | Method for efficient primary key based queries using atomic RDMA reads on cache friendly in-memory hash index |
US10691722B2 (en) | 2017-05-31 | 2020-06-23 | Oracle International Corporation | Consistent query execution for big data analytics in a hybrid database |
US10719446B2 (en) | 2017-08-31 | 2020-07-21 | Oracle International Corporation | Directly mapped buffer cache on non-volatile memory |
US10956335B2 (en) | 2017-09-29 | 2021-03-23 | Oracle International Corporation | Non-volatile cache access using RDMA |
US11086876B2 (en) | 2017-09-29 | 2021-08-10 | Oracle International Corporation | Storing derived summaries on persistent memory of a storage device |
US10802766B2 (en) | 2017-09-29 | 2020-10-13 | Oracle International Corporation | Database with NVDIMM as persistent storage |
US10732836B2 (en) | 2017-09-29 | 2020-08-04 | Oracle International Corporation | Remote one-sided persistent writes |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4224664A (en) * | 1976-05-07 | 1980-09-23 | Honeywell Information Systems Inc. | Apparatus for detecting when the activity of one process in relation to a common piece of information interferes with any other process in a multiprogramming/multiprocessing computer system |
US4270168A (en) * | 1978-08-31 | 1981-05-26 | United Technologies Corporation | Selective disablement in fail-operational, fail-safe multi-computer control system |
US4342083A (en) * | 1980-02-05 | 1982-07-27 | The Bendix Corporation | Communication system for a multiple-computer system |
US4627019A (en) * | 1982-07-08 | 1986-12-02 | At&T Bell Laboratories | Database management system for controlling concurrent access to a database |
US5056003A (en) * | 1985-06-17 | 1991-10-08 | International Business Machines Corporation | Distributed data management mechanism |
JPS63100562A (ja) * | 1986-10-17 | 1988-05-02 | Hitachi Ltd | フアイルシステム管理方式 |
DE3639055C2 (de) * | 1986-11-14 | 1998-02-05 | Bosch Gmbh Robert | Verfahren zur Betriebsüberwachung und Fehlerkorrektur von Rechnern eines Mehrrechnersystems und Mehrrechnersystem |
US4881166A (en) * | 1987-07-24 | 1989-11-14 | Amoco Corporation | Method for consistent multidatabase transaction processing |
US4912707A (en) * | 1988-08-23 | 1990-03-27 | International Business Machines Corporation | Checkpoint retry mechanism |
JP2804046B2 (ja) * | 1988-08-26 | 1998-09-24 | 株式会社日立製作所 | 分散処理システムのデータ整合化方法 |
US5136707A (en) * | 1988-10-28 | 1992-08-04 | At&T Bell Laboratories | Reliable database administration arrangement |
US5095421A (en) * | 1989-08-17 | 1992-03-10 | International Business Machines Corporation | Transaction processing facility within an operating system environment |
US5170480A (en) * | 1989-09-25 | 1992-12-08 | International Business Machines Corporation | Concurrently applying redo records to backup database in a log sequence using single queue server per queue at a time |
US5062045A (en) * | 1990-02-23 | 1991-10-29 | International Business Machines Corporation | System for maintaining a document and activity selective alterable document history log in a data processing system |
-
1990
- 1990-10-22 JP JP28377790A patent/JP3516344B2/ja not_active Expired - Fee Related
-
1991
- 1991-10-22 EP EP91117995A patent/EP0482582B1/en not_active Expired - Lifetime
- 1991-10-22 US US07/780,337 patent/US5333265A/en not_active Expired - Lifetime
- 1991-10-22 DE DE69130014T patent/DE69130014T2/de not_active Expired - Fee Related
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012027933A (ja) * | 2003-10-27 | 2012-02-09 | Archivas Inc | 独立ノード冗長アレイに対するポリシーに基づく管理 |
Also Published As
Publication number | Publication date |
---|---|
EP0482582A3 (ja) | 1994-04-20 |
US5333265A (en) | 1994-07-26 |
JP3516344B2 (ja) | 2004-04-05 |
EP0482582A2 (en) | 1992-04-29 |
DE69130014D1 (de) | 1998-09-24 |
EP0482582B1 (en) | 1998-08-19 |
DE69130014T2 (de) | 1999-04-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JPH04157541A (ja) | 分散処理システムの多重データ処理方法 | |
US8364726B2 (en) | Methods and apparatus facilitating access to storage among multiple computers | |
JP4107083B2 (ja) | 高可用ディスク制御装置とその障害処理方法及び高可用ディスクサブシステム | |
US6757782B2 (en) | Disk array and method for reading/writing data from/into disk unit | |
US6839804B2 (en) | Disk array storage device with means for enhancing host application performance using task priorities | |
US20140149783A1 (en) | Methods and apparatus facilitating access to storage among multiple computers | |
US7069305B2 (en) | Computer system and a data transfer method thereof using remote direct memory access | |
CN111130896A (zh) | 一种nfs故障的切换方法、系统及双控存储系统 | |
US7359833B2 (en) | Information processing system and method | |
JP3006491B2 (ja) | トランザクション実行状態管理システム、管理方法、および管理プログラムを記憶する媒体 | |
JP2000267703A (ja) | プログラマブルコントローラ | |
JPH04239239A (ja) | データ収集システム | |
JPS6239789B2 (ja) | ||
JPH0449146B2 (ja) | ||
JP4048037B2 (ja) | データ書出プログラムおよび記録媒体 | |
JPH09288608A (ja) | 分散処理システムにおけるファイル共用制御装置 | |
KR100502501B1 (ko) | 데이터베이스 시스템의 실시간 원격 로깅 및 복구 방법 | |
JP2784520B2 (ja) | ファイル転送装置 | |
JPH0496830A (ja) | 分散処理システムにおけるデータ管理方法 | |
JP6100135B2 (ja) | フォールトトレラントシステム及びフォールトトレラントシステム制御方法 | |
JP2912046B2 (ja) | ファイルサーバの制御方法 | |
JP2000047986A (ja) | トランザクション処理システム | |
JP3664139B2 (ja) | Scsiインタフェース制御装置のリトライ処理方式 | |
JPH11212917A (ja) | トランザクションリカバリ方式およびそのプログラム記録媒体 | |
JPS6059612B2 (ja) | 二重化ファイルの管理方式 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20031222 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040116 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080130 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090130 Year of fee payment: 5 |
|
LAPS | Cancellation because of no payment of annual fees |