JPH01211140A - データ資源アクセス方法 - Google Patents

Abstract

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

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は同時に１つの又は２つ以上のプログラムを実行
する汎用ディジタル計算システムを動作させる方法に関
する。更に詳細に説明すれば１本発明は任意のアクセス
される資源の情報状態の複製物間のコヒーレンシーを維
持しながら選択的にロック可能なデータ資源に対し並行
的に実行するプロセスのスループットを増大させること
に関する。

Ｂ、従来技術 多くの作業単位またはサブタスクが同じレコードのアク
セスを共有する必要があるハイエンドのデータ共有シス
テムでは、最短応答時間が得られることが保証されるよ
うにレコード／データに対する並行アクセスを管理する
必要がある。短かい応答時間はマルチプログラミング・
レベルを低下させ、該システムにおける他の資源との競
合を減する。データを共有するシステム数が２つ以上に
なると適切な管理の必要性はずっと大きくなる。

ハイエンド・システムではデータベースｌ１０（入力／
出力）は遅延原因のかなりの部分を構成する。Ｉ１０遅
延は２つの主要な源から発生する。

第一は記憶されている媒体（ディスク）からのデータブ
ロックの読取りに関する遅延である。第二は１つのシス
テムがデータブロックを変更（更新）し［ブロック無効
化］、それにより複製されたコピーを無効にするときの
他のユーザーへの通報に関する遅延である。

データ資源の共有を管理する１つの従来の方法はオバー
マーク　（Ｏｂｅｒｍａｒｃｋ）、外による米国特許第
４３９９５０４号に開示されている。この方法−２つの
システムがデータ共有に関係する場合に最も効率的であ
る−は、資源のロックを獲得し開放するためにＩＢＭ情
報管理システム（ＩＭＳ／ＶＳ）バージョン１をＩＭＳ
／ＶＳ資源り、／り・マネジャー（ＩＲＬＭ）と共に用
いる。　　ＩＭＳ／ＶＳプロセス／ユーザーがそのＩＲ
ＬＭを要求すると、ＩＲＬＭは通信を伴わずに要求を許
可することができるかどうかを調べる。もしそうなら、
要求は直ちに処理され、プロセス／ユーザーは続行する
ことが許可される。もし通信が要求されるなら、要求は
送信のためキューされ、資源が開放されて要求が再開始
できるようになるまでプロセス／ユーザーは延期される
。ＩＢＭ３０８４システム対の場合には、遅延は３〜２
３ミリ秒の範囲になることがある。

Ｃ１発明が解決しようとする問題点 該方法は単一の更新者と複数の同時読取者を許可する。

しかしながら、資源を更新するプロセス／ユーザーは、
他のシステムが古いバージョンからのデータを使用する
のを妨げるために、該更新を他のシステムにも利用可能
にしなければならない、この要求は第３図に関連して明
白に示すように幾つかの問題を生ずる。第３図はプロセ
ス／ユーザーが共有資源上のレコードを更新するのを許
可するのに必要な従来技術の簡略化されたステップのシ
ーケンスを表わす、プロセス／ユーザーが存在するシス
テムは、最初にロック（１００）を取得し、所望のレコ
ードを含むブロックをＤＡＳＤからバッファ（１０２）
に読込まなければならない、そしてプロセス／ユーザー
は、その更新、を開始する前に、バッファされたブロッ
クでそれ自身のロック（１０４）を取得する。プロセス
／ユーザーが同じブロックで複数のレコードを更新しな
ければならないとき１つの問題が生ずる。

例えば、前述のように、もし幾つかのプロセス／ユーザ
ーが同じブロックでレコードを更新しなければならない
なら、上記米国特許に記載の方法は各プロセス／ユーザ
ーが該ブロックで該レコードを更新することを必要とす
る。各プロセス／ユーザーがコミットする前に、該方法
は更新されたブロックがＤＡＳＤ　（１１２）に再書込
みされ。

同じブロック（複製物）の他の保持者に、該ブロックが
変更されていることを示す回報メツセージ（１１０）が
後続することを必要とする。この事象シーケンスはブロ
ックを更新するプロセス／ユーザー毎に反復される。

ＩＭＳ／ＶＳによって使用される上記米国特許記載の方
法は”コミットを強制する”方式とじて記述されている
ものである。前述のように、該方式は更新を行なうシス
テムに強制してＤＡＳＤに変更されたブロックを書込み
、無効メツセージを他のシステムに送出し、肯定応答を
待ってからプロセス／ユーザーがそれ以後の更新を続け
るのを許可する。同じブロックに対し複数の更新を要す
るプロセスの場合には、ユーザーは一般にＤＡＳＤ書込
み毎に最小限平均２５ミリ秒のＤＡＳＤアクセス時間の
費用を支払わなければならない。

各ブロックのコピーを保持するシステムのリストが維持
されるデータ共有システムのバッファ・プールを管理す
る従来技術の方法はＩＢＭ技術報告　（Ｔｅｃｈｎｉｃ
ａｌ　Ｂｕｌｌｅｔｉｎ）、ダイアス　（Ｄｉａｓ）、
”同時制御の統合に関する設計及び分析（Ｄｅｓｉｇｎ
　ａｎｄＡｎａｌｙｓｉｓ　ｏｆ　Ｉｎｔｅｇｒａｔｅ
ｄ　Ｃｏｎｃｕｒｒｅｎｃｙ　Ｃｏｎｔｒｏｉ）”、Ｖ
ｏｌ、１８．ＮＯ，５，１９８６年３月、ｐ、４６４２
に記載されている。ダイアスのロック・マネジャーは記
憶装置にあるブロックの有効なコピーを保持するシステ
ムのリストを含む、この方法はバッファ・プールでブロ
ックを検査する前にプロセス／ユーザーがブロック上の
共有ロックを取得することを必要とする。ロック・マネ
ジャーは記憶装置にバッファされたブロックが有効であ
るかどうかを示す、もしブロックが有効ではないことが
わかれば、最新レベルのブロックがバッファ・プールに
あることを保証するため、バッファ・マネジャーはブロ
ックを再読取りする。ブロックを更新するには、プロセ
ス／ユーザーは該ブロックに排他的ロックを保持しなけ
ればならない、それは、コミット（更新）時刻に、”有
効なコピーを有する°“リストから全ての他のシステム
を除去する要求をロック・マネジャーに送り、その排他
的ロックを開放する。該方法は全てのロックが他のシス
テムとの通信を必要とするという欠点がある。その結果
、プロセスはメツセージの伝達のための余分な遅延及び
−時停止／再開始のための余分な経路長を伴うことにな
る。もう１つの不利点はロッキングがブロック・レベル
で実行されなければならないので異なるプロセス／ユー
ザーによる同じブロックの同時読取り及び更新はたとえ
プロセスが同じシステムでランしていても許可されない
ことである。

Ｄ０問題点を解決するための手段 本発明の目的は同じか又は異なる中央電子システムで複
数のユーザーによるデータ資源の同時アクセスを制御す
る方法を改善することである。

更に本発明の目的はアクセスされた資源の情報状態の複
製物間のコヒーレンシーを維持しながらデータ資源の選
択的にロック可能な部分に対し同時に実行するプロセス
のスループットを大きくすることである。

