JPH0277868A - 共用データの管理方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、複数のデータ処理装置が拡張記憶装置および
ファイル装置を共有する形態のマルチプロセサにおける
データベース共用方法に関し、特配データ資源の整合性
を保証しながら効率的なアクセスを行うための共用デー
タアクセス制御方法に関するものである。

〔従来の技術〕

複数のデータ処理装置が、主記憶を共用せずファイル装
置を共用する、いわゆる疎結合マルチプロセサシステム
において、共用データ資源に対するアクセスを制御する
方法としては、例えば、特開昭６２−１４５３４９号公
報に記載されているように、複数のデータ処理装置を通
信装置で結合し、各々の共用データ資源ごとに定められ
た排他マスクのデータ処理装置上のロックマネジャにロ
ック要求を送信して排他制御を行う方法が知られている
。また、上記公知例では、あるデータ処理装置が故障し
た場合、故障したデータ処理装置がマスクであった共用
データ資源に関して、別個のデータ処理装置が新たなマ
スクとなってシステムの運転を続行する方法が示されて
いる。

疎結合マルチプロセサにおいて、データ処理装置間の通
信により共用データ資源の排他制御を実現する第２の方
法は、特開昭５８−１７２７６４号公報に記載されてい
る。この公知例では、ロックマネジャは、ロック要求を
データ処理装置間で回覧し、全データ処理装置の過半数
の承認が得られた時点でそのロック要求を有効とする多
数決方式によってデータ処理装置間での排他制御を行っ
ている。

また、複数データ処理装置間の排他制御を実行するため
の特別の制御装置を設ける方法が特開昭５９−８１７４
８号公報に記載されている。この第３の公知例では、各
データ処理装置は、上記特別の制御装置に対してロック
またはアンロック命令を発行する。この方法では、排他
制御をデータ処理装置とは別の単一の制御装置によって
行うため、データ処理装置の排他制御オーバヘッドを削
減でき、また複数データ処理装置にまたがったデッドロ
ックの検出を容易に行える。

〔発明が解決しようとする課題〕

疎結合マルチプロセサにおいて、共用データ資源に対す
るアクセスの排他制御を行う場合、最大の問題となるの
は通信オーバヘッドである。上記第１および第２の公知
例においては、通信装置で結合されたデータ処理装置間
の排他制御情報の通信オーバヘッドが、また第３の公知
例においては、データ処理装置と排他制御用の専用制御
装置との間の排他制御情報の通信オーバヘッドがそれぞ
れ問題となる。また、上記第１および第２の公知例にお
いては、ロックの待ちを各データ処理装置で分散して管
理するため、データ処理装置間にロック待ちのループが
またがったようないわゆるグローバルデッドロックを検
出するためには、ロック待ちの情報をデータ処理装置間
でやりとりしなければならず、大きな通信オーバヘッド
が発生する。

また、上記第１の公知例においては、データ処理装置が
故障して別のデータ処理装置にマスク権限を委譲する場
合に、ロックマネジャ間での通信が必要となる。また、
各々のサブシステムは、ファイル装置へのアクセス回数
を削減するためにバッファプールを設けてバッファリン
グを行っているが、それらのバッファプール中に記憶さ
れるデータの整合性を保持するために、サブシステム間
でデータの更新発生の同期をとる通信が必要となる。

さらに、共用のファイル装置が故障した場合、各々のサ
ブシステムがデータの更新を記録したジャーナル情報を
時系列に並べて、ファイル内容のバックアップコピーと
マージする必要があるが、全サブシステムに共通の一意
的な時系列順を与えるためにデータ処理装置間の通信が
必要となる。上記第３の公知例においては、ロック情報
を特別の制御装置で集中して管理するため、上記の余分
な通信オーバヘッドはかなり削減されるが、特殊なハー
ドウェアが必要であり、この制御装置がシステム全体の
性能、信頼性、拡張性および経済性のボトルネックとな
る可能性がある。

また、主記憶−２次記憶という従来のコンピュータシス
テムの記憶階層に加えて、主記憶とほぼ同列に位置し、
かつ複数データ処理装置間で共用可能な拡張記憶装置が
実現されるようになってきた。拡張記憶装置は、コンピ
ュータシステムで一般的に使用可能な記憶装置であり、
経済性も高い。

しかし、上記公知例においては、この共用の拡張記憶装
置の使用方法については何も述べられていない。

本発明の目的は、拡張記憶装置を共用するような疎結合
マルチプロセサ環境において、共用データ資源に対する
複数のサブシステムからのアクセスの制御を、共用され
た拡張記憶装置を利用して効率よく実現し、かつ、シス
テムの各種の障害発生に対してデータの可用性をできる
だけ保持するようなアクセスの制御を実現する方式を提
供する上記目的を達成するために、本発明は、複数デー
タ処理装置がファイル装置に加えて拡張記憶装置を共用
するような疎結合マルチプロセサシステムでの共用デー
タ資源に対する複数サブシステムからのアクセスを管理
する方法において、個々の共用データ資源に関する排他
制御情報をデータ処理装置の主記憶上に保持するととも
に、クラスタリングされた共用データ資源に関する排他
制御情報を共用拡張記憶上に保持し、各データ処理装置
上のロックマネジャは、主記憶上の排他制御情報を使用
して自データ処理装置内でのサブシステム間の排他制御
を行うとともに、共用拡張記憶上の排他制御情報を使用
してデータ処理装置間での排他制御を行うことにより達
成される。

また、本発明は、ロックマネジャがサブシステムからの
ロック要求を受け付けると、上記主記憶上の排他制御情
報を参照してデータ処理装置間の排他制御が必要かどう
かを判断し、もし必要であれば共用拡張記憶上の排他制
御情報を操作してデータ処理装置間でのロックを確保し
た後に主記憶上の排他制御情報を操作してサブシステム
にロックを与え、もし必要でなければ主記憶上の排他制
御情報を操作してサブシステムにロックを与えることに
特徴がある。

また、本発明は、ロックマネジャが主記憶および共用拡
張記憶上の排他制御情報を参照して、複数データ処理装
置にまたがったデッドロック発生の可能性を検出し、デ
ッドロック発生の可能性がある場合には、関連するデー
タ処理装置に連絡を行って実際にデッドロックが発生し
ているかを確認することにより複数データ処理装置間で
のデッドロックを検出することに特徴がある。

また、本発明はロックマネジャが、システムに各種の故
障が発生した場合、主記憶および共用拡張記憶上の排他
制御情報を使用して、データ資源の整合性を保持するよ
うに、選択的にデータ資源をアクセス禁止にすることに
特徴がある。

また、本発明は、サブシステムは各々、共用データ資源
へのアクセスを実行するためのバッファマネジャとバッ
ファプールを備え、ロックマネジャおよびバッファマネ
ジャは、サブシステムが実行したデータ資源に対する更
新の発生を主記憶および共用拡張記憶上の排他制御情報
を利用して他サブシステムに通知してバッファプール内
容の整合性を保持することに特徴がある。

さらに、本発明は、共用拡張記憶上に全サブシステムに
よって参照および更新されるカウンタを設け、サブシス
テムは各々そのカウンタ値をジャーナルレコードに記憶
することにより、そのカウンタ値をキーとして複数サブ
システムが取得したジャーナルレコードを時系列に並べ
ることに特徴がある。

〔作用〕

共用のデータ資源を管理するために制御情報をメツセー
ジとして連絡し合う方法では、各種の制御情報メツセー
ジを組立てて送受信する処理に大きなオーバヘッドがか
かる。これに対し、拡張記憶は主記憶と同様に命令プロ
セサから高速に同期アクセス可能な記憶装置であり、拡
張記憶上に配置された制御情報を操作することは高速か
つ容易に実行できる。一方、共用された拡張記憶に対す
るアクセスオーバヘッドは、２次記憶に対するものより
もはるかに小さいが、主記憶に対するものよりは多少大
きく、また、主記憶アクセスは、ビット、バイト、また
はワード単位に自由に行えるのに対して、拡張記憶アク
セスはブロック単位であるという制限がある。したがっ
て、シングルプロセサ環境で主記憶上に配置されていた
ロックマネジャの制御テーブルを共用拡張記憶に配置し
、が使用するようにしたのでは、拡張記憶アクセスオー
バヘッドがかさみ、効率良いデータの管理を実現できな
い可能性がある。