更に本発明の目的はＮ経路のデータ共有におけるレコー
ドのロック及びバッファの無効化を効率的に支援し、ト
ランザクション優先の環境で資源の変更の通知及びロッ
クを保持する他のプロセスとの調整を続行することであ
る。

更に本発明の目的はロックにより同期されているデータ
の処理と並行するロック要求にサービスすることである
。

前記及びその他の目的、特徴及び利点は本明細書で開示
される方法により実現される。共有データ資源（即ちデ
ータ・ブロック）のアクセスを要求する複数のユーザー
は該資源の読取りないしは書込みロックを要求する必要
がある。一般に、本発明に従って、たとえブロックがユ
ーザーの一人によって更新中のプロセスにあっても、複
数ユーザーは同時に同じブロックに対し読取りアクセス
することができる。しかしながら、該ブロックの更新ロ
ックを保持するシステムのユーザーしか該ブロックを更
新することができない、更に詳、ＩＪｌｌに説明すれば
、所与のロック要求に応答して、要求しているプロセス
／ユーザーが存在するシステムの資源における利害関係
状態（即ちＵＰＤＡＴＥ又はＲＥＡＤ）を確立する判定
動作が開始される。この判定動作は資源をアクセスしシ
ステム内の資源の所望の部分をバッファするのに必要な
動作と並行する１次いで処理が開始され要求元のユーザ
ーに対するロック要求を選択的に許可ないしは拒否する
。

もし処理が更新ロックの許可を生ずるなら、システムは
バッファされた資源にメツセージを付与し、該バッファ
された資源を要求している他のシステムのリストを作成
・維持且つ更新する。該バッファされた資源の更新は資
源ロック・マネジャーに報告する。該マネジャーは更新
されたシステムのリストを用いて、該バッファされた資
源の複製物を保持している各システムに資源変更の通知
を回報通信する。資源をバッファしているシステムは。

同報通信されたメツセージの受領の肯定応答を受取ると
、該データ資源の部分のロックを開放する。

Ｅ、実施例 本発明は記憶装置１通信及び計算機能のような計算資源
の最適利用にもかかわらず完全性及び障害からの回復可
能性を維持しながらデータ資源を共有する汎用コンピュ
ータを動作させる方法を提供する。

第２図は直接アクセス記憶装置（ＤＡＳＤ）１３．１４
に記憶されたデータのアクセスを共有する最大Ｎの中央
電子システム（ＣＥＣ）１１．１２　（ｆｍ略化のため
２つのシステムだけを示す）を含むことがある典型的な
システムを表わす、各システム１１．１２内にはホスト
・オペレーティング・システム２１，２２；少なくとも
１つの管理システム／トランザクション・プロセッサ３
１〜３４：管理システム／トランザクション・プロセッ
サ毎のバッファ・プール４１〜４４：データベース回復
制御（ＤＢＲＣ）システム５１．５２；及び資源ロック
・マネジャー（ＲＬＭ）６１．６２を含む多数のデータ
記憶及びプログラム領域を有する実アドレス空間又は仮
想アドレス空間がある。

各管理システム／トランザクション・プロセッサ３１〜
３４はトランザクション・ログ・ディスクの１つと通信
するのに適合する。システム１１．１２は通信制御装置
により（または代りにチャネル対チャネルのアダプタに
より）相互接続され、共有ＤＡＳＤ１３．１４及び制御
データセット５７を介して疎結合される。

各ＣＥＣ１１，１２は一主記憶及び仮想記憶装置、並び
に必要なチャネル及び周辺装置と共に−ＩＢＭ３０８４
ないしは１８Ｍシステム／３７０のような汎用中央処理
装置から成る。その構成はＧ、Ｍ、アムダール（Ａｍｄ
ａｈｌ）、外の米国特許第３４００３７１号に記載され
ている。

各システム１１．１２は１８Ｍシステム／３７０　ＭＶ
Ｓオペレーティング・システムのようなオペレーティン
グ・システム２１．２２の制御の下に動作する。管理シ
ステム／トランザクション・プロセッサ３１〜３４はそ
れぞれのオペレーティング・システムの制御の下に実行
し、通信制御装置２７−例えば、ＩＢＭ３７０５通信制
御装置かもしれない−とのインタフェースに、これらの
オペレーティング・システム機構を利用する。

各ＣＥＣのＤＢＲＣモジュール５１．５２はＩＢＭ３３
５０のような直接アクセス記憶装置に存在することがあ
る制御データ・セット５７を共有する。　ＤＢＲＣの例
はカー（Ｃａｒｒ）、外の米国特許第４４８０３０４号
に記載された発明により計算システムを作動させるよう
に変更されたＩＢＭ　ＩＮＳ／ＶＳデータベース回復制
御機構である。

第２図により、２つのＣＥＣＩＩ、１２を含む典型的な
計算システムの動作について説明する。障害状態は存在
しないものと仮定すると、多重プログラミング環境で各
ＣＥＣ−それぞれは管理システム／トランザクション・
プロセッサ３１〜３４の制御下にある−の少なくとも１
つのアプリケーション・プログラム（図示せず）が実行
される。

例えば管理システム／トランザクション・プロセッサ３
１の制御の下に実行するプロセス／ユーザーが、例えば
０ＡＳＤ１３に存在するデータ資源の一部分のアクセス
を必要とするとき、管理システム／トランザクション・
プロセッサ３１は、制御経路３５で示すような、対応す
るＲＬＭ６１との通信のためロック要求を起こす、ロッ
ク要求はＵＰＤＡＴＥロック要求ないしは５ＨＡＲＥロ
ツク要求から成ることがある。

ＵＰＤＡＴＥロックは資源が変更される場合に要求され
、５ＨＡＲＥロツクは読取りの場合に要求される。

ロック要求を処理する際、ＲＬＭ６１は利害関係マネジ
ャー（ＩＭ）１０により制御／データ経路２５．２１．
２３．２７．２４．２２．２６に沿ってＲＬＭ６２と通
信することができる。　ＲＬＭはロックを要求するとき
非同期ロック方式を利用する。これはシステムがＤＡＳ
Ｄ１３からブロックを読取るために支払わなければなら
ない遅延とロックを得るのに関連した応答時間遅延とを
オ−バッファすることを可能にする。非同期方式を用い
る場合、ロック要求を解決するのにもしプロセッサ間の
通信が必要ならＲＬＭ　６１は即値表示を管理システム
／トランザクション・プロセッサ３１に返送する。

ロック要求が終了すると、非同期要求の発行者−本実施
例では管理システム／トランザクション・プロセッサ３
１−はＲＬＭ６１により動作の続行を許可され、該要求
が成功したか失敗したかが通知される。その結果、管理
システム／トランザクション・プロセッサは必要とする
所望の資源の該部分を物理的に読取り、システム内にバ
ッファする動作を開始することができる。プロセッサ間
の通信を必要とするか避けられるかの状態については、
ロックを許可するステップに関連してあとで詳細に説明
する。システムのＩＭＩＯに１つの事例がある。各ＲＬ
Ｍ６１．６２はＩＭＩＯとの通信セツションを確立する
。　ＩＭＩＯはＲＬＭ６１．６２の間のロックを調停す
る。