本発明では、共用のデータ資源をクラスタリングし、個
々のデータ資源に関する排他制御情報（ローカルロック
管理テーブル）を主記憶に配置して細かな排他制御（ロ
ーカルロック）を行うとともに、クラスタリングされた
データ資源をひとまとまりとして扱い、拡張記憶上には
そのクラスタ対応の情報（グローバルロック管理テーブ
ル）だけを保持して少い粗い排他制御（グローバルロッ
ク）を行うことにより拡張記憶への不必要なアクセスの
増加をおさえているので、各データ処理装置上のロック
マネジャは、自データ処理装置の主記憶上のローカルロ
ック管理テーブルと拡張記憶上のグローバルロック管理
テーブルだけをアクセスすればよく、グローバルロック
の待ちが発生した場合だけデータ処理装置間での通信を
行い、通信オーバヘッドは大きく削減される。

また、各ロックマネジャは主記憶上のローカルロック管
理テーブルを参照して自データ処理装置内で発生してい
るロック待ちの詳細情報を把握するとともに、共用拡張
記憶上のグローバルロック管理テーブルを参照してデー
タ処理装置間のロック待ちの概要情報を獲得して、デー
タ処理装置にまたがったグローバルデッドロック発生の
可能性を確立よく判断できる。これにより、グローバル
デッドロックが実際に発生している事を確実に判定する
ためにデータ処理装置間で行うロック待ち情報の通信が
、不必要に発生することを防止できる。

また、システムに各種の障害が発生した場合、各ロック
マネジャは他のデータ処理装置上のロックマネジャと特
別な連絡を取り合う必要なく、自分の管理するローカル
ロック管理テーブルと共用のグローバルロック管理テー
ブルだけを参照して、自律的にデータ資源へのアクセス
制限を実行できる。これにより、障害対索処理が単純化
される。

また、主記憶上のローカルロック管理テーブルとバッフ
ァ管理テーブルを連携させることにより同−データ処理
装置内の複数サブシステム間でのバッファ内容の同期処
理を行うとともに、拡張記憶上のグローバルロック管理
テーブルを利用してデータ資源の更新を記憶し、各ロッ
クマネジャはこの情報を参照して自データ処理装置上の
バッファ内容の有効性を判断することにより複数データ
処理装置間でのバッファ内容の整合性を保証している。

この方法では、データ処理装置間の通信は不要であり、
オーバヘッドが少ない。

また、共用の拡張記憶上に設けられたカウンタを全サブ
システムが参照および更新し、その内容をサブシステム
が取得するジャーナルレコード中に記録することにより
、そのカウンタ値をキーとして複数サブシステムのジャ
ーナルレコードを一意的な時系列順に並べることが容易
にできるようになる。この方法では、ジャーナルレコー
ド取得時に、時系列順の判断に用いるキー情報を獲得す
るためのデータ処理装置間での通信は必要ない。

共用データ資源を記憶するファイル装置が故障した場合
は、このようにして並べられたジャーナルレコードとフ
ァイル装置のバックアップコピーとをマージしてファイ
ル内容を回復すればよい。

〔実施例〕

以下、本発明の実施例を図面により詳細に説明する。

本発明は、拡張記憶および２次記憶を共用する疎結合マ
ルチプロセサにおいて、共用データ資源に対するアクセ
スを制御する方法を提供する。第１の実施例においては
、複数データ処理装置間の排他制御を行うロックマネジ
ャの仕組みを示し、システムに各種の障害が発生した場
合の処理を合わせて記載する。第２の実施例では、第１
の実施例で記載するロックマネジャと各サブシステムの
バッファマネジャやジャーナルマネジャを組合せた処理
を述べる。

（１）第１の実施例 本発明の第１の実施例であるコンピュータシステムのブ
ロック図を第１図に示す。第１図においては、通信装置
１０で結合された複数のデータ処理装置２０．３０が、
拡張記憶装置４０およびフフィル装置５０を共用してい
る例が示されている。

各々のデータ処理装置は、共用データ資源をアクセスす
るサブシステム２１〜２２．３１〜３２、ロックマネジ
ャ２３，３３、およびローカルロック管理テーブル２４
．３４を含む。また、共用の拡張記憶装置４０上には、
グローバルロック管理テーブル４１が配置される。ロー
カルロック管理テーブルとグローバルロック管理テーブ
ルの内容と使いかたは後述する。共用のデータ資源は、
共用の拡張記憶装置４０または共用のファイル装置５０
上に保持される。第１図では、２台のデータ処理装置と
４つのサブシステムからなるシステムの構成が示されて
いるが、さらに多くのデータ処理装置や、さらに多くの
（もしくは少ない）サブシステムからなるシステムであ
ってもかまわない。

また、各データ処理装置は、共用しない拡張記憶装置や
ファイル装置を備えていてもよい。これらの拡張装置間
で共用されないデータ資源が配置される。また、本実施
例においては、通信袋Ｗ１０は任意のデータを伝送でき
る複雑な装置である必要はなく、他データ処理装置に単
純なコードを連絡できる程度のものでよい。共用の拡張
記憶装置４０上にデータ処理装置間のメールボックスを
設け、そこにメツセージを格納するようにすれば、その
ような簡単な通信装置しかなくてもデータ処理装置間で
任意のデータをやりとりできる。

ロックマネジャ２３　（３３）は、データ処理装置対応
に１つ存在し、自データ処理装置上で動作するサブシス
テム２１および２２（３１および３２）からのロック要
求、アンロック要求を受け付け、自データ処理装置の主
記憶上に保持されたローカルロック管理テーブル２４　
（３４）　、および共用の拡張記憶上に保持されたグロ
ーバルロック管理テーブル４１を操作して排他制御を行
う。

ロックマネジャに対してロック要求、アンロック要求を
実際に発行するのは、各サブシステムの管理下で実行さ
れるトランザクションである。各々のトランザクション
は、共用データ資源を使用する前にロックマネジャに対
してロック要求を出し、ロックが確保できると該データ
資源へのアクセスを行い、該データ資源の利用が不要に
なるとアンロック要求を発行してデータの使用権を放棄
する。

各々のデータ処理装置、サブシステム、および共用デー
タ資源には、システム内で一意の識別子が付与される。

また、サブシステムの管理下で動作するトランザクショ
ンには、サブシステム内で一意の識別子が付けられてお
り、この識別子とサブシステムの識別子を組合せること
により、システム内で一意の識別子を組合せることによ
り、システム内で一意の識別子が構成できる。ここで、
サブシステムに対してデータ処理装置内で一意でなく全
システム内で一意の識別子を与えるのは、サブシステム
は複数のデータ処理装置上で実行される可能性があるた
めである（もちろん、同時には１つのデータ処理装置上
でしか実行されない）。

このようなことは、例えば、あるデータ処理装置が故障
して、その上で実行されていたサブシステムを予備のデ
ータ処理装置で実行するような場合に起こりうる。

ローカルロック管理テーブル２４　（３４）の内容を第
２図に示す。マスク管理テーブル１００は、各テーブル
を検索する場合のアンカとなるテーブルであり、ロック
マネジャ対応に１つ設けられる。

サブシステムテーブル１１０は、自データ処理装置上で
動作するサブシステムを表現するものであり、マスク管
理テーブルからポイントされる。各サブシステムの管理
下で動作するトランザクションは、トランザクションテ
ーブル１２１，１２２により表現される。トランザクシ
ョンテーブルは、サブシステムテーブルからのポインタ
チェーンにつながれる。

共用データ資源は、２段階にクラスタリングされる。最
初のクラスタリングは、そのデータ資源の運用上の特性
に応じてユーザがシステム定義で分類基準を与えるもの
であり、各クラスタ（資源クラスと呼ぶ）対応に資源ク
ラステーブル１３０が設定される。２段目のクラスタリ
ングは、資源名称をキーとしたハツシングによって行わ
れ、同一のハツシュ値を持つデータ資源が１つのクラス
タ（ハツシュクラスと呼ぶ）となり、ハッシュクラステ
ーブル１４１，１４２で表現される。資源クラステーブ
ルはマスク管理テーブル１００からポイントされ、ハツ
シュクラステーブルは資源クラステーブル１３０中のポ
インタアレイの１つによってポイントされる。また、個
々の共用データ資源は、資源テーブル１５１〜１５２で
表される。

この資源テーブルは、各々が属するハツシュクラステー
ブルからのポインタチェーンにつながれる。

クラスタリングを多段にするのは、大容量共用データ資
源の運用上、その方が好都合だからである。

クラスタリングがハツシングによる１段だけであると、
例えば、個別のファイル装置上に配置されたデータ資源
が同一のハツシュクラスにクラスタリングされてしまい
、ハツシュクラス単位の操作を行う場合にファイル装置
間の不必要な干渉が発生してしまう可能性がある。その
ようなサイドエフェクトを排除することは、特別の工夫
を施したハツシュ関数を使用してクラスタリングを行う
ことによっても可能であるが、多段のクラスタリングを
行う方がより自然に実現できる。

それぞれのトランザクションによるロック要求は、ロッ
クテーブル１６１〜１６５によって示される。ここで、
ロックテーブルは、そのロック要求の処理状況に応じて
３つの状態を持つ。第１の状態は、「ロック保有ｊ状態
であり、トランザクションがデータ資源に対するロック
を確保していることを示す。この状態のロックテーブル
は、資源テーブルからのロック保有チェーンにつながれ
る。第２の状態は、「ローカルロック待ち」状態であり
、自データ処理装置内の他トランザクションのロック解
放を待っていることを示す。この状態のロックテーブル
は、資源テーブルからのローカルロック待ちチェーンに
つながれる。第３の状態は、「グローバルロック待ち」
状態であり、他データ処理装置上のトランザクションの
ロック解放を待っていることを示す。この状態のロック
テーブルは、ハツシュクラステーブルからのグローバル
ロック待ちチェーンにつながれる。あるトランザクショ
ンが複数のロックを確保していることは、トランザクシ
ョンテーブルからのポインタチエージにつながれたロッ
クテーブルによって表現される。第２図では、トランザ
クションｔ１が、ロックテーブル１６１，１６２，１６
３によって表現されるロック要求を行い、トランザクシ
ョンｔ２がロックテーブル１６４，１６５によって表現
されるロック要求を行っている例が示されている。ここ
でロックテーブル１６２，１６３゜１６５は「ロック保
有」状態、ロックテーブル１６４は「ローカルロック待
ち」状態、ロックテーブル１６１は「グローバルロック
待ち」状態である。

共用データ資源に対するロックの確保は、グローバルロ
ックの確保とローカルロックの確保という２段階の手続
きで行われる。グローバルロックは、複数データ処理装
置間の排他制御を行うためのロックであり、ロックは、
ハツシュクラス単位に、データ処理装置に対して与えら
れる。これに対して、ローカルロックは、１つのデータ
処理装置内での複数トランザクション間の排他制御を行
うためのロックであり、ロックは、個々の資源単位にト
ランザクションに対して与えられる。共用資源に対する
ロックを確保する場合は、まずロック対象資源の属する
ハツシュクラスのグローバルロックを自データ処理装置
について確保し、次にその資源のローカルロックを自ト
ランザクションについて確保するという手順が実行され
る。自データ処理装置が既にロック対象ハツシュクラス
のグローバルロックを保有している場合には、新たにグ
ローバルロックを確保しにゆく必要はなく、ローカルロ
ックの確保から実行すればよい。

第３図は、共用の拡張記憶上に保持されたグローバルロ
ック管理テーブルを示している。拡張記憶は、主記憶と
拡張記憶の間でのデータ転送を実行する処理装置命令に
よってそれぞれのデータ処理装置から直接読み書き可能
であり、そのデータ転送は、ブロック単位に行われる（
ブロックのサイズは個々のハードウェア仕様による）。

拡張記憶へのアクセスは、主記憶に対するアクセスより
は遅いが、２次記憶（例えば磁気ディスク装置など）に
対するアクセスよりははるかに速いという特性を持って
いる。従って、グローバルロック管理テーブルを主記憶
上のローカルロック管理テーブルと同様に設計して頻繁
なアクセスを行うと、システム全体の性能が低下する恐
れがある。本実施例では、グローバルロック管理テーブ
ルをポインタチェーンのない単純な配列構造とし、クラ
スタ化されたデータ資源（ハツシュクラス）対応にエン
トリを設けることにより、拡張記憶に対する不必要なア
クセスの増大を防いでいる。

拡張記憶の１ブロツク２００内には、複数のグローバル
ロック管理テーブルエントリ２１０が配置される。グロ
ーバルロック管理テーブルエン１〜りは、対応するハツ
シュクラスのハツシュ値の順に並べられている。各ロッ
クマネジャは、自データ処理装置の主記憶上に、ハツシ
ュクラスと拡張記憶ブロックの対応表を持っており、こ
れによって目的のグローバルロック管理テーブルエン１
ヘリを含むブロックのアドレスを求め、そのブロックを
主記憶に転送して操作を行う。各々のグローバルロック
管理テーブルエントリ２　］、　Ｏは、第４図に示され
るように、ａ）対応するハツシュクラスに関してどのデ
ータ処理装置がどのモードのロックを保有しているかを
示すロック占有マツプのフィールド２１１と、ｂ）グロ
ーバルロック確保を持っているデータ処理装置のキュー
を作成するためのフィールド２１２を含む。このキュー
は、ロック要求元のデータ処理装置を示すフィールドと
要求ロックモードを示すフィールドのペアの配列で表現
される。グローバルロックテーブルエントリの内容は、
本実施例で示したもの以外でも、グローバルロックの占
有と待ちを表現するものであれば何でもよい。

本実施例における、ロックモード両立性の一覧を第５図
に示す。ここで、ロックモードの両立性とは、異なるト
ランザクションから同一のロック対象に要求された２つ
のロックが同時に許可可能であるかをいう。２つのロッ
クが両立しない場合には、後から行われたロック要求が
待たされる。

第５図において、Ｑ印は２つのロックモードが両立する
（即ち、同時にロック許可が可能である）ことを示し、
Ｘ印は２つのロックモードが背反である（同時にはロッ
クを許可不可能である）ことを意味している。また、第
６図にロックモードの包含性の一覧を示す。ここで、２
つのロックモード間での包含性とは、一方のロックモー
ドで許可されるデータへのアクセス権限が他方のロック
で許可されるアクセス権限に含まれるかどうかをし、）
う。あるデータ資源に対して既にロックを確保している
トランザクションが、同じデータ資源に対して再度ロッ
ク要求を行った場合、新たに要求したロックのモードが
既に確保したロックのモードに包含されるならば、新た
なロック要求は即時に許可されるが、そうでなければ新
たなロック要求は拒否される。後者の場合は、ロックマ
ネジャは新たなロック要求を取り消すか、もしくは、既
に確保しているロックと新たに要求されたロックをとも
に包含するモードのロック確保処理を試行する。第６図
において、Ｏ印はロックモードの包含関係が成立するこ
とを、Ｘ印は包含関係が成立しないことを示している。

ロックモードは、ここで示した以外のものを使用しても
よく、また、矛盾を引き起こさない範囲で、ローカルロ
ックとグローバルロックで別途のロックモード体系を採
用することも可能である。

以降では、ロック処理とアンロック処理を流れ図に従っ
て詳細に説明してゆく。説明は、ローカルロックとグロ
ーバルロックに分けて行う。なお、流れ図の説明におい
ては、記述が必要以上に複雑になるのを避けるため、細
かな例外処理等を省略しである。

（１−１）ローカルロック確保 第１１図は、ローカルロック処理の流れである。