各ＲＬＭ６１．６２は仮想記憶装置の詳細なロック情報
の表を維持する。　ＩＭＩＯもそれ自身のロック表を仮
想記憶装置に維持し、個々のトランザクション・レベル
でよりもＲＬＭレベルでロック所有権を追跡する。

ロック要求がＩＭＩＯへのメツセージ送信を要求すると
、ＲＬＭ６１．６２は通常は要求元のプログラムに待機
するよう告げる。要求処理が完了すると、ＲＬＭ６１゜
６２は要求者に再開するように告げる。非同期ロックに
より、　ＲＬＭ６１．６２は要求者にいつ■旧Ｏへのメ
ツセージが必要かを告げ、該結果の要求者に■旧Ｏから
の応答がいつ返送されるかを知らせる。

非同期のロック要求を実現する重要な局面はロック要求
処理が過去のある時点でロック表の状態に対して実行さ
れなければならないことである。

例えば、もしプロセッサＡが時刻Ｔ１でオブジェクトに
対する更新ロックを取得し時刻Ｔ２でそれを開放するな
ら、たとえ実際の処理が時刻Ｔ２後に生ずる場合でも、
そのオブジェクトに対し時刻Ｔ１とＴ２の間で行なわれ
るロック要求はどれも拒否されなければならない。

それ以後のロック要求の処理を可能にするためには、こ
の方式はロック活動記録と呼ばれる、保持された過去の
ロックの符号化に依存する。該記録は、それが控えめで
ある（即ち、該記録よりも多くのロックが保持されてい
てもよいが、該記録よりも少ないロックが保持されては
ならないことを意味する）限り、不正確であっても許さ
れる。

正確さが低い活動記録の場合には、空間オーバヘッドが
少なくなり、より簡単なアルゴリズムを用いて要求を検
査することができる。正確さが高い活動記録の場合には
、許可されているべき要求を拒否する見込みが少なくな
る。ロック活動記録は複数のプロセッサ間で比較される
時刻ステップを含むので、ある種のクロック同期が必要
である。

非同期ロック・アルゴリズムは３つの構成要素：同期論
理クロック、保持されたロックの過去の状態を符号化す
る手段、及び互換性を検査する手段から成る。これらの
３つの構成要素について以下に説明する。

同期論理クロックは整合された時間の表示を維持するの
に使用される。該クロックはＴＭ（利害関係マネジャー
）によって制御される。メツセージがＲＬＭ　　（資源
ロック・マネジャー）に送られる毎に、　ＩＭはクロッ
クを増訂数し、その結果をメツセージに記憶する。

ＲＬＭはＩ１４からメツセージを受取ると、入ってくる
クロック値とそれ自身のクロックを比較する。

もし入ってくる値の方が大きければ、その値は新しいク
ロック値として記憶される。　ＲＬＭは他の方法でその
クロック値を変えることはない。

このクロック・アルゴリズムの結果、ＩＭのクロックの
値は常に少なくともＲＬＭのクロックの値と同じ大きさ
である。この特性は非同期のロック・アルゴリズムの正
確さにとって非常に重要である。

全ての活動記録の符号化はＩＮで行なわれる。その方法
として、ロック表の要素はそれらに対する最後のＵＮＬ
ＯＣＫ動作を過ぎても保持される。ロック表の古い活動
記録の要素は定期的に削除され、記憶オーバヘッドを制
限する。活動記録情報も活動状態のロックに必要とする
ことがある。　ＲＥＡＤモードに格下げされるＵＰＤＡ
ＴＥモードに保持されたロッりの場合について考慮され
たい。

活動記録を表わすには、各ロック素子は２つの余分なフ
ィールド二ロックに対する最後のＵＮＬＯＣＫ動作の時
点のＩＭの論理クロック値、最後のＩＮＬＯｃにを実行
したＲＩＪのＩＤを含む、これらのフィールドは下記の
ように宣言される： ＤＥＣＬＡＲＥ Ｉ　ＬＯＣＫ。

２　ＬＯＣＫＴＩＭＥ　ＦＩＸＥＤ（３２）、　／＊最
後ノＵＮＬＯＣＫ（７）論理時刻零／ ２　ＬＯＣＫＵＬＩＤ　ＦＩＸＥＤ（８）、　　／本最
後にアンロックしたＲＬＭ　１０又はθネ／ 新しいロックが生ずると、　ＬＯＣＫＴＩＭＥとＬＯＣ
ＫＵＬＩＤは０に初期設定される。　ＵＮＬＯＣにがロ
ックに対して実行されるとき、下記のアルゴリズムが使
用される。ＣＬＯＣにはＩＮの論理クロック値であり、
ＲＥＱＬＭＩＤはアンロックするＲＬＭの独特のＩＤで
ある。

ｉｆ　ＬＯＣＫＵＬＩＤ　＝ＲＥＱＬＭＩＤ　ｏｒ　Ｌ
ＯＣＫＴＩＭＥ　＝　ＯｔｈｅｎＬＯＣＫＵＬＩＤ　＝
　ＵＮＬＯＣＫ者のロックマネジャーＩＤ；１ｓｅ ＬＯＣＫＵＬＩＤ　　＝　　Ｏ； ＬＯＣＫＴＩＭＥ　　＝　　ＣＬＯＣに；註：もし単一
のＲＬＭがこの口、ツクのＵＮＬＯＣＫを実行している
なら、ＬＯＣＫＵＬＩＤは意味がある。さもなければ、
ＬＯＣＫＵＬＩＤは０である。

古い活動記録を除去するため定期的にロック表の掃引が
実行される。しきい値が選択され、しきい値よりも古い
活動記録情報が削除される。削除されている最新の活動
記録情報の論理クロック値は互換性検査のため保持され
る。

下記で、　５ＷＥＥＰは削除されている活動記録の最高
の論理クロック値を含むＩＭにおける入城変数である。

　５ＷＥＥＰは遅れた要求に対して防護するため互換性
検査により使用される。ロック表で要素毎に実行される
掃引アルゴリズムを下記に示す：ｉｆ　ＬＯＣＫ’ＴＩ
ＭＥはＯに等しくなく且つＣＬＯＣＫ　−［、ＱＣＫＴ
ＩＭＥはＴＨＲＥＳＨＯＬＤよりも大きいｔｈｅｎ　ｄ
ｏ；５ＷＥＥＰ　＝　ｎ＋ａｘ（ＳＷＥＥＰ、　ＬＯ（
ＪＴＩＭＥ）；ＬＯＣＫＴＩＭＥ　　＝　　０； ＬＯＣＫＵＬＩＤ　　＝　　ｏ； ｉｆ　　要素に対しロックが保持されていない　ｔｈｅ
ｎロック表から除去する； ｅｎｄ； 要するに、活動記録情報は下記から成る：・あらゆる°
゛最近００ツクに対する最後のＵＮＬＯＣにの論理時刻 ・ロックが１つしかなかった場合のロックに対する最後
のＵＮＬＯＣＫを実行したＲＬＭ　１０・破棄されてい
る活動記録情報の最新の論理時刻を含む５ＷＥＥＰ変数 各非同期ロック要求はそれが発行される時刻にＲＬＭの
論理クロック値によりスタンプされる。ある時点で、た
ぶん幾つかの非同期要求収集後に。