トランザクションがロックマネジャに対してロック要求
を発行すると、まずこのローカルロック処理が起動され
る。ここで、ローカルロック要求の入力パラメタは、ロ
ック対象のデータ資源名称とロックモードおよびロック
要求トランザクションに対応するトランザクションテー
ブルである。ロックマネジャは、ローカルロック要求を
受け付けると、そのロック要求に対応したロックテーブ
ルを作成してトランザクションテーブルからのチェーン
につないだ後（ステップ１１０１）、後述するグローバ
ルロック処理をコールする（ステップ１１０２）。次に
、グローバルロック処理の出力で指定されるハツシュク
ラステーブルよりチェーンされる資源テーブルのポイン
タチェーンをたどって、ロック対象データ資源に対応す
る資源テーブルが既に作られているかを確認しくステッ
プ１１０３．１１０４）、なければ新たに作成してチェ
ーンにつなぐ（ステップ１１０５）。ロック対象データ
資源に他のロックがかけられていないか、または、今回
のロック要求と両立するロックしかかけられていない場
合は、今回のロック要求は許可可能であり、ロックテー
ブルを資源テーブルからのロック保有チェーンにつない
で要求元ヘリターンする（ステップ１１０６．１１０８
）。

既に当該データ資源に今回の要求ロックモードと背反の
ロックがかけられている場合は、ロックテーブルを資源
テーブルからのローカルロック待ちチェーンにつないで
、ロック占有トランザクションからのローカルロック解
放連絡を待つ（ステップ１１０７）。上記ローカルロッ
ク処理は、ステップ１００２でグローバルロック処理を
コールすることを除けば、一般のロック処理とほぼ同じ
である。また、ロックが即時に確保できない場合の処理
や、ロック要求トランザクションが当該データ資源に対
するロックを既に保有している場合の処理などの例外処
理は、例えばロック待ちとせずエラーリターンするとか
いった各種のバリエーションが考えられるが、それらは
本発明に関して本質的ではないため説明を割愛する。

（１−２）ローカルロック解放 第１２図に、ローカルアンロック処理の流れを示す。ロ
ーカルロック処理と同じく、トランザクションからのア
ンロック要求が発生すると、まずこのローカルアンロッ
ク処理が実行される。ローカルアンロック処理の入力パ
ラメタは、アンロック対象を一意に指定するものであり
、例えば、データ資源の名称とトランザクションテーブ
ルであり、また、ロックテーブル自体のアドレスを直接
指定してもよい。ロックマネジャは、この入力パラメタ
の指定よりアンロック対象のロック要求に対応するロッ
クテーブルを見つけ、それを資源テーブルからのロック
保有チェーンよりはずし、同時にロックテーブルをトラ
ンザクションテーブルからのチェーンより外してロック
テーブルを解放する（ステップ１２０１）。次に、アン
ロック対象データ資源からのローカルロック待ちチェー
ンを調べ（ステップ１２０２）、今回のアンロックによ
ってロック許可可能となるロック要求があればそのロー
カルロック要求の待ちを解除しくステップ１２０７）、
その後要求元にリターンする。

ここで解除するローカルロック待ちは、ローカルロック
処理で説明した、第１１図のステップ１１０７で発生し
たものである。今回のアンロック処理によって当該デー
タ資源に対するローカルロックが全て解放された、すな
わち資源テーブルからの保有ロックチェーンが空になっ
たならば、その資源テーブルを解放する（ステップ１２
０３゜１２０４、　）。また、上記資源テーブルの解放
によって、当該データ資源と同一のハツシュクラスに属
するデータ資源の資源テーブルが全て解放された、すな
わちハツシュクラステーブルからの資源テーブルチェー
ンが空になったならば、グローバルアンロック処理をコ
ールする（ステップ１２０５．１２０６）。ステップ１
２０３において当該データ資源にまだ他のローカルロッ
クが残っている、または、ステップ１２０５において当
該ハツシュクラスに属する資源テーブルがまだ残ってい
る場合は、グローバルアンロック処理をコールせずにそ
のままリターンする。このローカルアンロック処理も、
ステップ１２０６で行うグローバルアンロック処理コー
ルを除けば、はぼ一般のアンロック処理と同じである。

（１−３）グローバルロック確保 グローバルロック処理の流れを第１３図と第１４図に示
す。グローバルロック処理は、ローカルロック処理中か
らコールされ（第１１図のステップ１１０２）、その人
力パラメタは、ロック対象ハツシュクラスのハツシュ値
とロックテーブルである。グローバルロックは、その対
象が個々のデータ資源ではなくハツシュクラスであり、
ロック保有主体がトランザクションではなくデータ処理
装置である点がローカルロックと異なる。グローバルロ
ック処理では、まずロック対象のハツシュクラステーブ
ルをサーチしくステップ１３０１）、テーブルがなけれ
ば新たに作成して資源クラステーブルからポイントする
（ステップ１３０２．１３０３）。ステップ１３０３で
ハツシュクラステーブルを新たに作成した時点では、ハ
ツシュクラスはロック許可可能状態である。次に、ロッ
ク対象ハツシュクラスがロック許可可能状態であるかを
確かめ（ステップ１３０４）、許可可能であれば、今回
のグローバルロック要求を包含するモードのグローバル
ロックを自データ処理装置が既に確保しているかを調べ
る（ステップ１３０５）。既に包含するグローバルロッ
クが確保されていればそのまま要求元にリターンし、自
データ処理装置がグローバルロックを確保していないか
、またはグローバルロックを確保しているがそのロック
モードが今回のグローバルロック要求を包含しない場合
は、必要なグローバルロックを獲得しにゆく。ステップ
１３０４のチエツクでロック許可不可能状態であれば、
グローバルロック待ちに入る（ステップ１４．１１　）
。このロック許可可能状態の設定および変更については
後述する。以上の説明かられかるように、自データ処理
装置が必要なグローバルロックを既に確保している場合
は、拡張記憶上のグローバルロック管理テーブルへのア
クセスは発生しない。

グローバルロックの獲得は、第１４図のように行われる
。まず、ロック対象のハツシュクラスに対応するグロー
バルロック管理テーブルエントリを含む拡張記憶のブロ
ックを主記憶に転送しくステップ１４０１）、グローバ
ルロックが獲得可能かを調べる（ステップ１４０２）。

対象ハツシュクラスに他のデータ処理装置がグローバル
ロックをかけていない、または他のデータ処理装置が既
にグローバルロックをかけているがそのロックモードば
今回のグローバルロック要求と両立するものである場合
は、グローバルロック管理テーブルエントリ中の自デー
タ処理装置に対応する占有マツプをセットした後（ステ
ップ１４０３）、そのブロックを拡張記憶に書き戻す（
ステップ１４０４）。ステップ１４０２でロックモード
の両立性を調べるとき、獲得すべきロックモードは、今
回のグローバルロック処理のコールの原因となったトラ
ンザクションのロック要求だけによるものではなく、当
該ハツシュクラスに対してグローバルロック待ちになっ
ているロック要求を全て包含するようなロックモードで
ある。即ち、グローバルロック要求は、グローバルロッ
ク待ちになっている複数のトランザクションからのロッ
ク要求を１つにまとめた形で実行される。次に、主記憶
上のハツシュクラステーブルからチェーンされているグ
ローバルロック待ちのロックテーブルをチェーン先頭か
らたどり、順次グローバルロック待ちを解除してゆく（
ステップ１４０５）。グローバルロック管理テーブルエ
ントリ中のキューを調べ、キューが空である、すなわち
グローバルロック待ちの他データ処理装置が存在しなけ
れば、ハツシュクラスをロック許可可能状態にして（ス
テップ１４０６）要求元にリターンする。ステップ１４
０２において、他のデータ処理装置が既に今回のグロー
バルロック要求と背反のグローバルロックを確保してい
るならば、グローバルロックテーブルエントリ中のグロ
ーバルロック待ちキューに自データ処理装置の要求を設
定して（ステップ１４０７）、そのブロックを拡張記憶
へ書き戻す（ステップ１４０８）。それから、自データ
処理装置の主記憶上で対象ハツシュクラステーブルをロ
ック許可不可能状態にしくステップ１４０１）、ロック
テーブルをハツシュクラステーブルからのグローバルロ
ック待ちチェーンにつないで他データ処理装置のグロー
バルロック解放を待つ（ステップ１４１１）。ステップ
１４０６でグローバルロックテーブルエントリにキュー
情報を設定した時に、自データ処理装置がロック待ちの
先頭であれば、グローバルロック待ちが発生したことを
、グローバルロック占有中の他データ処理装置に連絡す
る（ステップ１４０９．１４１２）　６ステツプ１４１
１のグローバルロック待ちが解除されると、ロックマネ
ジャはステップ１３０５からグローバルロック獲得を再
試行する。ステップ１４１０でハツシュクラスをロック
許可不可能状態にするのは、自データ処理装置内で発生
するロック要求をＦＩＦ○（Ｆｉｒｓｔ　　Ｉｎ　Ｆｉ
ｒｓｔ　０ｕｔ）でサービスするためであり、今回のグ
ローバルロック要求よりも後で受け付けたグローバルロ
ック要求は、ロックモードの両立性の判定だけでは即時
に許可可能であっても、今回のグローバルロック要求が
満たされるまでは待ちとなる。