ＲＬＭは要求をＩＭに送る。　ＩＮの互換性検査は下記
を確認しなければならない： ・要求はロックの現在の保持者と互換性がある。

・要求はロックの”既知の”活動記録と互換性がある。

・要求はロックの削除された活動記録と互換性がある。

註：ロック毎の最後のＵＮＬＯＣＫの時刻だけが記憶さ
れる。従って、アルゴリズムは活動記録の時刻よりも小
さいか又は該時刻に等しい論理クロック値を有するロッ
クを許可してはならない、しかしながら、もしＬＯＣＫ
ＵＬＩＤが該要求のＲＬＭ　ＩＤに一致するなら、該ロ
ックは許可することができる。

もし入ってくる要求がｓｗＥＥＰ　（破棄された最新の
活動記録）よりも小さいか又はそれに等しい論理時刻を
有するなら、ロック表は必要な情報を含まない、この場
合、要求は拒否される。

これらの規則をまとめると下記のコード・セグメントに
なる。　ＲＥＱＴＩＭＥは要求が出たときのＲＬＭの論
理値である。　ＲＥＱＬＭＩＤは要求者のＲＬＭ　ＩＤ
である１両者はＲＬＭによりＩＭに送られたメツセージ
にあるフィールドである。

ｉｆ　ＲＥＱＴＩＭＥは５ＷＥＥＰよりも小さいか又は
等しいｔｈｅｎ　　要求を拒否する： ｅｌｓｅ　ｄｏ； ロックを探索する； ｉｆ見つかった　ａｎｄ　（（ＲＥＱＴＩＭＥはＩ、Ｏ
ＣＫＴＩＭＥよりも小さいか又は等しく且つＲＥＱＬＭ
ＩＤはＬＯＣＫＵＬＩＤに等しくない）　　ｏｒ要求は
保持者と互換性がない）　ｔｈｅｎ　ｄｏ； 要求を拒否する； ｌｓｅ 要求を受諾する ｅｎｄ； ■旧まＰＯ５Ｔ　ＭＥＳＳＡＧＥ（ＰＯ５ＴＭＳＧ）　
を実現する。　ＰＯ５ＴＭＳＧはロックされた資源に対
する動作であり、それによって、更新ＲＬＭは同じ資源
のロックを有する他の全ての保持者にメツセージを送る
。更に。

該メツセージは管理システム／トランザクション・プロ
セッサによりバッファされる資源に付与される。メツセ
ージは資源のコピーを現に保持するシステムにいつ変更
が生じたかを知らせる。更に、バッファされた資源のロ
ックを次に取得するシステムは、ＤＡＳＤには現在のバ
ージョンがないことを知らされる。もし既にメツセージ
が付与されているバッファされた資源にメツセージが送
られていれば、現存するメツセージは破棄され新しいメ
ツセージが付与される。新しいメツセージは該資源のロ
ックを保持している他のＲＬＭにも送られる。

全ての関連したシステムが該メツセージを肯定応答した
とき、ＰＯ５ＴＭＳＧは要求者、管理システム／トラン
ザクション・プロセッサに完了を知らせる。

更に要求者は該メツセージを受取った他のロック保持者
数のカウントを受取る。障害時の使用可能性を保証する
ためメツセージはその有効期間のあいだ２つのシステム
のなかに存在する。

ＲＬＭはロックを許可するのに階層ロック方式を用いる
１階層ロックでは、管理システム／トランザクション・
プロセッサはロック名を体系化して論理階層に入れる。

その結果、管理システム／トランザクション・プロセッ
サはロックを取得できるようになる前に、予め親ロック
を保持しなければならない１種々のシステムのＲＬＭは
論理階層のどの部分にＲＬ１４がロックを保持するかを
（管理システム／トランザクション・プロセッサの局所
的な段階に代わって）追跡するためＲＬＭ自身のあいだ
で通信する。単一のＲＬＭが階層のサブトリー（ｓｕｂ
ｔｒｅｅ）にロックだけを保持するときは、そのＲＬＭ
は該サブトリーの根ロックと唯一の利害関係を有する。

唯一の利害関係とは、所有するＲＬＭが単一利害関係サ
ブトリーの範囲内で、他のＲＬＭとの通信を行なわずに
、ロックを取得できることである。　ＲＬＭは、どの時
点でも、多くのサブトリーで唯一の利害関係を有するこ
とがある。

データ共有システムのプロセッサはそれぞれ旧。

にコードのコピーをランし、局所的に生じたロック要求
を処理する。　ＲＬＭも該システムの成る計算機に存在
する単一のＩＨにメツセージを送る。

データベース・システムはロックを論理階層に分類する
。ロックはどれもその親ロックが保持されるまでは取得
することができない。

１Ｍは各資源に対するロックを保持するＲＬＭのセット
を動的に追跡する。単一のＲＬＭが資源のロックを保持
するとき、その旧、Ｈは該資源で唯一の利害関係を有す
る。　ＲＬＭは資源で唯一の利害関係を有するあいだは
■にと相談せずに該資源に従属するロックを取得するこ
とができる。

データベース・システムの設計者はロック階層を選択す
る。ロック・マネジャー（ＬＨ）はトランザクションが
オブジェクト自身のロックを取得する前に該オブジェク
トの親ロックを取得する必要がある。データベース・シ
ステムのロック階層の可能なレベルを下記に示す： データベース リレーション ページ テユーブル ブロック レコード オブジェクトを体系化して階層に入れることはデータベ
ース・システムで支援されたデータ・モデルが階層構造
であることを意味しない１本明細書に記述された手法は
リレーショナル・システムにも等しく適用される。

第４図に階層ロック・マネジャーの構造を示す。

ＲＬＭはトランザクションを実行する各々のシステムで
ランする。　ＩＮは別個のシステムでランする。

各ＲＬＭが仮想記憶装置に有する表は、同じシステムで
ランしているトランザクションによりオブジェクトに対
して保持された全てのロックを記述する。　ＲＬＭの表
はオブジェクトのトリーとして体系化される。更に、各
オブジェクトはそれに関連した２つのキュー：オブジェ
クトに対するロックの保持者のキュー及びオブジェクト
に対するロックの待機者のキューを有する。　ＲＬＭが
他のＲＬＭはロックを保持しないオブジェクトのロック
を保持するとき、最初のＲＬＭは該オブジェクトと唯一
の利害関係を持つといわれる。ロックは子オブジェクト
で取得できるようになる前に親オブジェクトで取得しな
ければならないという規則により、　ＲＬＭはオブジェ
クトと唯一の利害関係を持つとき該オブジェクトの全て
の子孫とも唯一の利害関係を持つ、トランザクションは
オブジェクトのロックを取得する必要があるとき、その
システムの該ＲＬＭに対し要求を出す、該ＲＬＭはその
ロック表を検査し下記の３つの事項のうちの１つを実行
する＝（１）直ちに該ロックを許可する。

（２）該ロック要求を同じオブジェクトの互換性のない
別の要求のあとにキューする。

（３）該要求をメツセージを介してＲＬＭに送る。