ステップ１４１２で送信したグローバルロック待ち発生
連絡を受信したデータ処理装置では、第１６図に示すよ
うな処理を行う。まず、連絡メツセージ中で指定された
ハツシュクラスに対応するハツシュクラステーブルをサ
ーチして、そのハツシュクラスをロック許可不可能状態
とする（ステップ１６０１）。これにより、当該ハツシ
ュクラスに属するデータ資源に対してこのデータ処理袋
置内で発生するロック要求は全てグローバルロック待ち
となり、グローバルロックの不当な長期占有が防止され
る。ロック待ちメツセージ受信時点で、当該ハツシュク
ラスに属するデータ資源に対するローカルロックが存在
しない場合は、グローバルアンロック処理をコールする
（ステップ１６０２．１６０３）。このような場合は、
データ処理装置が、あるハツシュクラスに対するグロー
バルロックを獲得して後、そのハツシュクラスに属する
データ資源に関するローカルロックが全て解放されてし
まうまで、他のデータ処理装置から当該ハツシュクラス
に対するグローバルロック要求が生しなかった時に起こ
りうる。

（１−４）グローバルロック解放 第１５図は、グローバルアンロック処理の流れ図である
。グローバルアンロック処理では、アンロック対象のハ
ツシュクラスが入力パラメタとなり、まず、ハツシュク
ラスのロック許可可能状態を調べる（ステップ１５０１
）。ハッシュクラスまま要求元ヘリターンする。これは
、当該ハツシュクラスに属するデータ資源に対して次回
のロック要求が発生したときに、グローバルロック確保
オーバヘッドを少なくするためである。ステップ１５０
１において、ロック許可不可能状態である、すなわち、
自データ処理装置もしくは他データ処理装置内で当該ハ
ツシュクラスに関するグローバルロック待ちが発生して
いる場合には、占有中のグローバルロックの解放を行う
。ロックマネジャは、グローバルロックの解放を行うた
め、解放対象のハツシュクラスに対応するグローバルロ
ック管理テーブルエントリを含む拡張記憶のブロックを
主記憶に転送しくステップ１５０２）、主記憶上で自デ
ータ処理装置のロック占有マツプをリセットしてからブ
ロックを拡張記憶へ書き戻う（ステップ１５０３．１５
０４）。このとき、グローバルロック管理テーブルエン
トリ中のキューを調べて、自データ処理装置のグローバ
ルロック解放でグローバルロック獲得が可能になった他
データ処理装置があれば、そのデータ処理装置へロック
解放連絡メツセージを送信する（ステップ１５０５．１
５０６）。また、自データ処理装置内で当該ハツシュク
ラスに対するグローバルロック待ちが発生していて、か
つそのグローバルロック要求が今回のグローバルロック
解放時点で獲得可能である場合には、グローバルロック
処理をコールする（ステップ１５０７．１５０９）。自
データ処理装置内でそのようなグローバルロック待ちが
ない場合は、ハツシュクラステーブルを解放して要求元
ヘリターンする（ステップ１５０８）。

ステップ１５０６で送信されたロック解放連絡メツセー
ジを受信したデータ処理装置での処理の流れを第１７図
に示す。この場合、ロックマネジャは、グローバルロッ
クが解放されたハツシュクラスに対応するハツシュクラ
ステーブルのグローバルロック待ちチェーンを見て、チ
ェーン先頭の待ちを解除する（ステップ１７０１）。こ
の待ちは、グローバルロック処理中で発生したものであ
り（第１４図のステップ１４１１）、　、待ちを解除さ
れたロック要求は、グローバルロック確保を再試行する
。

以上が、本実施例におけるロックおよびアンロック処理
の説明であるが、ローカルロックとグローバルロックの
関連のつけ方には、さまざまなバリエーションが考えら
れる。本実施例では、グローバルアンロック処理におい
て、他のデータ処理装置で当該ハツシュクラスに対する
グローバルロック待ちが発生していなければグローバル
ロックの解放を実行しないことにより、次回のグローバ
ルロック獲得のオーバヘッドを削減している。また、自
データ処理装置がグローバルロックを保有しているハツ
シュクラスに関して、他のデータ処理装置でグローバル
ロック待ちが発生した場合は、自ローカルロック管理テ
ーブル中のハツシュクラスをロック許可不可能状態とし
て自データ処理装置内からのグローバルロック要求を認
めないことによりグローバルロックの不当な長期占有を
防止している。この方法は、特にグローバルロック対象
となるハツシュクラスの分布がデータ処理装置ごとに分
離されている傾向のあるシステムにおいてグローバルロ
ックオーバヘッドを減らすのに有効である。これに対し
て、グローバルロックが頻繁にデータ処理装置間を移る
ようなシステムにおいては、本実施例におけるロック待
ち発生連絡を行わないことにより、データ処理装置間で
の通信オーバヘッドを削減する方法も考えられる。この
方法では、例えば、一定時間以上グローバルロックを占
有したとか、一定数以上のローカルロックを自データ処
理装置内で与えたとかいった指標を用いてハツシュクラ
スをロック許可不可能状態とすることにより、長時間占
有を防止する。また、本実施例のように、複数のトラン
ザクションからのロック要求をまとめてグローバルロッ
ク処理を行うのではなく、ローカルロック要求とグロー
バルロック要求を１対１に対応させる方法も考えられる
。これは、拡張記憶アクセスオーバヘッドと主記憶アク
セスオーバヘッドのギャップが小さい場合に採用でき、
ロックマネジャの処理を単純可することができる。

（１−５）デッドロック検出 ロックマネジャは、ローカルロック管理テーブルを走査
し、自データ処理装置内のトランザクション間での待ち
のループを検出することができる。

本発明のような複数データ処理装置がデータ資源を共用
してアクセスする環境では、このようなローカルデッド
ロックの他に、データ処理装置間にまたがった待ちのル
ープ（グローバルデッドロック）の検出が必要となる。

第７図にグローバルデッドロックの例を示す。

第７図では、データ処理装置１上で動作するトランザク
ションｔ１は、ハツシュクラスａに属するデータ資源ａ
１に対するローカルロックを保有し、ハツシュクラスｂ
に対するグローバルロック待ちとなっており、他方デー
タ処理装置２上で動作するトランザクションｔ２は、ハ
ツシュクラスｂに属するデータ資源ｂ１に対するローカ
ルロックを保有し、ハツシュクラスａに対するグローバ
ルロック待ちとなっている状態が示されている。第７図
において、１２３〜１２４はトランザクションテーブル
、１４３〜１４６はハツシュクラステーブル、１５３〜
１５４はデータ資源テーブル、１６６〜１６９はロック
テーブルである。このようなグローバルデッドロックを
検出するには、複数のロックマネジャの共同作業が必要
となる。

第１８図に、グローバルデッドロック検出処理の流れ図
を示す。デッドロック検出処理は、一定時間おきに、ま
たは一定数以上のトランザクションがロック待ちとなっ
たときに、または他データ処理装置からの待ちグラフ受
信時に起動される。

デッドロック検出処理が起動されると、ロックマネジャ
は、自データ処理装置内のローカルロック管理テーブル
を走査して、トランザクションの待ちグラフを作成しく
ステップ１８０１）、その待ちグラフを簡約化する（ス
テップ１８０２）。他データ処理装置から待ちグラフを
受信して起動された処理の場合は、自データ処理装置内
の待ちグラフと受信した待ちグラフを合成してから簡約
化する。ここで、待ちグラフのデータ処理装置上での表
現方法と、グラフの簡約アルゴリズムは任意のものを使
用してよい。待ちグラフの簡約結果、待ちループが検出
されたならば、犠牲トランザクションを選択し、そのト
ランザクションにデッドロック連絡を行う（ステップ１
８０３．１８０４）。