ＩＮが仮想記憶装置に有する表は（システムのトランザ
クションの代わりに）それぞれのＲＬＭによりオブジェ
クトに保持されたロックを記述する。

しかしながら、ＩＭの表はシステムに保持されたロック
を全て含むわけではない、この表は２つ以」二のＲＬＭ
によってオブジェクトに保持されたロック及び唯一の利
害関係を有するＲＬＭによってオブジェクトに保持され
た最も高いレベルのロックを含む、各ＩＭ表の項目はロ
ックを保持するＲＬＭのセットを表わす、第５図はＩＭ
表及びＲＬＭ表の例を示す。

トランザクションがそのシステムのＲＬＭからオブジェ
クトのロックを要求するとき、下記の３つの状況のうち
の１つが存在する： （１）オブジェクトはＨしに表にはない。

（２）オブジェクトはＲＬＨの表にはあるが、ＲＬＭは
該オブジェクトでは唯一の利害関係を持たない。

（３）　ＲＬＭは該オブジェクトで唯一の利害関係を持
つ。

次にこれらの状況に対するロック・マネジャーの活動に
ついて調べる。

もしオブジェクトがＲＬＭ表になければ、　ＲＬＭはオ
ブジェクトをその表に入れ、該オブジェクトのロックの
待機者のキューに該トランザクションを入れる。　ＲＬ
Ｍは該オブジェクトのロックを要求するＩＨにメツセー
ジを送り、該トランザクションの延期を指示する。

下記のように、３つの応答のうちの１つがＩＭから戻る
ことができる。それに続いて、句”トランザクションを
再開始する”　−オブジェクトの待機者キューのトラン
ザクションの項目を保持者キューに移動することを意味
する−が受取られ。

該トランザクションは実行を続行することが許される。

ＩＮ応答及び関連ＲＬＭ動作は次の通りである：（１）
オブジェクトのロックは許可されており、ＲＬＭは該オ
ブジェクトで唯一の利害関係を持つ、　ＲＬＨは該オブ
ジェクトを唯一の利害関係として記録する。

（２）オブジェクトのロックは許可されているが。

もう１つのＲＬＭも該オブジェクトに利害関係を持つ、
該ＲＬＭは該トランザクションを再開始する。

（３）オブジェクトのロックはもう１つのＲＬＭの障害
により許可することができない、該トランザクションが
呼起こされ、要求が失敗したことが通知される。該オブ
ジェクトは該ＲＬＭ表から除去される。

もしオブジェクトはＲＬＭ表にあるが該ＲＬＭは該オブ
ジェクトで唯一の利害関係を有しないなら。

該ＲＬＭは該オブジェクトの待機者キューにトランザク
ションの要求を付加し、該トランザクションを延期し、
且つメツセージを介して要求をＩＭに転送する。可能な
ＩＭ応答メツセージ及び関連ＲＥ、Ｍ動作は前の場合の
動作とほぼ同じである。唯一の相違はＩＭがＲＬＭにロ
ックを許可すると、要求トランザクションと同じシステ
ムでランしている他のトランザクションが該要求と競合
するオブジェクトのロックを保持できることである。そ
の場合、要求しているトランザクションは、それらが該
オブジェクトのロックを開放するまでは１局所トランザ
クションのあとにキューされたままである。

もしＲＬＭがオブジェクトで唯一の利害関係を持つなら
、　ＩＭとの通信は不要である。前の場合のように、ト
ランザクションは、該オブジェクトの競合しているロッ
クを保持する他の局所トランザクションがそれらのロッ
クを開放するまで、待機者キューにとどまることができ
る。

ＩＭはあるＲＬＭによりロックされるが単一の利害関係
によりカバーされないオブジェクトの表を維持する。　
ＩＭはロック要求をＲＬＭ　（例えば、ＲＬＭ　６１）
から受取ると、そのオブジェクトの表を検査する。

もし該オブジェクトがまだその表になければその表に加
えられ、ＲＬＭの唯一の利害関係として記録され、応答
がロックを許可するＲＬＭ　６１に返されると共に唯一
の利害関係がＲＬＭ　６１に与えられる。

もしオブジェクトが既にＩＭの表にあれば、■旧よ該要
求と競合するオブジェクトのロックを保持する他のＲＬ
Ｍの各々にメツセージを送る。　ＲＬＭ　６１は該オブ
ジェクトのロックを保持するＲＬＭのリストに加えられ
る。　ＲＬＭの全てが新しいロックを認める許可を与え
ることを示すメツセージを返すと。

■旧まロックを許可するメツセージをＲＬＭ　６１に送
る。

もし、該要求の時点で、もう１つのＲＬＭ　　（例えば
、　ＲＬＭ　６２）が該オブジェクトで唯一の利害関係
を持つなら、更に複雑なプロトコルが必要になる。

ＩＭは直ちに該オブジェクトに対するロックをＲＬＭ６
１に加えるが、　ＲＬＭ　６２が保持する唯一の利害関
係は一時的に保持される。その期間中、該ＩＭはＩＩＬ
Ｍ６２が該唯−の利害関係のオブジェクトの直近下位の
オブジェクトに保持されたロックをどれも該ＩＭに送る
ことを要求する。もちろん、新しいオブジェクトはＲＬ
Ｍ　６２に唯一の利害関係を持つ、全ての直接従属する
ロックがＲＬＭ　６２によりＩＭに送られているときは
、最初のオブジェクトでＲＬＭ　６２の唯一の利害関係
は落される。

もし該オブジェクトの競合するロックを保持するＲＬＨ
のどれかが失敗していれば、ＩＮはＲＬＭ　６１に対す
るロック要求に誤り応答を返す。

ＲＬＭは局所トランザクション要求及びＩＮからの遠隔
要求の両者に応答しなければならない、このセクション
ではＩＮメツセージに対する応答について説明する。　
ＲＬＭはＩＭからの遠隔要求を受取ると、その関連する
オブジェクトの表を検査する。もしその表が該オブジェ
クトを含まなければ、ロックを許可するメツセージは直
ちにＩＮに返される。その表が該オブジェクトを含むな
ら、該要求は該ロックの現在の保持者及び待機者との互
換性について検査される。もし該要求に互換性があるな
ら。

ロックを許可するメツセージは直ちにＩＭに返される。

さもなければ、該要求は該オブジェクトの他の待機して
いるロック要求のあとにキューされる。

該要求が（該オブジェクトのロックを開放する他のトラ
ンザクションにより）許可されると、該ロックを許可す
るＩＭにメツセージが返される。

トランザクションがオブジェクトのロックを開放すると
、　ＲＬＭは新しい保持者を収容できるかどうかを調べ
るため待機者のキューを検査する。もしそうなら、互換
性がある多くの新しい待機者が、それらが局所にある場
合に、保持者キューに加えられる。互換性がある遠隔の
待機者の場合は該要求を許可するメツセージがＩＭに送
られる。オブジェクトの最後のロックがＲＬＭで開放さ
れると、ロックを開放するためのメツセージがＩＭに送
られる。

ＩＮはオブジェクトのロック保持者のリストから該ＲＬ
Ｍを除去する。もし現在ただ１つのＲＬＭ　Ｌ、か該オ
ブジェクトのロックを保持しないなら、唯一の利害関係
を与えるメツセージが送られ、■旧よその表で現在の唯
一の利害関係のオブジェクトの下位の全てのオブジェク
トを削除する。

ＲＬＭ　６１によりロックが管理システム／トランザク
ション・プロセッサ３１にいったん付与されると、該プ
ロセッサ３１は線８１を介して０ＡＳＤ　１３の所望の
データをアクセスし、そのバッファ・プールに該データ
を読取る。プロセス／ユーザーによりデータを処理する
間に又はその後のある時点で、該データはＤＡＳＤ１３
に再書込みされ、ＲＬＭ　６１は該ロックを開放するよ
うに通知される。もしプロセス／ユーザーがバッファ・
プール４１に保持されたデータの多重更新を行なわなけ
ればならないなら、管理システム／トランザクション・
プロセッサ３１は、更新されたデータをＤＡＳＤ１３に
書込む前、全ての更新が終了するまでバッファ・プロセ
ッサにデータを保持する。もしＲＬＭ　６２が該データ
がＤＡＳＤ１３に書込まれる前に資源のコピーを要求す
れば、　ＲＬＭ　６１はコピーを直接バッファ・プール
から制御経路４５．３Ｌ３５．６１．２５．２１．２３
．２７．２４．２２．２６を介してＩＩＬＭ　６２に届
ける。管理システム／トランザクション・プロセッサ３
１は更新されたブロックの下記の情報をＰＯ５ＴＭＳＧ
動作で使用するためＲＬＭ　６１に返す。

本更新するシステムのＩＤ 本更新されたデータベースのＩＤ 本更新されたブロックの１０ 同様に、他の管理システム３２〜３４はどれも対応する
ＲＬＭ　６１．６２と協力してＤＡＳＤ１３．１４のデ
ータをアクセスし、バッファ・プール４１〜４４に記憶
されたデータを操作する。１つのバッファ・プールで行
なわれた更新が、同じブロックのコピーを有することが
ある他のシステムのバッファ・プールでも正しく行なわ
れることを保証することはコヒーレンシーの維持と呼ば
れる。

各管理システム／トランザクション・プロセッサは障害
の場合の回復のため全てのトランザクションのログをデ
ィスク７１〜７４に維持する。データベース回復制御機
構５１．５２は制御データセット５７のアクセスを共有
し、システム又は他の障害の場合に管理システム３１〜
３４と協力してデータベースの回復を制御する。

第６図は本発明の方法により計算システムを動作させる
のに使われる、各管理システム／トランザクション・プ
ロセッサ３１〜３４内に含まれるバッファ・マネジャー
・モジュールを示す、バッファ・マネジャー・モジュー
ルはロック取得のため適切なＲＬＭと通信するように明
確に指定されている。

バッファ・マネジャーは、管理システムがデータベース
管理システム／トランザクション・プロセッサであると
きは主記憶装置（２１）に、又は情報管理システム／ト
ランザクション・プロセッサならばバッファ・プール（
４１）に、ブロックのプールを維持する。各ブロックは
関連するバッファ見出し一ブロックの識別（データベー
ス及びブロック番号の識別）及び他の状況を含む−を有
する。

バッファ・マネジャーが各ブロックと共に維持する他の
状況は第６図に示す。

バッファ・マネジャーは保持する各マネジャーのＵＰＤ
ＡＴＥ又はＲＥＡＤロックのどちらかを保持する。

ＲＥＡＤとＵＰＤＡＴＥロックは互換性があるが、ＵＰ
ＤＡＴＥロックは他のＵＰＤＡＴＥロックとは互換性が
ない、それゆえ、任意の時刻で１つのプロセッサだけが
特定のブロックの更新可能なコピーを保持できるが。

読取りは複数の読取者に許可される。バッファ・マネジ
ャーがプロセス／ユーザーにブロックの変更を許可でき
るようになる前に、　ＲＬＭは該ブロックにＵＰＤＡＴ
Ｅロックを保持しなければならない、該プロセスは関連
したブロック・ロックの下位の階層の一貫性を保証する
のに役立つレコード・ロックも取得する。バッファマネ
ジャーがＤＡＳＤからブロックを取出すとき、下記の動
作を行なう＝（１）バッファ見出しのＢＵＦＳＹＮＣを
消去する。

（２）　ＢＵＦＥＶＥＮＴを２にセットする。

（３）該ブロックの５ＨＡＲＥ　ＬＯＣＫを非同期オプ
ションにより要求する。

（４）　ＤＡＳＤ読取りをスケジューリングする。

（５）　ＢＵＦＳＹＮＣフラグを待つ。

ロック要求処理が終了すると、　ｎＬＭは要求している
サブシステムのロック状況出口を駆動する。

ロック状況出口はロック要求が失敗した場合にはＢＵＦ
ＦＬＦＡ　Ｉをセットする。いずれにしても、それはＢ
ＵＦＥＶＥＮＴを減計数する。もしＢＵＦＥＶＥＮＴが
Ｏになれば、それはＢＵＦＳＹＮＣ事象を知らせる。

同様に、Ｉｌｏが終了するとき、該ブロックの読取り中
にＩ１０誤りが起きていたならＢＵＦＦＩＯＥＲがセッ
トされる。いずれにしても、ＢＵＦＥＶＥＮＴは減計数
される。もしＢＵＦＥＶＥＮＴがＯになれば、　ＢＵＦ
ＳＹＮＣ信号が送られる。

もしロック要求が成功しブロック読取りの誤りがなかっ
たなら、該ロックは直ちに使用することができる。もし
誤りが起きたなら、読取られたブロックは使用すること
ができない、ロック要求失敗の場合には１次の試みで成
功するのを保証するため同期ロック要求が使われ、続い
て通常のブロック読取りが行なわれる。

もしブロックのＳ　ＨＡ　ＲＥロックを保持するプロセ
ス／ユーザーがあとで該ブロックを更新しなければなら
ないなら、該ブロックの共有ロックを格」こげして更新
するように同期ロック要求が行なわれなければならない
、もし該ブロックを更新する意向が予めわかっていれば
、前記プロセスで非同期に取得されたブロック・ロック
はＵＰＤＡＴＥモードで取得し、余分なロック要求及び
起こりうる延期／再開始を避けることができる。前述の
バッファ見出しにあるＢＵＦＦＵＰＤＴフィールドはＵ
ＰＤＡＴＥロックが該ブロックに保持されていることを
忘れないようにするために使用される。

本発明の動作 一ケース■− 次に、本発明を使用する無競合動作を図面を参照して説
明する。レコード１１１１及びＲ１２（図示せず）から
成るブロックＢ１はＤＡＳＤ１３にありバッファ・プー
ル４１又は４３には存在しない、　ＣＥＣＩｆにあるプ
ロセッサ／ユーザーはＲ１１のアクセスを欲するものと
する。

ステップ１：プロセス／ユーザーはバッファ・マネジャ
ーから０１を要求する。

ステップ２：バッファ・マネジャーはＢｌがバッファ・
プールにないことがわかると下 記動作を開始する： ＋　　Ｂｌに対し非同期更新ロック要求を出す。