ここで発見される待ちループには、ローカルデッドロッ
クとグローバルデッドロックの両方が含まれる。連絡を
受けたトランザクションは、ロールパック処理を行い、
占有しているデータ資源のロックを解放する。犠牲トラ
ンザクションの選択基準は任意のものを使用してよい。

また、選択された犠牲トランザクションが他データ処理
装置上で動作しているならば、そのデータ処理装置にデ
ッドロック発生を通知するメツセージの送信が必要であ
る。次に、待ちグラフ中にグローバルデッドロック候補
が存在しないかを確かめる（ステップ１８０５）。ここ
で言うグローバルデッドロック候補とは、他データ処理
装置を始点とし他データ処理装置を終点とする待ちの系
列で表現される待ちグラフであり、複数データ処理装置
にまたがった待ちループが発生している可能性のあるグ
ラフである。自データ処理装置上のトランザクションが
他データ処理装置上のトランザクションを待っているこ
とは、ハツシュクラステーブルからのグローバルロック
待ちチェーンの有無によってわかる。逆に、他のデータ
処理装置上のトランザクションが自データ処理装置上の
トランザクションを待っていることは、他データ処理装
置からのグローバルロック待ち発生連絡を受信した時点
でハツシュクラステーブルに記憶されている。このグロ
ーバルデッドロック候補が存在する場合は、拡張記憶上
のグローバルロック管理テーブルを参照して、どのデー
タ処理装置を待っているのかを調べ（ステップ１８’０
６）、そのデータ処理装置に候補の待ちグラフを送信す
る（ステップ１８０７）。

グローバルロック待ちが発生していることはローカルロ
ック管理テーブルを走査すれば判るが、どのデータ処理
装置間で待ちが発生しているかはグローバルロック管理
テーブルを見ないと確定できない。もし、ローカルロッ
クテーブルだけでグローバルロック待ちの詳細情報を得
ようとすると、グローバルロック待ちの発生および解除
のたびごとにデータ処理装置間での連絡を行う必要があ
り、通信オーバヘッドが大きくなる。待ちグラフの受信
側では、グローバルデッドロック処理を起動する。ステ
ップ１８０３とステップ１８０５でデッドロックまたは
デッドロック候補を検出できなければ、グローバルデッ
ドロックは存在しないことになり、デッドロック検出処
理は完了する。グローバルデッドロックが発生している
場合は、複数のデータ処理装置でほぼ同時にデッドロッ
ク検出１処理が起動されると、各々のデータ処理装置で
グローバルデッドロック候補が検出され、データ処理装
置間の通信が必要以上に行われる場合がある。

これを防ぐには、例えば、データ処理装置に一意的な順
序関係を設定しておき、デッドロック候補の待ちグラフ
の連絡は、順序関係の先のデータ処理装置から後のデー
タ処理装置に向かってだけ行うようにすればよい。また
、本実施例では、グローバルロックをハツシュクラス単
位で行っているため、個々のデータ資源単位でロック要
求を見ればデッドロックになっていなくても、相互に無
関係な複数のデータ資源がたまたま同一のハツシュクラ
スに含まれているためにグローバルデッドロックになっ
てしまう場合が起こりうる。このような不必要なデッド
ロックの発生確率は、ハツシュクラスとデータ資源の対
応を１対１に近付けるほど小さくなる。これは、ハツシ
ュ関数の選択と、拡張記憶上のグローバルロック管理テ
ーブルエントリ数をどの程度準備するかということで制
御できる。

本節以降で、システムに各種の障害が発生した場合のロ
ックマネジャの処理を述べる。障害発生に対する基本方
針は、データの整合性を損なわないように、かつできる
だけ制限された範囲のデータ資源を障害回復までアクセ
ス禁止にすることである。システムの障害には、大きく
分けてサブシステムの故障１通信装置の故障、データ処
理装置の故障の３つの形態があり、以下で順に述べてゆ
く。

（１−６）サブシステムの故障 自データ処理装置上のサブシステムが故障したことが通
知されると、ロックマネジャは、そのサブシステムが保
有していたローカルロックを保留し、そのサブシステム
の行ったロック要求のうち待ち状態になっているものを
無効にする。保留されたロックモードと両立しないロー
カルロック要求が当該データ資源に対して行われると、
ロックマネジャはそのロック要求を待ち状態にすること
なく即時にエラーリターンさせ、長期ロック待ちの発生
を防止する。ここで、サブシステムの故障の検出とロッ
クマネジャへの通知の仕組は、本発明とは特に関係しな
いので説明を省略する。ロックマネジャは、ローカルロ
ックの保留を行うとともに、保留されたローカルロック
を包含する様にグローバルロックの保留も行う。ローカ
ルロックの保留は、自データ処理装置上のデータ資源テ
ーブル上に記憶され、グローバルロックの保留は、拡張
記憶上のグローバルロック管理テーブルエントリ上に記
憶される。他データ処理装置に対するアクセス禁止の制
御は、保留されたグローバルロックを通じてハツシュク
ラス単位に行われる。すなわち、他データ処理装置のロ
ックマネジャは、保留されたグローバルロック要求を待
ち状態にせずエラーリターンさせる。これらのローカル
ロックおよびグローバルロックの保留は、故障したサブ
システムが回復してデータ整合性復旧処理が完了した時
点で解除される。

（１−７）通信装置の故障 通信装置が故障して、他のデータ処理装置との連絡が不
可能になった場合、ロックマネジャはグローバルロック
確保処理において、通信不可能な他データ処理装置が、
要求されたグローバルロックモードと両立しないグロー
バルロックを占有していればそのグローバルロック要求
をエラーリターンさせる。この場合、ロックマネジャは
、特別にロック保留状態をテーブルに記憶する処理は行
わない。したがって通信装置が故障から回復した時も、
特別な処理はない。

（１−８）データ処理装置の故障 他データ処理装置の故障は、モニタリング装置（図示省
略）によって検出され、ロックマネジャに通知される。

通知を受けたロックマネジャは、拡張記憶上のグローバ
ルロックテーブルエントリを走査し、故障したデータ処
理装置が占有していたグローバルロックを保留状態にし
、待ち状態のグローバルロック要求を無効にする。この
保留状態は、グローバルロックテーブルエントリに記憶
され、以後、保留されたグローバルロックと両立しない
グローバルロック要求は全てエラーリターンさせられる
。このロック保留は、故障したデータ処理装置上で稼働
していた全てのサブシステムの回復処理が完了した時点
で解放される。

上記、サブシステム故障とデータ処理装置故障に起因す
るロック保留は、全てのモードのロックに対して行われ
る必要はない。データ資源の整合性を保証するには、汚
れたデータ資源、すなわち動作不能になったサブシステ
ムが更新を行っていたデータ資源だけをアクセス禁止に
すれば十分である。したがって、データ更新を行うため
のロックモード（本実施例では、ＳＵ、ＰＵ、ＥＸモー
ドがこれに相当する）を待つロックだけを保留すればよ
く、データ参照だけを行うためのロックモード（本実施
例では、ＳＲ，ＰＲモードがこれに相当する）を持つロ
ックは解放してよい。

（２）第２の実施例 本発明の第２の実施例であるコンピュータシステムのブ
ロック図を第８図に示す。第２の実施例においては、第
１の実施例のロックマネジャに加えて、サブシステムの
バッファマネジャやジャーナルマネジャが有機的に協力
してデータ資源の共用を実現している。第８図において
は、各サブシステム（２１，２２，３１，３２）はそれ
ぞれデータ資源アククセスのためのバッファプール（２
５，２６，３５，３６）とデータ資源の更新を記憶する
ためのジャーナルファイル（６１゜６２．６３．６４）
を備えている。また、全サブシステムで共用するグロー
バルバッファプール４２を拡張記憶上に持っていてもよ
い。さらに拡張記憶上には、全サブシステムによって参
照更新されるカウンタ４３が設けられている。その他の
構成は、第１図で示した第１の実施例と同じである。ロ
ックマネジャが行うロック処理およびアンロック処理は
、第１の実施例と同様であるためここでは説明を割愛し
、第２の実施例の特徴であるバッファ管理方法とジャー
ナル管理方法について詳しく説明する。