＋　　Ｂｌをバッファに読取るためＴ１０を開始する。

＋　プロセス／ユーザーを一時停止 する。

ステップ３：成功及び唯一の利害関係を表わす非同期更
新ロック要求応答を返す。

＋　バッファ・マネジャーはその表 にロック要求成功を記入する。

ステップ４：Ｂ１を読取るＩｌｏが完了する。

＋　バッファ・マネジャーは成功し た読取り完了を表に記入する。

＋　　Ｂｌはバッファ・マネジャーによりバッファ・プ
ールに使用可能 と記録され、システム１１が唯一 の利害関係を有することを示す メツセージを付与する。

＋　プロセス／ユーザーが再開始す る。

ステップ５：プロセス／ユーザーはＢｌに対するそれ自
身の読取りブロック・ロックを 要求する。　（１５４） 十　要求を通信なしで許可する。

ステップ６：プロセス／ユーザーは旧１及び旧２のロッ
クを要求する。　（１５６） 十　ロックは階層的にブロック・ロ ックに従属する。

＋　　Ｂｌの唯一の利害関係によりロックを通信なしに
直ちに許可する。

ステップ７：プロセス／ユーザーはＲ１１を更新する。

　（１５８） ステップ８：プロセス／ユーザーはコミットのフェーズ
１を開始する。

ステップ９：バッファ・マネジャーはＢ１に対するＰＯ
５ＴＭＳＧを発行する。　（１６０）ステップ１０：プ
ロセス／ユーザーはＲＬ２を更新する。　（１６２） ステップ１１：バッファ・マネジャーはＢ１に対するＰ
Ｏ５ＴＭＳＧを発行する。　（１６４）ステップ１０：
プロセス／ユーザーはフェーズ１〜２を変換ログ・レコ
ードニ！　込ム。

ステップ１１：プロセス／ユーザーはコミットのフェー
ズ２を開始する。

ステップ１２：プロセス／ユーザーはステップ９及びス
テップ１１で行なりれたＰＯ５ＴＭＳＧ呼出しが終って
いることをバッファ ・マネジャーが知らせるのを待つ。

ステップ１３：プロセス／ユーザーのロックを開放する
。

ステップ１４：バッファ・マネジャーは更新されたブロ
ックのＤＡＳＤへの再書込みを決定する。

ステップ１５：　ＤＡＳＤへのブロック書込みを完了す
る６ステップ１６：バッファ・マネジャーは該ブロック
のメツセージを消去しブロック・ロ ックを開放する要求をＲＬＭに出す。

一ケースＩＩ　−− レコード旧１及びＲ１２から成るブロックＢｌは該ブロ
ックが更新されたのちＤＡＳＤ１３に書込まれるまでシ
ステム１１のバッファ・プール４１にあるものとする（
ケースＩのステップ１３）、システム１２のプロセス／
ユーザーは旧ｌの読取りを欲するものとする。

ステップ１ニジステム１２のプロセス／ユーザーはバッ
ファ・マネジャーからＢ１を要求 する。

ステップ２：バッファ・マネジャーはＢｌがシステム１
２のバッファ・プール４２にないことがわかると下記動
作を開始する： ＋　　８１の非同期５ＨＡＲＥロツク要求を出す。

＋１１０は記憶装置への８１の読取り を開始する。

十　プロセス／ユーザーを延期する。

ステップ３：成功及び唯一の利害関係、ならびにＰＯ５
ＴＭＳＧメツセージを表わす非同期′ロック要求応答を
返す。

＋　システム１２のバッファ・マネジ ャーはその表にロック要求成功 を記入する。

十　前のＰＯ３ＴＭＳＧの結果としてシステム１１のＲ
ＬＭ　６１から返されたメツセージは、システム１１が
まだ 現在の８１ブロツクを保持するこ とを回報通信する（ケースＩの ステップ１１）。

＋　システム１２によりブロックＢ１を要求するメツセ
ージをシステム １１に送る。

ステップ４：　Ｂｌを読取るブロックＩ１０が完了する
。

＋　システム１２のバッファ・マネジ ャーは読取り完了の成功を表に 記入する。

＋　　Ｂｌはバッファ・マネジャーによりバッファ・プ
ールに使用不可 能と記録される。

ステップ５：ブロック口１の現在のコピーをシステム１
１から受取る。

＋　プロセス／ユーザーは再開始す る。

ステップ６：プロセス／ユーザーはＢ１に対するそれ自
身のロックを要求する。

十　共有ロックの要求である。

＋　要求は通信なしに許可される。

ステップ７：プロセス／ユーザーはＲ１１のロックを要
求する。

十　ロックは階層的にブロック・ロ ックに従属する。

＋　　Ｂｌはシステム１２で唯一の利害関係ではないか
ら、レコード・ロ ツクは通信を必要とする。

＋Ｒ１１のロック要求が許可される までプロセス／ユーザーを延期 する。

一ケースＩＩＩ　　− レコードＲ１１及びＲ１２から成るブロックＢ１は既に
システム１１のバッファ・プール４１にあるものとし、
システム１１のプロセス／ユーザーはＲ１１のアクセス
を欲するものとする。

ステップ１ニジステム１１のプロセス／ユーザーはバッ
ファ・マネジャーがらＢ１を要求 する。

ステップ２：バッファ・マネジャーはＢ１がシステム１
１のバッファ・プール４Ｉにあることがわかると直ちに
プロセス／ユー ザーに返す。

ステップ３：プロセス／ユーザーはＢ１に対するそれ自
身の読取りロックを要求する。

＋　該要求は通信なしに許可される。

ステップ４：プロセス／ユーザーはＲ１１のロックを要
求する。

十　ロックは階層的にブロック・ロ ックに従属する。

＋　システム１１で旧は唯一の利害関 係であるから、レコード・ロッ クは通信を必要としない。

Ｒはトランザクションによりアクセスされたレコード数
、Ｂはトランザクションにより読取られたブロック数、
Ｕはトランザクションにより更新されたブロック数、及
びＮはデータ共有に加わるシステム数とする。データベ
ース・システムはブロックが１）ＡＳＩ）から読取られ
たとき該ブロックが更新されるかどうかを予測しないも
のとする。そして、競合がないものとすると１本発明は
下記の延期／再開始（Ｓ／Ｒ）数及びトランザクション
をランするメツセージ数を必要とする： ＳＲ＝　Ｂ　＋　Ｕ メツセージ＝Ｂ＋１＋１ 延期／再開始は読取られるブロックごとに、及びＵＰＤ
ＡＴＥモードに格上げされるブロック・ロックごとに待
機する必要があるために生ずる。読取られ更新されるブ
ロックごとのメツセージが送られ、最後にＵＮＬＯＣＫ
　ＡＬＬ及びバッファ無効化メツセージが送られる。