（２−１）バッファ管理 複数のデータ処理装置上で動作する複数のサブシステム
が共用のファイル装置上に格納されている共用のデータ
資源をアクセスする場合、Ｉ１０バッファとしてグロー
バルバッファを使用する場合とローカルバッファを使用
する場合がある。グローバルバッファは、共用の拡張記
憶上に設けられ、全サブシステムによって使用される。

このため、あるサブシステムがグローバルバッファ上で
更新を行ったデータ資源は、直ちに他のサブシステムか
らもアクセス可能である。これに対して、ローカルバッ
ファは各サブシステム対応に主記憶上に設けられ、１つ
のサブシステムだけによって使用される。したがって、
同一のデータ資源が複数のサブシステムのローカルバッ
ファ上に保持されている場合、１つのサブシステムがそ
のデータ資源を更新しても、その内容が他のサブシステ
ムのローカルバッファ上のデータ資源に反映されず、デ
ータの一貫性が保てない可能性がある。これを防止する
ために、本実施例ではロックマネジャとサブシステムの
バッファマネジャの連携を行っている。第９図に本実施
例におけるロックマネジャとバッファマネジャの管理す
るテーブルの関連を示す。第９図においては、１４７〜
１４８はハツシュクラステーブル、１５５〜１５７はデ
ータ資源テーブル、２１〜２２はサブシステム、１７１
〜１７４はバッファ管理テーブル、２５〜２６はローカ
ルバッファプールをそれぞれ示している。

ハツシュクラステーブルとデータ資源テーブルの関連は
、第２図で示したものと同じである。バッファ管理テー
ブルは、個々のバッファ対応に１つ設けられ、バッファ
中にどのようなデータ資源が格納されているかの情報を
含む。サブシステムは、データ資源をアクセスする場合
、まずロックマネジャにロック要求を発行し、ロックを
確保できたならば、バッファプールを走査して目的デー
タ資源が既にバッファ上にあるかを調べる。バッファプ
ール中に目的データ資源がない場合は、空きのバッファ
を確保してデータ資源を読み込む。また、サブシステム
は、データ資源に対する必要な更新を完了し、そのデー
タの内容をファイル装置に反映した後に、ロックマネジ
ャに対して、アンロック要求を発行してロックを解放す
る。本実施例では、バッファ管理テーブルと、そのバッ
ファ中に格納されているデータ思源に対応するデータ資
源テーブルの間に双方向のポインタチェーン設定するこ
とにより、ロックマネジャとバッファマネジャの連携を
実現している。第９図においては、データ資源ａ１はサ
ブシステム１のローカルバッファプール中のバッファｂ
ｌｌとサブシステム２のローカルバッファプール中のバ
ッファｂ２１に格納され、データ資源ａ２は、サブシス
テム１のバッファｂ１２だけに格納され、データ資源ｂ
１はサブシステム２のバッファｂ２２だけに格納されて
いる例が示されている。第１の実施例では、データ資源
に対するローカルロックが全て解放されてしまえばデー
タ資源テーブルの解放を行ったが、第２の実施例におい
ては、データ資源テーブルは、ローカルロックが全て解
放されかつそのデータ資源が自データ処理装置内の全て
のサブシステムのローカルバッファプールから追い出さ
れた時点で解放される。逆に、バッファ中にデータ資源
が読み込まれるときは、前もって必ずそのデータ資源に
対するロックが確保されており、したがって、対応する
データ資源テーブルは既に作成されている。

ローカルバッファ間のデータ内容の同期方法は、１デー
タ処理装置内での複数サブシステム間の同期処理と複数
データ処理装置間での同期処理に分けられる。まず、同
一データ処理装置内でのサブシステム間のバッファ同期
について第１９図に示す流れ図にしたがって説明する。

バッファマネジャは、自ローカルバッファ上でデータを
更新すると、バッファ管理テーブルからデータ資源テー
ブルをたどって（ステップ１９０１）同一データ処理装
置内の他のサブシステムのローカルバッファプール中に
当該データ資源が格納されていないかを確認する（ステ
ップ１９０２）。もし他のサブシステムのローカルバッ
ファに格納されていれば、そのサブシステムのバッファ
マネジャをコールしてそのバッファ内容を無効とするよ
うに要求する。

第９図において、サブシステム１がバッファｂｌｌの内
容を更新したときがこれに相当する。

この場合、サブシステム１のバッファマネジャは、バッ
ファ管理テーブル１７１からデータ資源テーブル１５５
をたどり、データ資源ａ１がバッファｂ　’２１にも格
納されていることを知る。そこで、サブシステム１のバ
ッファマネジャはサブシステム２のバッファマネジャを
コールし、バッファｂ２１の内容を無効にすることを要
求する。このとき、サブシステム１はデータ資源ａ１を
更新するためにＥＸモードのロックを確保しており、サ
ブシステム２においては、データ資源ａ１に対するアク
セスは存在しないか、ロック待ちになっている。サブシ
ステム２でデータ資源ａ１に対するアクセスが行われる
と、そのデータ資源が格納されていたローカルバッファ
の内容は無効化されているため、ファイル装置から最新
の内容が読み込まれる。これに対し、サブシステム１が
バッファｂ１２に格納されているデータ資源ｂ１２を更
新した場合は、サブシステム１のバッファマネジャは、
バッファ管理テーブル１７２からデータ資源テーブル１
５６をたどって、他のサブシステムのバッファ中にはデ
ータ資源ｂ１は格納されていないことを認識できるので
、サブシステム２のバッファマネジャをコールすること
はない。

次に、データ処理装置間でのバッファ内容の同期方法に
ついて説明する。本実施例では、データ処理装置間での
バッファ同期を行うため、第１０図に示すように、ハツ
シュクラスに属するデータ資源に対する更新の発生を記
憶しておくための更新同期マツプをグローバルロック管
理テーブルエントリ中に設けている。グローバルロック
管理テーブルエントリの他のフィールドについては、第
４図で示したものと同じである。更新同期マップは、デ
ータ処理装置対応に１ビツトを割当てたビットマツプで
ある。この更新同期マツプの使いかたを第２０図に示す
流れ図しこしたがって説明する。

ロックマネジャは、グローバルロック獲得処理において
ロック対象ハツシュクラスに対応するグローバルロック
管理テーブルエントリを拡張記憶から主記憶に転送して
くる（第１４図のステップ１４０１）。ここで、グロー
バルロック管理テーブルエントリ中の更新同期マツプを
退避しておき（ステップ２００１）、グローバルロック
が確保できたならば、テーブルエントリ中の更新同期マ
ツプの自データ処理装置に対応するビットをオンにする
（ステップ２００２）。確保したグローバルロックのモ
ードがデータ更新のためのものであれば（ＳＵ、ＰＵ、
ＥＸモード）更新同期マツプの他データ処理装置に対応
するビットを全てオフにする（ステップ２００３．ステ
ップ２００４）。

更新同期のマツプのビットがオンであるということは、
対応するデータ処理装置上のサブシステムが当該ハツシ
ュクラスに属するデータ資源を自分のローカルバッファ
プール中に格納している可能性があることを意味してい
る。ステップ２００１で退避した更新同期マツプにおい
て、自データ処理装置に対応するビットがオフであれば
、他データ処理装置で当該ハツシュクラスに属するデー
タ資源を更新した可能性があるため、ロックマネジャは
、自データ処理装置内で動作しているサブシステムのロ
ーカルバッファプール上の当該ハツシュクラスに属する
データ資源を格納しているバッファを無効とするようサ
ブシステムのバッファマネジャに要求する（ステップ２
００５．２００６）。

上記要求を受けたバッファマネジャは、そのバッファが
現在使用中でなければ即時にバッファを無効とするが、
バッファが使用中であれば無効化を行わない。これは、
バッファが使用中であるということは、そのバッファに
格納されたデータ資源に対するロックを自サブシステム
が保有しているということであり、そのデータ資源を他
データ処理装置上のサブシステム□が更新するというこ
とは起こりえないからである。データ処理装置間でのバ
ッファ更新同期処理は、個々のデータ資源単位でなくハ
ツシュクラス単位で行われるため、本来は不要なバッフ
ァの無効化を引き起こす可能性がある。このようなサイ
ドエフェクトが発生する確率は、グローバルバッファ管
理テーブルエントリの要素数を大きくし、ハツシュクラ
スとデータ資源の対応を１対１に近付けるほど小さくな
ることは、グローバルデッドロックの場合と同じである
。