現在のＩＭＳ／ＶＳのデータ共有の場合の費用は：ＳＲ
＝　　Ｂ　　＋　　Ｕ　　＋　　Ｒメツセージ数　Ｕ（
Ｎ　−１）　＋　Ｒ＋　１Ｕ（Ｎ−１）項は同報通信無
効化を行なう費用である。Ｒ項はレコード・ロックを取
得するためのメツセージをカウントする５もしレコード
の一部が同じＧＨＴクラスにハツシュすれば、トランザ
クションによっては取得するメツセージがＲメツセージ
よりも少ないことがある。これらの数字を比較すると１
本発明が必要とする遅延／再開始はＲだけ少なくなり、
メツセージは少なくともＲ−Ｂ４Ｏ（Ｎ　−２）だけ少
なくなる。２経路共有の場合は、本発明によるメツセー
ジはＩｔ−８だけ少なくなる。

４ブロツクで６レコードを読取り　２ブロツクのレコー
ドの　２つを更新するトランザクションの場合、２経路
データ共有を行なう現在のＩＮＳ／ＶＳ方式のメツセー
ジ及び延期／再開始対の両者をカウントすると、下記の
結果が得られる： 動　　作　　　　　　メツセージ゛　　メツセージ゛　
　Ｓ／ＲＳ／ＲＩＭＳ／ＶＳ　　本発明　ＩＮＳ／ＶＳ
　　本発明ＲＥＡＤ４ＢＬＯＣＫＳ　　　　　０　　　
　　　　４　　　　　　　４　　　　　　　４ＧＥＴ　
　６　　ＲＥＣＯＲＤ ＬＯＣＫＳ　　　　　　　　　　　　　４　　　　　　
　０　　　　　　　４　　　　　　　０ＢＬＩＦＦＥＲ
ＮＯＴＩＦＹ　　　　　２　　　　　　　０　　　　　
　　０　　　　　　　０ＵＮＬＯＣＫ　　ＡＬＬ　　　
　　　　　１　　　　　　　１　　　　　　　０　　　
　　　　０合　　計　　　　　　７　　　　５　　　　
８　　　　４６つのロックを取得するにはＩＮＳ／ＶＳ
に４つのメツセージが課されるに過ぎない、同じブロッ
クのロックの場合、　ＩＮＳ／ＶＳ資源ロック・マネジ
ャーにおける大域ハツシュ・テーブル方式は通信を減す
るものと仮定する。　ＵＮＬＯＣＫ　ＡＬＬの場合は１
両方式とも１つのメツセージが課されているに過ぎない
、これは、今日では適切ではないことがある最適化を仮
定している。引用例では、本発明はバッファ無効化のた
め、より多くのメツセージを送るが、実際にはレコード
・ロックでそれらを減する。

更に重要な要素は、現在のＩＭＳ／ＶＳに必要な余分の
延期／再開始対が新しい方式では削除されることである
。

システムは、システムに故障が生ずると、ＤＡＳＤに再
書込みされていないコミットされた更新を有するブロッ
クを保持することができる。バッファ・マネジャー、資
源ロック・マネジャー及びデータベース回復制御は、残
存しているシステムのトランザクションが陳腐化したデ
ータに遭遇しないこと及び最新の値が速やかに復元され
ることを確実にするため協力しなければならない、資源
ロック・マネジャーはＰＯ５ＴＭＳＧのコピーを少なく
とも２つのシステムに保持するので、単一の故障ではＰ
Ｏ３ＴＭＳＧメツセージを喪失することはない、これら
の保持されたメツセージは残存しているシステムに陳腐
化したデータを見させない、このシステムは、該故障バ
ッファ・マネジャーの代理を演じ、故障で失われたブロ
ック値の要求に答える。該代理は回復が完了し現在のブ
ロック値がＤＡＳＤに再書込みし終るまで他のシステム
からの要求を留保する。データベース回復制御は失われ
たブロックの値を回復するため単一システム再実行型回
復を用いる。チエツクポイント式のような、現在の手法
は回復を実行するため検査しなければならないログ・デ
ータの量を制限するのに使用することができる１回復さ
れたブロックは残存しているシステムからのコミットさ
れていない更新を含むことがある。コミットされていな
いレコード値は該残存しているシステムによりなお保持
されたレコード・ロックによりカバーされる。故障した
システムの回復が完了すると、該ブロック・ロック（及
び該故障したシステムのコミットされていないトランザ
クションにより保持されたレコード・ロック）が開放さ
れる。該故障したシステムによりブロック・ロックに付
与された全てのメツセージも削除される。

【図面の簡単な説明】

第１図はＮ経路のシステムで動作するプロセス／ユーザ
ーによって２つのレコードを更新する際に本発明によっ
て用いられる方法を示す図、第２図は本発明による動作
の代表的なディジタル計算システム構成を表わすブロッ
ク図、第３図は２経路のシステムで動作するプロセス／
ユーザーによってブロックの２つのレコードを更新する
従来技術の方法を示す図、 第４図は階層ロックマネジャーの構造を表わすブロック
図、 第５図はＩＭ及びＲＬＭにより維持される表の例を示す
図、 第６図は各管理システム／トランザクション・プロセッ
サ内に含まれるバッファ・マネジャー・モジュールを示
す図である。 １０・・・・ＩＭ、　１１．１２・・・・ＣＥＣ１１３
，１４・・・・ＤＡＳＤ、２１．２２・・・・ホスト・
オペレーティング・システム、２７・・・・通信制御装
置、３１〜３４・・・・管理システム／トランザクショ
ン・プロセッサ、４１〜４４・・・・バッファ・プール
、５１．５２　　・・・・ＤＢＩＣ１６１，６２・・・
・ＲＬＭ、７１〜７４・・・・トランザクション・ログ
・ディスク。 出願人　　インターナショナル・ビジネス・マシーンズ
・コーポレーション 代理人　　弁理士　　頓　　宮　　孝　　−（外１名） ￥　３　口 篤４　回 χ　５　図

Claims (1)

1. 【特許請求の範囲】 複数の並行して実行可能な独立なユーザーにより、デー
   タ資源の選択的にロック可能な部分に同時にアクセスし
   且つ上記データ資源の部分の情報状態の複製物間にコヒ
   ーレンシーを維持する方法であって、 ユーザーにより、対応する電子システムの資源ロック・
   マネジャーに、データ資源の所望部分に関する更新ロッ
   クを要求し、 資源ロック・マネジャーにより上記データ資源の所望部
   分に関する上記電子システムの利害関係状態を判定する
   とともに、上記判定処理と並行して上記データ資源に条
   件付きアクセスを行なって上記電子システム内に上記デ
   ータ資源の所望部分をバッファし、 上記判定ステップにより上記データ資源の所望部分に他
   の電子システムが利害関係を有していないことが示され
   る時、資源ロック・マネジャーにより上記電子システム
   及び上記要求を行なっているユーザーに上記更新ロック
   を許可し、上記電子システム内にバッファされた上記デ
   ータ資源に、上記電子システムが更新ロック及び上記資
   源に対する独占的な利害関係を保持していることを示す
   メッセージを付加し、 上記電子システム内に、上記バッファされた資源に読取
   ロックを要求している全てのシステム中のユーザーのリ
   ストを維持し、 上記バッファされた資源に含まれるデータを処理し、デ
   ータに対する変更を上記資源ロック・マネジャーに報告
   し、 上記バッファされた資源上に読取ロックを保持している
   全てのリストされたユーザーに、現行データに非コヒー
   レンシーのあることを通知するステップを含む データ資源アクセス方法。