以上で説明した同一データ処理装置内の複数サブシステ
ムのローカルバッファプール間でのデータ更新の同期方
法と、データ処理装置間でのデータ更新の同期方法を組
合せることにより、全てのサブシステムのバッファプー
ルの内容の整合性を保つことが可能となる。

（２−２）ジャーナル管理 本実施例では、各サブシステムはジャーナルファイルを
備え、自サブシステムで行ったデータの更新をジャーナ
ルレコードとして記録している。

共用のファイル装置が故障して、格納されたデータが使
用不可能になった場合は、ある時点でのフ＝６０− アイル装置の内容のバックアップコピーとジャーナルフ
ァイルに記録されたデータ更新の内容を時系列にマージ
してファイル装置の内容を回復する。

本実施例のように複数のサブシステムがデータ資源を共
用して更新を行うようなシステムにおいては、各々のサ
ブシステムごとに独立して記録されたジャーナルレコー
ドを時系列にマージする必要がでてくる。本実施例では
、共用の拡張記憶上にカウンタエリアを設け（第８図の
４３）、全サブシステムがデータの更新ごとにこのカウ
ンタ値を増加させ、ジャーナルレコード上にそのカウン
タ値を記録することにより、全サブシステムが行ったデ
ータの更新を一意的な時系列順に並べることを可能とし
ている。また、このカウンタを用いればジャーナルレコ
ードをマージした結果において必要なジャーナルレコー
ドが抜けていないかを容易に判定することができる。

〔発明の効果〕

以上述べたように、本発明によれば、複数データ処理装
置によるデータ資源の共用が、特別な制御装置を用いる
ことなく、かつ小さな通信オーバヘットで実現できるの
で、経済的で高性能なデータベース共用システムを構築
できる。また、本発明によれば、複数データ処理装置の
またがるデッドロックの検出を少ないオーバヘッドで行
えるので、システムの可用性を高める事ができる。また
、本発明によれば、システムに各種の故障が発生した場
合、データ資源を選択的にアクセス禁止にできるので、
データの保全性を保つことができる。

また、本発明によれば、各サブシステムはバッファプー
ル中のデータの有効性を少ないオーバヘッドで判断でき
るので、データ資源の共用環境下でもバッファリング手
法を用いる事ができる。さらに、本発明によれば、各サ
ブシステムが取得したジャーナルレコードを容易に時系
順に並べる事ができるので、共用のファイル装置が故障
してデータ資源が失われた場合でも、即時にデータの回
復が行え、システムの信頼性、可能性を高めることがで
きる。

【図面の簡単な説明】

第１図は本発明の第１の実施例を示すコンピュータシス
テムのブロック図、第２図はローカルロック管理テーブ
ルを示す図、第３図はグローバルロック管理テーブルを
示す図、第４図は第１の実施例におけるグローバルロッ
ク管理テーブルエントリを示す図、第５図はロックモー
ドの両立性の一覧性を示す図、第６図はロックモードの
包含性の一覧表を示す図、第７図はグローバルデッドロ
ックの例を示す図、第８図は本発明の第２の実施例を示
すコンピュータシステムのブロック図、第９図はロック
管理テーブルとバッファ管理テーブルの関連を示す図、
第１０図は第２の実施例におけるグローバルロック管理
テーブルエントリを示す図、第１１図〜第１７図はロッ
クおよびアンロック処理の流れ図、第１８図はデッドロ
ック検出処理の流れ図、第１９図〜第２０図はバッファ
間更新同期処理の流れ図である。 １０：通信装置 ２０．３０：データ処理装置 ２１〜２２．３１〜３２：サブシステム２３．３３：ロ
ツクマネジャ ２４．３４：ローカルロック管理テーブル２５〜２６．
３５〜３６二ローカルバツフアプール ４０：拡張記憶装置 ４１ニゲローバルロツク管理テーブル ４２ニゲローバルバツフアプール ４３：カウンタ ５ｏ：ファイル装置 ６１〜６４：ジャーナルファイル １００：マスク管理テーブル １１０：サブシステムテーブル １２１〜１２４ニドランザクジヨンテーブル１３０：資
源クラステーブル １４１〜１４８：ハツシュクラステーブル１５１〜１５
７：データ資源テーブル １６１〜１６９：ロックテーブル １７１〜１７４：バッファ管理テーブル２００：拡張記
憶のブロック ２１０ニゲローバルロック管理テーブルエンドリ 第１６図 第１７図 第１８図 第１９図

Claims (1)

1. 【特許請求の範囲】 １、命令プロセサおよび該命令プロセサによって共用さ
   れる主記憶装置を含むデータ処理装置の一群と、該デー
   タ処理装置を相互接続する通信装置と、該データ処理装
   置により共用されるデータ資源を記憶する拡張記憶装置
   と、ファイル装置とを備え、かつ上記データ処理装置は
   各々、上記データ資源をアクセスするサブシステムと、
   該サブシステムの共用データ資源へのアクセスに対する
   排他制御を行うロックマネジャとを具備したコンピュー
   タシステムにおいて、個々の上記共用データ資源に関す
   る排他制御情報を主記憶上に保持するとともに、クラス
   タリングされた共用データ資源に関する排他制御情報を
   共用拡張記憶上に保持し、各ロックマネジャは、上記主
   記憶上の排他制御情報を使用して自データ処理装置内で
   のサブシステム間の排他制御を行うとともに、上記共用
   拡張記憶上の排他制御情報を使用して、データ処理装置
   間での排他制御を行うことを特徴とするシステム間デー
   タベース共用方法。 ２、上記ロックマネジャは、サブシステムからのロック
   要求を受け付けると、上記主記憶上の排他制御情報を参
   照してデータ処理装置間の排他制御が必要であるかどう
   かを判断し、もし必要であれば上記共用拡張記憶上の排
   他制御情報を操作してデータ処理装置間でのロックを確
   保した後に上記主記憶上の排他制御情報を操作してサブ
   システムにロックを与え、もし必要でなければ上記主記
   憶上の排他制御情報を操作してサブシステムにロックを
   与えることを特徴とする請求項１記載のシステム間デー
   タベース共用方法。 ３、上記ロックマネジャは、上記主記憶および共用拡張
   記憶上の排他制御情報を参照して、複数データ処理装置
   にまたがったデッドロック発生の可能性を検出し、デッ
   ドロック発生の可能性がある場合は、関連する他のデー
   タ処理装置に連絡を行って実際にデッドロックが発生し
   ているかを確認することにより複数データ処理装置間で
   のデッドロックを検出することを特徴とする請求項１記
   載のシステム間データベース共用方法。 ４、上記ロックマネジャは、システムに各種の故障が発
   生した場合、上記主記憶および共用拡張記憶上の排他制
   御情報を使用して、データ資源の整合性を保持するよう
   に、選択的にデータ資源をアクセス禁止にすることを特
   徴とする請求項１記載のシステム間データベース共用方
   法。 ５、上記サブシステムは各々、共用データ資源へのアク
   セスを実行するためのバッファマネジャとバッファプー
   ルを備え、上記ロックマネジャおよび上記バッファマネ
   ジャは、サブシステムが実行したデータ資源に対する更
   新の発生を上記主記憶および共用拡張記憶上の排他制御
   情報を利用して他サブシステムに通知してバッファプー
   ル内容の整合性を保持することを特徴とする請求図１記
   載のシステム間データベース共用方法。 ６、上記共用拡張記憶上に全サブシステムによって参照
   および更新されるカウンタを設け、サブシステムは各々
   そのカウンタ値をジャーナルレコードに記録することに
   より、そのカウンタ値をキーとして複数サブシステムが
   取得したジャーナルレコードを時系列に並べることを可
   能とすることを特徴とする請求項１記載のシステム間デ
   ータベース共用方法。７、請求項１〜６のいずれかに記
   載された、システム間データベース共用方法のための制
   御情報を記憶する共用拡張記憶装置。