JPH0784815A

JPH0784815A - フォールト・トレラント・トランザクション指向データ処理システムおよび方法

Info

Publication number: JPH0784815A
Application number: JP6163804A
Authority: JP
Inventors: John Schofield Andrew; アンドリュー・ジョン・ショフィールド; Robert Washer Anthony; アンソニー・ロバート・ウォッシャ
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1993-09-02
Filing date: 1994-07-15
Publication date: 1995-03-31
Anticipated expiration: 2012-08-25
Also published as: EP0642079B1; GB2281644A; JP2644188B2; US6154847A; US6493826B1; GB9318167D0; EP0642079A1; DE69422105D1

Abstract

(57)【要約】【目的】フォールト・トレラント・トランザクション処
理のシステムおよび方法によって、トランザクションを
ロールバックするかシステムを再始動する必要が生じた
場合に回復を可能にするため、システムの動作に関連す
るレコードが記録される。【構成】動作レコードのうちの少なくともいくつかは、
低速不揮発性記憶域内の回復ログとして記憶され、少な
くともいくつかは、高速揮発性記憶域内の回復リストと
して記憶される。個々のトランザクションのロールバッ
クは、回復リストを参照することによって行われるが、
システムの再始動は、回復ログを参照することによって
行われる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、フォールト・トレラン
ト・トランザクション指向データ処理に関し、具体的に
は、トランザクション指向のメッセージング・システ
ム、ファイル・システム、データベース・システムなど
のトランザクション内で回復可能資源の更新をサポート
するための効率的な方法およびシステムに関する。

【０００２】

【従来の技術】アプリケーション指向のコンピュータ・
プログラムを使用するトランザクション処理によって、
多くのビジネス機能を実施できる。アプリケーション指
向プログラムの大半が、なんらかの形のコンピュータ・
システム機能（プロセッサ、データベース、ファイル、
入出力装置、他のアプリケーション・プログラムなどの
機能）へのアクセスを必要とするが、これらの機能を一
般に資源と称する。これらの資源を制御するシステム・
ソフトウェアを、一般に資源管理プログラムと称する。
一般的な処理要件は、１つまたは複数の資源（具体的に
はデータ・オブジェクトの集まり）に、調整された１組
の変更を加えて、変更のすべてが有効となり、資源が新
しい一貫性のある状態に移されるか、それらが全く行わ
れないかのいずれかになるようにすることができること
である。すべてか無というこの処理の特性を、「原子
性」と称する。

【０００３】C.J.Date著、"An Introduction to Data B
ase Systems", Vol. 1, 4th Edition, Addison-Wesley
Publishing Co., 1986, Ch.18に指摘されているよう
に、「トランザクション」とは、１つまたは複数の回復
可能資源の一貫性のある状態を別の一貫性のある状態に
変換する（すべての中間点で一貫性を維持する必要はな
い）関連動作のシーケンスを指す、作業の論理単位であ
る。トランザクション処理とは、共用データをアクセス
し更新する別々の作業単位を管理することである。

【０００４】システム、媒体およびトランザクションの
障害（後者の１例は、アプリケーションによって検出さ
れ、トランザクションの完了不能につながるエラー状態
である）に対してデータ一貫性とトランザクションの原
子性を維持できるフォールト・トレラント・トランザク
ション処理システムを提供することが知られている。障
害の後に資源を一貫性のある状態に回復できるようにす
るためには、システムが障害の時点でのシステム資源の
状態の記録を保持する必要があり、これには、完了した
トランザクションをもう一度実行できるようにどのトラ
ンザクションが完了していたかを知り、未完了のトラン
ザクション内の動作を取り消せるようにどのトランザク
ションが進行中であったかを知ることが含まれる。した
がって、トランザクションによって、作業の単位ならび
に回復の単位が定義される。

【０００５】しばしば、更新を行う前にトランザクショ
ンを成功裡に完了できるかどうかを検証するための遅延
なしで、１トランザクション内で資源更新を行うことが
処理要件になる。したがって、このようなシステムで
は、原子性と一貫性のために、トランザクションが成功
裡に完了できない時のための逆方向回復機能を設け、部
分的実行中に資源に加えられたすべての変更を除去でき
るようにする必要がある。

【０００６】あるトランザクションの開始の前に存在し
た一貫性のある状態への資源の回復を、トランザクショ
ンのＲＯＬＬＢＡＣＫ（ロールバック、ＢＡＣＫＯＵＴ
（バックアウト）も同義語、１トランザクション全体の
ＲＯＬＬＢＡＣＫをＡＢＯＲＴ（打切）と称する）と称
し、一般に、変更は、元々それが行われた時間的な順序
と逆の順序で除去される。

【０００７】トランザクション性技法を使用できるシス
テムの１例が、文書"IBM Messagingand Queuing Series
- technical Reference" (SC33-0850-01, 1993)に記載
のメッセージングおよび待合せシステムである。メッセ
ージングおよび待合せは、高水準のプログラム間通信用
の複数の機能を提供する。これには下記が含まれる。・メッセージング。通信プロトコルを隠蔽する、プログ
ラム間通信の簡単な手段。・待合せ。メッセージの遅延配布。これを用いると、同
時に活動状態にならないか、それらのためのデータ・リ
ンクが活動状態でないプロセスの間での非同期通信が可
能になる。メッセージングおよび待合せサービスによっ
て、目標アプリケーションへの後の配布を保証できる。・メッセージ駆動処理。分散システム内の複数のプロセ
スへのメッセージの流れによるアプリケーション・タス
クの達成。諸プロセスは、アプリケーション・タスクが
達成されるまで、待ち行列内のメッセージをアクセス
し、新メッセージを生成することによって、一緒に作業
する。

【０００８】ほとんどのアプリケーションは、いくつか
の形式の資源をアクセスすることを必要とし、一般に、
２つ以上の資源への調整された１組の変更を行えること
が必要である。「調整された」とは、資源に対する変更
のすべてが実施されるか、１つも実施されないかのいず
れかであることを意味する。待ち行列も、これに関して
は例外でない。アプリケーションは、メッセージをプッ
トし、ゲットする（および、おそらくはデータベースな
ど他の資源を更新する）ことができ、動作のすべてが実
施されるか１つも実施されないかを知ることができる必
要がある。これに含まれる動作のセットを、トランザク
ションまたは作業の単位と称する。下の例でこれを示
す。ある口座から同じ位置にある別の口座への送金を行
う金融アプリケーションでは、２つの基本動作を行う必
要がある。すなわち、一方の口座の借方記入と他方の口
座の貸方記入である。通常はこの両方の動作が成功する
が、一方で障害が発生する場合には、両方をエラーにし
なければならない。この障害は、動作上の理由（たとえ
ば、一方の待ち行列が一時的に使用不能）である場合が
あり、この場合、このトランザクションを後にもう一度
提示できる。また、この障害が、借り方口座の資金不足
が原因の場合があるが、この場合には、適当な応答をト
ランザクションの開始プログラムに返さなければならな
い。

【０００９】一方の口座の貸方記入と他方の口座の借方
記入とが、作業の単位を構成する。

【００１０】作業の単位は、最初の回復可能資源が影響
を受ける時に始まる。メッセージ待合せの場合、これ
は、メッセージが作業の単位の一部としてゲットまたは
プットされる時を意味する。この作業の単位は、そのア
プリケーションが終了する時またはそのアプリケーショ
ンがシンクポイント（下を参照されたい）を宣言する時
に終了する。アプリケーションがシンクポイントを宣言
することによって作業が終了する場合、もう１つの作業
の単位を開始でき、その結果、あるアプリケーションの
１つの実体が、複数の作業の単位にかかわる可能性があ
る。

【００１１】ゲット動作またはプット動作はそれぞれ、
現在の作業の単位に別々に参加することができる。アプ
リケーションは、ＭＱＧＥＴ、ＭＱＰＵＴおよびＭＱＰ
ＵＴ１の呼出し時に適当な「シンクポイント」または
「非シンクポイント」のオプションを指定することによ
って、どの動作が参加するかを選択する。どちらのオプ
ションも指定されない場合、現在の作業の単位内での呼
出しの参加は、環境によって決定される。

【００１２】アプリケーションは、シンクポイントを宣
言することによって作業の単位を終える。シンクポイン
トが宣言される時、その作業の単位に関心を有するもの
は、"ｎｏ"を投票し、したがってその作業の単位をバッ
クアウトさせることができる。これには、その作業の単
位の一部として行われた変更のすべてを取り消すという
効果がある。参加するすべてのものが"ｙｅｓ"を投票す
る場合、その作業の単位がコミットされ、その作業の一
部として行われた変更が永続的になる。作業の単位に関
心を有するものとは、下記のいずれかである。・アプリケーション・待ち行列管理プログラム・他の資源管理プログラム

【００１３】アプリケーションは、適当な環境依存の呼
出しを発行することによって、シンクポイントを宣言
し、投票を登録する。

【００１４】作業の単位の一部としてメッセージがプッ
トされる場合、そのメッセージは、その作業の単位が成
功裡にコミットされない限り、通常はアプリケーション
による検索のために使用可能にはならない。これに対す
る１つの例外が、そのメッセージをプットしたアプリケ
ーションである。このアプリケーションは、元の作業の
単位がコミットされる前に、その作業の単位の一部とし
て宛先待ち行列からメッセージを検索できる。ただし、
これを可能にするためには、宛先待ち行列が局所待ち行
列でなければならない。

【００１５】宛先待ち行列が遠隔待ち行列管理プログラ
ムに属する場合、そのメッセージは、その作業の単位が
コミットされない限り、局所待ち行列管理プログラムか
ら送るのに使用できない。これは、要求メッセージの送
出とその要求に対する応答の受取りを同一の作業の単位
の一部として行うことができないことを意味する。要求
メッセージを含む作業の単位をコミットした後でなけれ
ば、応答を受け取ることはできない。

【００１６】メッセージがプットされる時に待ち行列管
理プログラムによって検出されたエラーは、完了コード
・パラメータと理由コード・パラメータによって、即座
にアプリケーションに返される。この形で検出できるエ
ラーには、下記のものが含まれる。・メッセージが大きすぎて待ち行列に入らない・待ち行列が満杯・待ち行列に関して禁止されている要求をプットした

【００１７】メッセージのプットで障害が発生しても、
その作業の単位の状況には影響しない（そのメッセージ
は作業の単位の一部ではないので）。したがって、アプ
リケーションは、必要に応じてその作業の単位をコミッ
トまたはバックアウトできる。

【００１８】しかし、作業の単位の一部として成功裡に
プットされたメッセージが、アプリケーションが作業の
単位をコミットしようとした時にエラーを引き起こす場
合には、その作業の単位がバックアウトされる。

【００１９】作業の単位の一部としてメッセージを検索
する場合、そのメッセージは、待ち行列から除去され、
他のアプリケーションからは使用不能になる。しかし、
そのメッセージは破棄されず、作業の単位がコミットま
たはバックアウトされるまで待ち行列管理プログラムに
よって保存される。

【００２０】作業の単位が成功裡にコミットされる場
合、待ち行列管理プログラムがメッセージを破棄する。
しかし、作業の単位がバックアウトされる場合、そのメ
ッセージは、待ち行列の元の位置に復元され、したがっ
て、同一のアプリケーションまたは別のアプリケーショ
ンによる走査検索または検索に、もう一度使用可能にな
る。

【００２１】作業の単位を、持続性と称するメッセージ
の特性と混同してはならない。メッセージの持続性と
は、メッセージが障害と待ち行列管理プログラムの再開
の後に残るかどうかの定義である。

【００２２】作業の単位を使用して、アプリケーション
の障害または同一の作業の単位内で動作する他の資源管
理プログラムの障害に対する保護を行うことができる。
この「障害」には、プログラムが宣言する障害ならびに
エラー状況を含めることができる。その一方で、メッセ
ージの持続性によって、待ち行列管理プログラムの障害
に対する保護が行われる。

【００２３】作業の単位を使用する多くのアプリケーシ
ョンが、持続性メッセージも使用しようとする。しか
し、このどちらか一方だけを使用することが有利な情況
が存在する。たとえば、待ち行列管理プログラムの障害
の後に回復を行う論理がアプリケーションに含まれる場
合、非持続性メッセージと共に作業の単位を使用する
と、通常の障害のない場合に性能の利益が得られる。こ
の組合せを使用して、作業の単位がシンクポイントに達
する前にバックアウトされる場合に、最終（非持続性）
メッセージを送らないようにすることもできる。

【００２４】一般的な議論に戻ると、システム障害とト
ランザクション障害からの回復に必要な情報を提供する
ために、回復可能データに対して行われるすべての処置
が、通常は回復ログに記録される。このログは、可変長
レコードのための持続性記憶域であり、書込みはその末
尾でのみ可能であるが、読取りはどのような順序でも可
能である。通常、資源更新動作ごとに、ＵＮＤＯ（取
消）ログ・レコードとＲＥＤＯ（再実行）ログ・レコー
ドが書き込まれるが、前者は資源の前の状態を示し、後
者は資源の新しい状態を示す。障害の場合、作業の単位
の進行状態によって、どのレコードを回復に使用するか
が決定される。ＵＮＤＯログ・レコードは、障害の時点
でトランザクションが未完了であった場合に、トランザ
クション開始の前に存在した状態にシステム資源を復元
できるようにするために読み取られるが、ＲＥＤＯレコ
ードは、トランザクションが完了していた場合に、その
トランザクションの更新が行われた後に存在した状態に
資源を戻すために読み取られる。しかし、「遷移ロギン
グ」を使用することも既知である。この場合、資源更新
ごとに１つのログ項目（前の状態と後の状態の間の相
違）だけが必要である。すべての資源を回復可能にする
必要はなく、したがって、資源を「持続性」（不揮発
性）または「非持続性」（揮発性）のいずれかとして定
義できることが既知である。

【００２５】既知のシステムの多くでは、トランザクシ
ョンの成功裡の完了時にもログ・レコードを読み取っ
て、そのトランザクション内でどの動作が実行されたか
を判定し、したがって、現在どの資源更新を永続的とし
て確認できるかを判定する。資源を更新するアプリケー
ションは、ＣＯＭＭＩＴ（コミット）動作を実行して、
成功裡に完了したトランザクション内のすべての更新を
確認する。

【００２６】資源（たとえばデータベース）の内容が媒
体障害のために失われた場合、その資源が作成されて以
来のすべてのＲＥＤＯログ・レコードがセーブされてお
り、使用可能であるならば、その資源を再作成できるは
ずである。しかし、障害の後のシステム再始動時に読み
取り、処理しなければならないログ情報の量を制限する
（したがって、コストを削減し、回復の速度を向上させ
る）ために、資源の不揮発性のコピーを周期的に（一定
の時間間隔でまたは所定の量のシステム活動の後に）作
成し、セーブすることができ、そのコピーを作成する時
点でのログ位置を記録することができる。これを、チェ
ックポイントをとると称する。その後、障害が発生した
場合、記録された位置から回復ログを処理するが、この
時、最も最近のコピーの時点の資源の状態が、資源を回
復するための初期設定情報として役立つ。その資源に対
する後続のすべての処置を表すそのポイントからのＲＥ
ＤＯレコードを、資源のセーブされたコピーに対して再
処理する。

【００２７】ロギングのオーバーヘッドを減らすための
方法が、C.Mohan他著、"ARIES: A Transaction Recover
y Method Supporting Fine Granularity Locking and P
artial Rollbacks Using Write-Ahead Logging", IBM R
esearch Report RJ6649 (Computer Science),１９８９
年１月１９日に記載されている。ＡＲＩＥＳ回復方法で
は、ログを使用して、資源に対して行われる変更を記録
する。トランザクションの順方向処理の間に行われる更
新活動のロギングの他に、通常処理と再始動処理の両方
の間のトランザクションの全体的または部分的なロール
バックの間に実行される資源変更についてもログを書き
込む。トランザクション内の中間チェックポイントへの
部分的なロールバックがサポートされる。

【００２８】ある動作のバックアウトに関して書き込ま
れるログ・レコードを、補償ログ・レコード（Compensa
ting Log Records、ＣＬＲ）と称する。ＡＲＩＥＳで
は、各ＣＬＲに、補償処置の記述の他に、そのＣＬＲが
補償するログ・レコードの前の、そのトランザクション
のログ・レコードを指すポインタが含まれる。このポイ
ンタを用いると、それまでに取り消されていないトラン
ザクションがどれだけあるかを正確に判定できる。ＣＬ
Ｒは、取消の間にどの処置を使用可能であるかを記述す
るのに使用できるので、取消処置は、補償されつつある
処置を正確に逆転したものである必要はない（すなわ
ち、論理的な取消が可能である）。

【００２９】トランザクションの異常終了の後（たとえ
ばシステム障害の後）の再始動の間に、最後の完了した
チェックポイントの最初のレコードから始めて、ログの
末尾まで、ログを走査する。この最初の「分析」パスの
間に、データ資源の永続版に含まれるものより新しい可
能性のある緩衝記憶域内のページと、中断の時点で進行
中であったトランザクションに関する情報を集める。そ
の後、中断の前に不揮発性記憶域に書き込まれなかった
更新を、クラッシュの時点で進行中であったトランザク
ションを含むすべてのトランザクションについて繰り返
す。

【００３０】これによって、クラッシュの時点でのログ
に表現された処置に関する限り、クラッシュの時点の資
源の状態が基本的に再確立される。このＲＥＤＯパスの
間に再実行される更新については、ロギングは行われな
い。

【００３１】次のパスはＵＮＤＯパスであり、このパス
の間に、進行中のすべてのトランザクションの更新が、
ログの単一の掃引によって時間的に逆の順序でロールバ
ックされる。クラッシュの時点で既にロールバック中で
あったトランザクションについては、取り消されていな
かった処置だけをロールバックする。これは、ＣＬＲに
記録された処置が絶対に取り消されない（すなわち、Ｃ
ＬＲは補償されない）ことを意味する。これが可能であ
るのは、そのようなトランザクションが再実行されるか
らであり、各トランザクションについて書き込まれた最
後のＣＬＲが、取り消す必要のある次の非ＣＬＲレコー
ドを指しているからである。

【００３２】ＡＲＩＥＳでは、この処理のいずれの間に
も、修正されたページを不揮発性記憶域に置く必要がな
い。また、回復の間にチェックポイントをとることも可
能である。トランザクション・ロールバックの間にロッ
クを取得する必要はなく、したがって、ロールバックし
つつあるトランザクションは、デッドロックに巻き込ま
れないようになっている。

【００３３】一部のオペレーティング・システムでは、
アプリケーションにオペレーティング・システム特権が
与えられない。そのような場合には、ログ・レコードの
選択的走査と、おそらくはディスクへのログの書込み
が、トランザクション処理の比較的非効率的な側面とな
り、したがって、ロギングとログからの読み取りに既知
の方法を用いてデータ一貫性をサポートする場合には、
ＢＡＣＫＯＵＴ動作が非効率的になる。同じことが、既
知のシステムの一部のＣＯＭＭＩＴ動作にもあてはまる
が、そうでない既知のシステムでは、ＣＯＭＭＩＴがト
ランザクションの解決の時点で発生すると仮定して処理
が実行され（Mohan, Lindsay, Obermarck著、"Transact
ion Management in the R* Distributed Database Mana
gement System", ACM Transactions on Database Syste
ms", Vol. 11, No. 4, １９８６年１２月を参照された
い）、その場合、ＣＯＭＭＩＴ処理のためにログ・レコ
ードを走査する必要はなく、障害の後のＢＡＣＫＯＵＴ
という例外的な場合についてのみログ・レコードを走査
する必要がある。

【００３４】

【発明が解決しようとする課題】特定のオペレーティン
グ・システムのために効率的なフォールト・トレラント
・データ処理をサポートしなければならない場合に、そ
のオペレーティング・システムの非効率的なログ走査と
いう制約の被害を受けない回復機能を提供する必要が、
ますます高まっている。

【００３５】

【課題を解決するための手段】したがって、本発明は、
トランザクションをロールバックするかまたはシステム
を再始動する必要がある場合に回復を可能にするために
システムの動作に関連するレコードが記憶され、高速の
揮発性記憶域と低速の不揮発性記憶域とを有し、前記動
作レコードのうちの少なくともいくつかが、前記不揮発
性記憶域に回復ログとして記憶されるトランザクション
・システムにおいて、少なくともいくつかの動作レコー
ドが、前記揮発性記憶域に回復リストとしても記憶さ
れ、個々のトランザクションのロールバックが、前記回
復リストの参照によって行われ、システムの再始動が、
前記回復ログの参照によって行われることを特徴とす
る、前記システムを提供する。

【００３６】別の表現でいえば、本発明は、第１プロセ
スによって１トランザクション内で実行される動作によ
って更新される資源が、そのトランザクションの解決ま
で（すなわち、そのトランザクションが成功裡に完了す
るか否かの判定まで）他のプロセスからアクセス可能に
されず、そのトランザクション内で実行される資源更新
が、トランザクションの解決の前の障害に応答して原子
的にバックアップされる、トランザクション指向データ
処理の方法であって、トランザクションの順方向処理を
実行するステップと、トランザクション内で実行され
る、回復可能資源を更新する動作ごとに、トランザクシ
ョンの解決まで揮発性メモリ内で維持される、トランザ
クション内で実行される前記動作のすべての揮発性メモ
リ・リストに、前記第１動作の識別子と操作される資源
の識別子とを含む項目を追加するステップと、トランザ
クションの解決の前のトランザクション障害に応答し
て、どの動作をバックアウトするかを判定するためその
トランザクションに関する揮発性メモリ・リストを読み
取り、揮発性メモリ・リストの情報を使用してその動作
をバックアウトするステップとを含む方法を提供する。

【００３７】揮発性メモリ・リストは、トランザクショ
ン障害が発生した時にトランザクションをバックアウト
するのに必要なすべての情報を提供し、その結果、その
ようなバックアウトを実行するためにログ・レコードを
読み取る必要がなくなる。提供される回復機能は、揮発
性メモリ・リストの他にログ・レコードを含むことが好
ましく、その場合、本発明によれば、通常処理の間にロ
グ・レコードを書込み専用レコードにすることによっ
て、ログ・レコードの使用が最適化され、ログは、シス
テム障害の後の再始動処理のためにのみ読み取られるよ
うになる。揮発性メモリ・リストは、ログ・レコードの
完全なコピーである必要はなく、通常の順方向処理とバ
ックアウト処理の実行の際に、すなわち、トランザクシ
ョン障害に応答したロールバック動作の実行と、好まし
くはコミット動作（またはコミットの確認。下を参照さ
れたい）の実行のために、そこになければログからアク
セスする必要があるはずの情報を保持するだけでよい。

【００３８】したがって、不揮発性メモリ・リストは、
この両方の機能が設けられるシステムではログ・レコー
ドの部分的な複製であることが好ましいが、これら２つ
の間には区別がある。すなわち、揮発性メモリ・リスト
は、データ（ログ・レコードの識別と、おそらくは動作
をＵＮＤＯする方法に関する情報などの追加情報）を見
つける方法に関する指示以外のデータは含まない。これ
に対して、ログ・レコードは、更新される資源を完全に
再構成するのに必要な完全な情報を含む。回復可能資源
を更新しない動作（したがって、ログ・レコードを書き
込む必要のない動作）を含めて、１トランザクション内
で実行される動作ごとに、揮発性メモリ・リストに１項
目を追加することが好ましい。トランザクション内の動
作のすべてが参照される単一のリストを設けることで、
処理の他の態様が単純になる。

【００３９】トランザクションのコミットは、正常処理
を前提とすることが好ましく、したがって、トランザク
ションが成功裡に完了する際の更新のコミットには、仮
定されたコミットの確認が含まれる。

【００４０】ある動作に関して書き込まれる１つまたは
複数のログ・レコードに、その動作のＵＮＤＯのための
情報を追加的に含めることができるが、あるタイプのＵ
ＮＤＯは、その動作自体から暗示することができ、した
がって、特定のログ・レコードを書き込む必要はない。
１つのログ・レコードが、複数の動作を組み合わせた影
響を表現でき、したがって、複数のＲＥＤＯと、任意指
定としてＵＮＤＯのための情報を提供できる。

【００４１】本発明の動作の揮発性メモリ・リストは、
当初にログ・レコードを仮想記憶域に書き込んだ後にロ
グをディスクに書き込むという従来技術の方法と比較し
て、従来技術の方法ではトランザクションの状態とは無
関係に周期的にまたは仮想記憶域の情報が所定のサイズ
に達した時のいずれかにログをディスクに書き込むとい
う点で区別される。本発明のキャッシュ・メモリ・リス
トは、まだコミットされていないトランザクションごと
の、それまでに実行されたトランザクションの全体の記
録である。既知のシステムによるディスクへのログ・レ
コードの書き込みは、その周期に関してはオペレーティ
ング・システム依存であるが、これに対して本発明は、
トランザクションに関する更新の完全な１組の別々のリ
ストである。

【００４２】バックアウトの間に、個々の動作のバック
アウトのロギングを通常通りに実行でき、バックアウト
中に書き込まれたログ・レコードが、バックアウトしな
ければならない動作に関する情報を提供するためログを
読み取る従来のバックアウト処理によって書き込まれた
のと全く同様になるという特性を有する。これによる利
益は、回復の効率が全般的に改良されることに加えて、
元々コミット動作またはバックアウト動作を実行してい
た制御のスレッドがユーザによって停止される場合に、
その動作を継続できることである。コミット処理または
バックアウト処理は、たとえば実行の実体を停止させる
ことによって中断でき、別の実行の実体によって後で再
開できる。というのは、揮発性メモリ・リストがすべて
のアプリケーションから使用可能だからである。制御の
スレッドが失われた時の回復の継続を提供できる既知の
システムには、通常のコミットまたはロールバックが実
際には実行されず、「架空の（pretend）」コミットま
たはロールバックが実施される、障害後の起動がある。
制御のスレッドが停止された時に通常の実行を継続する
能力があると、より堅牢な回復がもたらされ、既知の方
法より高い使用可能性がもたらされる。

【００４３】非持続性資源に対する操作は、ロギングさ
れない。というのは、障害の後の再始動の間にすべて削
除される、資源に対する動作を固める必要がないからで
ある。

【００４４】しばしば、複数の同時に走行するトランザ
クションが、単一のデータ資源管理プログラムの制御下
にある異なるレコードを更新する場合がある。このデー
タ資源管理プログラムは、資源を共用するための効率的
な手段をサポートしなければならず、それと同時に、２
つのトランザクションが同一のレコードを同時にアクセ
スしないようにしなければならない。このような並行性
制御を達成するのに最も一般的に使用される方法が、ロ
ックであり、この場合、所与の資源（たとえばメッセー
ジやファイル内のレコード）が、一時に１つのトランザ
クション実体に予約される。ＣＯＭＭＩＴ期間ロック
（すなわち、トランザクションがコミットされるまで残
存するロック）を、資源更新の前にその資源に対して獲
得する。他のトランザクションは、作業の単位が完了す
るまでこのロックされた資源をアクセスできない。ＣＯ
ＭＭＩＴ期間ロックはすべて、一般に、ＣＯＭＭＩＴ動
作またはＢＡＣＫＯＵＴ動作の最終ステップとして、作
業の単位の終了時に解放される。

【００４５】トランザクションの解決までオブジェクト
をロックする既知の方法には、ロックの取得に大きなオ
ーバーヘッドが伴う可能性があるという点に問題があ
る。これは、微細ロック粒度を使用する場合（たとえ
ば、ロックされるオブジェクトが、レコードを含むファ
イルや、ファイルがその一部であるデータベースではな
く、個々のレコードである場合）に、特に重要である。
一部のオペレーティング・システムは、またはロックの
ための良好なサポートを提供せず、その結果、ロックの
取得が低速であるか、またはロックの維持にかなりのア
プリケーション制御が必要になっている。また、一部の
オペレーティング・システムは、相互排他（ｍｕｔｅ
ｘ）ロックを提供せず、その結果、どの時点でも一つの
プロセスしかロックされた資源をアクセスできなくなっ
ている。

【００４６】並行トランザクション処理を備えること
が、システム応答とシステム利用の改良に望ましく、共
用ロックもサポートするシステム（個々のプロセスが、
排他的ロック自体を取得するのではなく、他のプロセス
が排他的ロックを取得できなくするロックを取得するシ
ステム）と比較して、相互排他ロックだけがサポートさ
れる場合は、明らかに並行性が低下する。しかし、資源
アクセスの並列性を設けることと、並行性制御手順のオ
ーバーヘッド（ロックを維持するコスト）の間にトレー
ドオフが存在する。相互排他ロックは、共用ロックと比
較して取得が高速であり、異なるオペレーティング・シ
ステムの間で広範囲にサポートされている。

【００４７】本発明の第２の態様は、トランザクション
内で実行される資源更新動作ごとに、更新される資源に
関する相互排他セマフォ・ロックを取得するステップ
と、動作要求に応答してトランザクション内の更新動作
を実行するステップと、動作要求を前記プロセスからア
クセス不能にする、動作がトランザクション内で実行さ
れたという事実の標識をセットするステップと、相互排
他セマフォ・ロックを解放するステップと、トランザク
ションの成功裡の完了時に、標識がセットされているト
ランザクション内のすべての動作をコミットするステッ
プと、トランザクションの解決の前の障害発生に応答し
て、標識がセットされているトランザクション内のすべ
ての動作をバックアウトするステップとを含む、トラン
ザクション内のプロセスによって実行される資源更新
が、トランザクションの解決の前の障害発生の後に原子
的にバックアウトされるか、またはトランザクションの
成功裡の完了時にコミットされる、フォールト・トレラ
ント・トランザクション指向データ処理の方法を提供す
ることである。

【００４８】相互排他セマフォ・ロックを、一時に１プ
ロセスによって資源に対して獲得して、そうでなければ
その資源を同時にアクセスする可能性のあるプロセスが
互いに干渉しないようにする。これは、トランザクショ
ンの解決まで資源更新が永続的にされない場合にデータ
保全性を保護するために重要である。相互排他ロック
は、異なるプラットホームの間で広範囲にサポートさ
れ、したがって、本発明によって提供される機能は、異
なるプラットホーム間（たとえば、ＲＥＦＥＲＥＮＣ
Ｅ、ＯＳ／２、ＯＳ／４００）で移植可能である。

【００４９】１トランザクション内で資源を更新する動
作は、標識をセットさせて、それらがトランザクション
の一部として実行されたことを示すことが好ましい。こ
の標識は、動作要求上のフラグ（待ち行列上のメッセー
ジにフラグを立てるなど）の形にすることができる。こ
の標識は、動作に対して保持されるロックとして現れ
る。したがって、標識がセットされている動作は、トラ
ンザクションの解決まで論理的にロックされ、この論理
ロックは、古典的なロック管理プログラムのオーバーヘ
ッドなしに物理的なロックと同一の目的（すなわち、他
のプロセスが特定の動作を実行しないようにすること）
を達成する。本発明のこのような実施態様では、ある資
源の更新のコミットに、フラッグの解放だけが必要であ
る。

【００５０】フラグから、どの動作が論理的にロックさ
れているかが明白なので、本発明によれば、従来技術の
方法に見られる、アプリケーションが既にロックされて
いるオブジェクトに対するロックを取得しようとした後
に、そのオブジェクトが使用不能であることを発見する
という情況が回避される。バックアウト処理および好ま
しくはコミット処理は、揮発性メモリ・リストの走査
と、項目のそれぞれのそれ相応の処理を含む。これによ
って、ログ・レコードの読み取りがうまくサポートされ
ていないオペレーティング・システムでのかなりの効率
改善が示される。

【００５１】本発明の第２の態様による方法は、回復可
能資源を更新するトランザクション内の動作のそれぞれ
について少なくとも１つのログ・レコードを書き込むス
テップを含み、前記少なくとも１つのログ・レコード
が、その動作のＲＥＤＯに十分な情報を含むことが好ま
しい。動作のＵＮＤＯのために別のログ・レコードがあ
ってもよく、また、特定の動作のＲＥＤＯとＵＮＤＯの
両方に使用できる単一の動作ログ・レコードがあっても
よい。各ログ・レコードは、複数の動作の組み合せた結
果を表すことができる。

【００５２】

【実施例】これから説明する本発明の１実施態様は、ト
ランザクションが成功裡に完了できない場合に資源更新
のＢＡＣＫＯＵＴを行う能力を提供するメッセージ待合
せのシステムおよび方法である。メッセージ待合せを用
いると、プログラムが、プログラム間の直接接続なしで
アプリケーション固有のデータを送受できるようにな
る。１つまたは複数のアプリケーション・プログラムに
とって意味のあるビットまたはバイトの列であるメッセ
ージは、記憶域内の待ち行列に置かれ、その結果、目標
アプリケーションは、目標アプリケーションが選択した
時（送出元のアプリケーションが選択した時ではなく）
に、メッセージ待ち行列からこれらのメッセージを取
り、処理できるようになる。この場合、プログラムは、
互いに独立に、異なる速度で異なる時間に走行できる。
送出元プログラムは、メッセージを送る前にトランザク
ションが成功裡に完了するかどうかをチェックする必要
がなく、目標アプリケーションは、同様に事前にチェッ
クを行わずに入力待ち行列からメッセージを取ることが
できるので、逆方向回復機能がしばしば必要になる。送
出元アプリケーションは、一般に、メッセージを送った
後に、そのメッセージの処理の結果を待たずに次の処理
タスクに進むことができる。

【００５３】メッセージは、持続性または非持続性とし
て定義できる。前者は、障害の発生の後に回復しなけれ
ばならないことを意味し、後者は、回復の必要がないこ
とを意味する。

【００５４】トランザクション内でのメッセージ待ち行
列に対する更新は、ＧＥＴ（ゲット：待ち行列からメッ
セージを取得する）動作とＰＵＴ（プット：待ち行列に
メッセージを置く）動作のシーケンスであり、これらの
動作は、トランザクションがコミットされる時（成功裡
の完了時）に原子的に発生するか、またはトランザクシ
ョンがロールバックする時に原子的に取り消される。持
続性メッセージに関するこれらのＧＥＴとＰＵＴのそれ
ぞれについて、ログ・レコードを書き込む。本発明のこ
の実施態様によれば、トランザクション内で実行される
各メッセージ動作のレコードも、揮発性記憶域のリスト
に追加される。動作は、コミットされたかのように実行
される（すなわち、トランザクションの成功裡の完了、
したがって、それに含まれるすべての動作のＣＯＭＭＩ
Ｔが仮定される。というのは、これがトランザクション
解決時の通常動作だからである）が、その結果の資源更
新は、トランザクションの解決まで、資源をアクセスす
る他のアプリケーションからアクセス不能になるように
マークされる。

【００５５】このようなシステム内の回復可能なデータ
構造が、待ち行列である。待ち行列を安定状態に戻せる
ようにするために、待ち行列のコピーを定期的に作成す
る。作成される待ち行列のコピーの間で、待ち行列上の
持続性メッセージに対して行われるすべての変更に関し
てログ・レコードを書き込む。

【００５６】図１は、１対１通信の簡単な例での、その
ようなトランザクション性メッセージ待合せシステムの
２つの通信するプログラムの間の通常処理の間のメッセ
ージの流れを示す図である。２つのプログラム１０およ
び２０は、待ち行列３０および４０を介して互いにメッ
セージを送る。メッセージ待ち行列とは、メッセージが
そこに蓄積され、後でそこから取り除かれる、名前付き
オブジェクトである。メッセージ待ち行列は、単なるス
タックではない。メッセージは、追加時には末尾に追加
され、通常は先頭から取り除かれる（ただし、待ち行列
上のメッセージの順序と異なる順序でメッセージを読み
取るための機能が存在する）。各待ち行列は、それぞれ
の待ち行列管理プログラム５０および６０（アプリケー
ションが使用するメッセージ待合せ機能を提供するシス
テム・サービス）の管理制御の下にあるが、その管理の
詳細は、アプリケーション・プログラムには明らかにさ
れない。メッセージ待合せサービスを使用可能にするた
めには、システム上に少なくとも１つの待ち行列管理プ
ログラムが必要である。１つの待ち行列管理プログラム
が、複数の待ち行列を所有できる。異なる待ち行列管理
プログラムの実体はそれぞれ、その名前によって区別さ
れ、この名前は、相互接続された待ち行列管理プログラ
ムのネットワーク内で一義的であり、その結果、ある待
ち行列管理プログラムが、所与のメッセージを送らなけ
ればならない目標待ち行列管理プログラムを明確に識別
できなければならない。

【００５７】アプリケーションは、特定の名前付きメッ
セージ待ち行列を使用することに同意することによって
通信し、特定の目標プログラムがそこからの読み取りに
同意した特定の待ち行列にメッセージを送る。これらの
待ち行列の位置は、メッセージを送るアプリケーション
には明らかでない。各アプリケーションは、その局所待
ち行列管理プログラムとだけ相互作用するのであって、
メッセージを所期の待ち行列に移動する責任を負うの
は、相互接続された待ち行列管理プログラムのネットワ
ークである。

【００５８】図１を参照すると、第１のプログラム１０
は、第２のプログラムの待ち行列３０にメッセージをプ
ットするが、専用の論理接続をこれらのプログラムの間
で確立する必要はない。このメッセージの流れを、図１
の矢印ｆ１、ｆ２、ｆ３およびｆ４によって表す。待ち
行列管理プログラム５０および６０は、メッセージがネ
ットワーク間で移動されることを保証して、プログラム
自体がネットワークの変動や複雑さから遮蔽されるよう
にする。これを、図１のネットワーク・リンク７０によ
って表す。プログラム２０は、送出元のプログラム１０
が選択した時ではなくプログラム２０側で準備ができた
時に、待ち行列３０からメッセージを取って、これを処
理する。メッセージの転送と後続の処理によって回復可
能資源に対して行われる変更は、後続の障害の場合に使
用するため不揮発性記憶域内の回復ログ８０および９０
に記録される。これらのログは、ジャーナルと称する場
合もあるが、基礎となるオペレーティング・システムが
提供する機能であり、ＩＢＭ社出版物、"AS/400 Progra
mming : Backup and Recovery Guide" (SC21-8079)に詳
しく記載されている。

【００５９】メッセージ待ち行列の維持、メッセージと
待ち行列の間の関係の維持、ネットワークの障害と再始
動の処理、および、ネットワーク内でのメッセージの移
動に伴う作業はすべて、待ち行列管理プログラムによっ
て処理される。ネットワークを横切る通信セッション
は、個々のプログラム間ではなく待ち行列管理プログラ
ム間で確立されるので、プログラムは、他のいくつかの
タイプのプログラム間通信の場合よりもネットワーク障
害に対して堅牢である。プロセッサ間のリンクに障害が
発生する場合、その障害からの回復は、待ち行列管理プ
ログラムの仕事である。影響されるプロセッサ上のプロ
グラムは、そのような事象によって停止状態にはされな
い。実際には、これらのプログラムは、それが発生した
ことを知る必要がない。

【００６０】メッセージングおよび待合せでは、アプリ
ケーションの構造に対する制約がない。図１に示される
ように、両方向相互通信ならびに１方向メッセージ・フ
ローが可能である。別々の待ち行列３０および４０が、
プログラム１０および２０のそれぞれのメッセージの受
取りのために存在する。さらに、この通信は、１対多
（単一プログラムの３つのコピーが負荷平衡のため並行
に走行しており、同一の待ち行列からメッセージを取っ
てよい場合など）または多対１（単一のサーバにメッセ
ージを送るクライアントが複数存在する場合など）もし
くはこれらの関係のすべての組み合わせとすることがで
きる。

【００６１】平常の（すなわち、再始動でない）処理の
際には、トランザクションは、順方向進行、部分的ロー
ルバックまたは全体的ロールバック（打切り）である可
能性がある。ロールバックは、システムまたはアプリケ
ーションが開始する可能性がある。ロールバックの原因
は、エラー状態、保全性制約の侵害、予期されないデー
タベース状態その他の理由があり得る。下記のデータ構
造を図１のシステムに設けて、回復を援助する。

【００６２】ロギング資源に対する変更は、回復ログ８０および９０を使用し
て記憶される。ログ・レコードには、下記の情報が含ま
れ、いくつかのタイプのログ・レコードには、他の情報
も追加される。・Ｏｗｎｅｒ（オーナー）そのログ・レコードを所有
するシステム・サブコンポーネントの名前。・Ｔｙｐｅ（タイプ）ログ・レコードのタイプ（たと
えば、補償、正常更新、またはコミット・プロトコル関
連のレコード）。・ＴｒａｎＩＤそのログ・レコードを書き込んだ関連
トランザクションが存在するならばその識別（下を参照
されたい）。・ＰｒｅｖＬＳＮこのトランザクション内の前のログ
・レコードのログ・シーケンス番号（ＬＳＮ）（各トラ
ンザクションの最初のログ・レコードでは、このフィー
ルドの値が０になる）。ログ・シーケンス番号は、ログ
上の１レコードの独自の識別子である。・Ｄａｔａ（データ）変更の前と後のイメージなど、
タイプ依存の情報を含む区域。通常はメッセージ待ち行
列識別子が含まれる。

【００６３】レコード・タイプ固有データの１例とし
て、補償ログ・レコード（ＣＬＲ）は、"ＵｎｄｏＮｅ
ｘｔＬＳＮ"と称するもう１つのＬＳＮを有する。これ
は、トランザクション・ロールバック中に取り消しを必
要とする次のログ・レコードのＬＳＮである。

【００６４】一部のログ・レコードは、更新を記述する
ためオブジェクト・カタログへ書き込まれる。オブジェ
クト・カタログとは、メッセージ待ち行列を含む、シス
テムに定義されたすべてのオブジェクトのリストであ
る。一部のログ・レコードは、シンクポイント制御の外
部にある持続性メッセージ対する動作を記述するために
書き込まれる。これらの更新は、トランザクションの内
部では発生しない。このような更新のすべてが、それが
表す論理動作ではなく、値によってロギングされる。

【００６５】ログ・レコードには、下記のタイプがあ
る。ＭＳＧＰＵＴ持続性メッセージを待ち行列にプッ
トする時に、このログ・レコードのうちの１つが書き込
まれる。これは、ＵＮＤＯ／ＲＥＤＯレコードであり、
変更を再適用または除去するのに十分な情報が含まれ
る。メッセージ・プット動作を取り消すためには、待ち
行列内のメッセージを含む待ち行列ファイルとメッセー
ジを指すポインタを含むヘッダ・ファイルの現在の状態
を知る必要がある。この情報は、メッセージ・リストに
保持される。メッセージ・リストとは、待ち行列ごとに
１つの二重リンク・リストの組であり、待ち行列上のメ
ッセージごとに１レコードが含まれる。ＰＵＴＰＡＲ
Ｔこのログ・レコードは、待ち行列に持続性メッセー
ジを書き込む時に必ず書き込まれるが、待ち行列用の空
間割振りルーチンによってばらばらの部分に分割されて
書き込まれる。これは、ＭＳＧＰＵＴログ・レコードが
ログ・レコード・サイズの限界に達し、分割が必要にな
った時にも必ず使用される。メッセージの主要部分は、
ＭＳＧＰＵＴレコードによって記述されるが、メッセー
ジの残りを記述するために複数のＰＵＴＰＡＲＴレコー
ドを書き込むことができる。これは、ＲＥＤＯＯＮＬ
Ｙ（取消専用）レコードである。ＭＳＧＧＥＴこのロ
グ・レコードのうちの１つが、持続性メッセージを待ち
行列からゲットする時に書き込まれる。これは、ＵＮＤ
Ｏ／ＲＥＤＯレコードである。メッセージ・ゲット動作
を取り消すためには、ゲットした時のメッセージを指し
ていたメッセージが変化している可能性があるので、待
ち行列ファイルの現在の状態を知る必要がある。ＱＣＲ
ＥＡＴＥ待ち行列ファイルの初期状態を記録するた
め、待ち行列の生成中に書き込まれる。ＱＡＴＴＲＳ
このログ・レコードのうちの１つが、待ち行列の属性を
更新する時に必ず書き込まれる。これは、ＲＥＤＯＯ
ＮＬＹレコードである。ＱＤＥＰＴＨディスクに記録
された待ち行列の現在の深さを更新するため、ロードさ
れた局所待ち行列ごとに、成功裡の遮断の間にこのレコ
ードのうちの１つが書き込まれる。これは、ＲＥＤＯ
ＯＮＬＹレコードである。ＰＵＲＧＥこのレコードの
うちの１つが、待ち行列が除去される時に必ず書き込ま
れる。これは、ＲＥＤＯＯＮＬＹレコードである。補
償ログ・レコード（ＣＬＲ）ロールバックの間に取り
消された変更のそれぞれを取り消すため、このレコード
のうちの１つが書き込まれる。ＣＬＲは、ロギングされ
た動作のうちで障害を発生したものを否定するためにも
書き込まれる。これは、ＲＥＤＯＯＮＬＹレコードで
ある。すなわち、このレコードは絶対に取り消されない
ので、変更を再適用するのに必要な最低限の情報だけが
含まれる。各ＣＬＲにはＵｎｄｏＮｅｘｔＬＳＮが存在
するので、ＣＬＲを用いると、それが表す変更の取消が
再始動の間に繰り返されないようになる。その代わりに
再始動では、取り消しの必要な次の変更にスキップす
る。図２にこれを示す。このレコードは、変更を正確に
物理的に逆転したものではなく、それが否定する変更の
取り消しに必要な論理動作を表すことに留意されたい。
ライトアヘッド・ロギング・プロトコルを尊重するため
には、各ＣＬＲを個別に書き込む必要がある。ＴＲＡＮ
ＴＡＢＬＥこのログ・レコードは、トランザクション
・テーブル（下を参照されたい）を記録するため、チェ
ックポイント処理の最初の部分の間に書き込まれる。Ｓ
ＴＡＲＴＴＲＡＮこのログ・レコードのうちの１つ
が、新トランザクションの始動時に書き込まれる。これ
は絶対必要ではないが、これがあるとログを読み取るの
が簡単になる。ＰＲＥＰＡＲＥこのログ・レコードの
うちの１つが、トランザクションのコミットの準備をす
る時に書き込まれる。このレコードは絶対必要である。
ＣＯＭＭＩＴこのログ・レコードのうちの１つが、ト
ランザクションをコミットすると決定する時に書き込ま
れる。ＲＯＬＬＢＡＣＫこのログ・レコードのうちの
１つが、トランザクションをロールバックすると決定す
る時に書き込まれる。ＥＮＤＴＲＡＮこのログ・レコ
ードのうちの１つが、トランザクションの完了時に書き
込まれる。トランザクションをコミットする時には、こ
のレコードのうちの１つが、そのトランザクションに関
連する他のすべてのレコードの後に続く。トランザクシ
ョンをロールバックする時には、トランザクションの変
更を除去するため、ロールバック・レコードを書き込
み、その後にＣＬＲを続け、最後にトランザクション終
りレコード（ＥＮＤＴＲＡＮ）を書き込む。ＢＥＧＩＮ
ＣＨＫＰＴこのタイプのレコードは、システム・チェ
ックポイントの開始時に書き込まれる。ＥＮＤＣＨＫＰ
Ｔこのタイプのレコードは、システム・チェックポイ
ントの終了時に書き込まれる。

【００６６】１つのトランザクションに関連するログ・
レコードは、図２に示されるように、各ログ・レコード
の"ＰｒｅｖＬＳＮ"フィールドを使用してリンクされ
る。順次ログ２００には、待ち行列更新１、２および３
を実行するトランザクションのログ・レコードが含まれ
る。ここで、このトランザクションをロールバックする
と仮定する。ログ・レコード、たとえばＲが、書き込ま
れ、補償ログ・レコード３’、２’および１’が書き込
まれる（ただし、１’は１を取り消すためのＣＬＲであ
り、他も同様である）。その後、トランザクション終り
レコードＥを書き込む。このトランザクションのログ・
レコードの間に、他のトランザクションのログ・レコー
ドがあってもよい。このトランザクションに関連するリ
ンクが、各トランザクションに、実際のログ内のそれ自
体の論理ログを提供することによって、この可能性に対
応する。

【００６７】ログは、平常処理の間には読み取られず、
したがって、データ構造回復ルーチンは、ある動作を記
録するログ・レコードが書き込まれたか否かを知らない
ので、回復の間のログ・レコードを絶対に書き込まず、
したがってログ・レコードを完全に失う危険を冒すので
はなく、回復中にもう一度ログ・レコードを書き込む危
険を冒すという方針をとる。

【００６８】トランザクション・テーブル特定の待ち行列管理プログラムのために活動状態である
トランザクションのリンク・リストを、待ち行列管理プ
ログラムが維持する。このリスト（以下、トランザクシ
ョン・テーブルと称する。図３の符号２７０である）に
含まれる各トランザクションは、独自の識別子を有す
る。具体的に言うと、このテーブルは、活動状態のトラ
ンザクションごとに、下記の情報を含む項目２６０を有
する。・そのトランザクションの独自の識別子・そのトランザクションの現在の状態（活動状態、準備
済みまたはロールバック中）・その"ＳＴＡＲＴＴＲＡＮ"ログ・レコード（すなわ
ち、新トランザクション始動時に書き込まれたログ・レ
コード）のログ・シーケンス番号（ＬＳＮ）・その最後のログ・レコードのＬＳＮ・そのソフトログ２５０（下を参照されたい）を指すポ
インタ・１つのプロセスだけが１つのトランザクションに関連
することを保証するための相互排他セマフォ・トランザクション制御ブロック（ＴＣＢ）へのアクセ
スが逐次化されることを保証するための相互排他ハンド
ル（ＴＣＢは、トランザクションを記述するデータ構造
である）。

【００６９】トランザクション・テーブルは、活動状態
のトランザクションの状態を追跡するのに使用される。
トランザクション・テーブルのうちで持続性の部分は、
障害の後のシステム再始動の間に再構成しなければなら
ない。この処理を最適化するために、その部分を、シス
テム・チェックポイントの一部として定期的にロギング
する。チェックポイントとは、オブジェクトを強制的に
ディスクに書き込む動作であり、オブジェクトを最新の
状態にするために適用する必要のあるログの量を減らす
ことによって、システム障害の後のオブジェクトの回復
に要する時間を短縮するために行われる動作である。

【００７０】ロギングされた版のトランザクション・テ
ーブルには、未確定であるすべてのトランザクションに
関して再始動中に再構成されるソフトログを指すポイン
タを除いて、メモリ内の版と同一の項目のすべてが含ま
れる。トランザクション・テーブルは、ログ・レコード
の最大サイズより大きくなる可能性があり、その場合に
は複数のレコードにロギングされる。

【００７１】ソフトログソフトログ２５０には、回復を援助するため揮発性メモ
リ内で維持されるリストが含まれる。これには、不揮発
性メモリ内のログに保持される情報の多くが複製される
が、ログと同一の情報のすべてが含まれるわけではな
い。ソフトログは、待ち行列に対するコミットまたはロ
ールバックを実施するために実行する必要がある処置の
記録を提供して、ログの選択的な逆方向走査の必要をな
くす。

【００７２】図３に概略的に示されるように、未完了の
トランザクションごとに１つのソフトログ２５０が、ト
ランザクション・テーブル２７０内のそのトランザクシ
ョンの項目２６０に付加されている。ソフトログは、関
連するトランザクション内で実行されたすべてのゲット
動作とプット動作の記録であり、すばやいコミット処理
とロールバック処理を可能にするために存在する。これ
には、トランザクションに関係がある、持続性と非持続
性の両方のメッセージ動作の項目が含まれる。対照的
に、持続性のメッセージ動作だけが、不揮発性の回復ロ
グ８０および９０にロギングされ、これには、システム
によって行われる非トランザクション性の持続性更新の
すべてが含まれる。

【００７３】トランザクションのソフトログ内には、ト
ランザクション内のメッセージ・ゲット動作とメッセー
ジ・プット動作のそれぞれについて１つの項目２８０お
よび２９０がある（通常処理の間に限る。下で説明する
ように活動状態トランザクションのソフトログが再構成
される再始動回復の間には、持続性メッセージ動作に関
する項目だけがソフトログに置かれる）。ソフトログ項
目のそれぞれには、そのソフトログ項目が記述する待ち
行列動作のロールバックに対応するＣＬＲを構成するの
に十分な情報が含まれる。

【００７４】ソフトログ項目は、下記のフォーマットを
有する。・影響されるメッセージを保持する待ち行列の識別子・その待ち行列でのメッセージの指標・項目の理由（ＧＥＴ、ＰＵＴまたはＴＲＩＧＧＥＲＰ
ＵＴ）・トランザクション内でこの動作に関して書き込まれた
ログ・レコード３００および３１０のＬＳＮ、または、
このトランザクションに関して最後にロギングされた動
作のＬＳＮ（ログ・レコード・リンクの構成に使用され
る）、もしくはその両方（この２つのＬＳＮのそれぞれ
は、他方から推論可能であるが、ソフトログ・エントリ
が両方を有してもよい）・状況フラグ。

【００７５】図３からわかるように、トランザクション
・テーブルの項目２６０は、その動作のソフトログ２５
０を指すポインタを有し、ソフトログの項目２８０およ
び２９０は、そのログ・レコード３００および３１０を
指すポインタを有する。ログ・レコードは、トランザク
ション・テーブルを指すポインタを有する。

【００７６】また、ソフトログ内の項目数に関するフィ
ールド、ソフトログ項目の最大数に関するフィールド
（ソフトログは、固定サイズのメモリ・ブロックであ
り、その要素数は、１トランザクション内で許容される
未コミットのメッセージの最大数である）、および、ソ
フトログを処理する順序を決定するのに使用される順序
フィールド（表立って配列に要素を追加することは困難
なので必要）を含むヘッダ構造がある。

【００７７】ソフトログには通常、項目が時間的な順序
で含まれ、これらの項目は、コミット処理の間には正方
向、ロールバック処理の間には逆方向に処理される。再
始動回復の間には、状況が複雑になる。というのは、ソ
フトログが、実際にはログから逆の順序で再構成される
からである。したがって、再始動処理中のコミット処理
とロールバック処理では、通常実行の間に使用されるの
と反対の順序でソフトログを処理する。

【００７８】システム・チェックポイントの一部として
ログ内にソフトログを記録することも可能ではあるが、
これは高価につく可能性があるので、その代わりに、後
に説明するように、システム障害からの回復の間に、通
常は低い頻度でソフトログを構成する。

【００７９】作業を含まないトランザクションは、トラ
ンザクション・テーブル内に項目を有するが、関連ソフ
トログには項目が含まれない。したがって、そのような
空のトランザクションのコミット処理とロールバック処
理では、ソフトログ項目を処理する必要がない。

【００８０】ロック単純な相互排他セマフォを使用して、ロック管理プログ
ラムの必要なしに、したがって、機能の充実したロック
管理プログラムを有しないシステムへの移植性という利
益を伴って（ただし、多少の並行性が失われるという犠
牲を伴う）、共用情報へのアクセスを制御する。セマフ
ォ・「ロック」の対象は、待ち行列であり、その待ち行
列上のすべてのメッセージの暗黙のロックが提供され
る。各待ち行列は、１時に１つのプロセスだけが保持で
きる相互排他セマフォを有し、各プロセスは、１時に１
つの相互排他だけを保持できる（いくつかの特殊な場合
を除く）。待ち行列のデータ構造のいずれかをアクセス
するには、この相互排他を取得し、アクセスを実行した
後に、相互排他を解放しなければならない。この技法だ
けでは、シンクポイント制御の下でのメッセージ・プッ
トの場合に不十分になるはずである。というのは、トラ
ンザクション全体にわたって待ち行列をロックしてはな
らないからである。ある待ち行列がアンロードまたは削
除されないように、その待ち行列が活動状態のトランザ
クションに関連するかどうかを知る必要がある。これを
達成するために、待ち行列のそれぞれに関連するカウン
タがあり、これは、その待ち行列にある未コミットのメ
ッセージ数である。

【００８１】未コミットのトランザクションによってプ
ットまたはゲットされたので使用できないメッセージ
は、メッセージがトランザクション内でゲットまたはプ
ットされたことを示す標識をセットすることによって、
そのメッセージ・リスト内で不可視としてマークされ、
その結果、待ち行列の走査では、これらが無視される。
これによって、ロック管理プログラムが個々のメッセー
ジに対する排他ロックを保持する必要がなくなる。

【００８２】図４は、１トランザクション内での成功裡
の完了までのメッセージの正方向処理の全般的なステッ
プを示す図である。まず、待ち行列をサービスするアプ
リケーションが、メッセージ待ち行列に対する相互排他
ロックを取得し（４００）、他のアプリケーションがそ
の待ち行列をアクセスしないようにする。明らかに、こ
れによって、個々のメッセージをロックすることほど高
度な並行性は提供されないが、このロック制御手順は、
高粒度ロックの場合より単純である。これがトランザク
ションの開始である場合、その開始に関するログ・レコ
ードを書き込み（４１０）、トランザクション・テーブ
ル内にそのトランザクションに関する項目を原子的に作
成する（４２０）。そうでない場合、現在のトランザク
ション項目の位置を突き止める（４３０）。

【００８３】その後、メッセージを操作する（４４
０）。ＧＥＴ動作で待ち行列からメッセージを取得する
（取得するアプリケーションによって処理されるメッセ
ージの場合。受取り側アプリケーションが目標アプリケ
ーションでない場合には、別の待ち行列にＰＵＴする）
か、ＰＵＴ動作で待ち行列にメッセージをプットする。
シンクポイント制御の下のすべてのメッセージ動作は、
ＰＵＴとＧＥＴのシーケンスである。詳細にいえば、Ｐ
ＵＴ動作の場合のステップ４４０には、下記のサブステ
ップが含まれる。ａ）メッセージを置く場所を突き止め、前のメッセージ
を識別するｂ）持続性メッセージの場合、すべての詳細をロギング
するｃ）選択された空間にメッセージを書き込むｄ）待ち行列にリンクを書き込むｅ）待ち行列に関するメモリ・リストに追加するＧＥＴ動作の場合、下記のサブステップが含まれるはず
である。ａ）メモリ・リスト内でメッセージを突き止めるｂ）メッセージの詳細を読み取るｃ）ｉｆ持続性メッセージの場合前のメッセージと後のメッセージを識別する詳細をロギングする待ち行列にリンク解除を書き込むＥｎｄｉｆｄ）メモリ・リストから除去する

【００８４】動作のこの実行に対して原子的に、メッセ
ージに、トランザクション内で操作されたものとして第
１の待ち行列内でフラグを立て（４５０）、ソフトログ
内でその動作に関する項目を作成する（４６０）。この
メッセージは、現在、その待ち行列をサービスする他の
アプリケーションから使用不能である。

【００８５】このアプリケーションはここで、他のアプ
リケーションがその待ち行列をサービスしないようにす
る必要がなくなったので、相互排他制御ロックを解放す
る（４７０）。操作されるメッセージは、待ち行列から
除去されたものとしてフラグを立てられたままになり、
したがって、アプリケーションから使用不能である。こ
のフラグは、メッセージに対する排他ロックとして働
く。その後、トランザクションが完了するまで、そのト
ランザクション内の他のメッセージに対して上のステッ
プを繰り返す（４８０）。トランザクションの成功裡の
完了時に、ログ・レコードを書き込んでトランザクショ
ンの終りをマークし（４９０）、そのトランザクション
内でゲットされたフラグを立てられたメッセージのすべ
てを入力待ち行列から原子的に削除し（５００）、その
トランザクション内でプットされたメッセージのすべて
のフラグを削除する。

【００８６】トランザクション内で実行された動作のい
ずれかが、エラー状態を発生するか、他のデータ保全性
制約のいずれかが侵害された場合、そのトランザクショ
ンの完了は許可できず、ロール・バックしなければなら
ない。ロールバック手順には、そのトランザクション内
でゲットしたメッセージのフラグを削除し、その結果、
待ち行列上でこれらをもう一度使用可能にすることと、
そのトランザクション内でＰＵＴされたメッセージを削
除することと、正方向処理の間に書き込まれたログ・レ
コードの補償ログ・レコードを書き込むことが含まれ
る。

【００８７】トランザクションは、解決の前に複数の段
階を通過する。トランザクションの各相の間に、異なる
処理が実行される。トランザクション管理プログラム
は、トランザクションがある相から別の相に移ったこと
を示す責任を負う。

【００８８】下記の諸ステップが、トランザクションの
相ごとに実行される。

【００８９】コミットの準備準備の時点で、"ＰＲＥＰＡＲＥ"ログ・レコードを書き
込まなければならない。

【００９０】この段階中に、待ち行列管理プログラム
は、要求された時にコミットできることを保証すること
が期待される。トランザクション内部のすべての変更
が、すでにログに固められている場合、準備を求められ
たという事実を記録するだけで十分である。したがっ
て、待ち行列管理プログラムは、このログ・レコードの
書込みが不可能でない限り、準備要求に対して必ず"ｙ
ｅｓ"を投票し、書込不可能の場合には"ｎｏ"を投票す
る。

【００９１】コミットトランザクションをコミットする時には、"ＣＯＭＭＩ
Ｔ"ログ・レコードを書き込む。これは、異なるシステ
ムの間での移植性にとって望ましい。というのは、すべ
てのトランザクション管理プログラムが、監視されるコ
ミットのロギングという状況を処理できるとは限らない
からである。

【００９２】トランザクションに関連するソフトログを
検査して、トランザクションの結果としてどのメッセー
ジがプットまたはゲットされたかについての詳細を得
る。ソフトログの走査と各レコードの処理は、必要に応
じて待ち行列をロックまたはロック解除しながら、下記
のように行われる。ＭＳＧＰＵＴ関連メッセージを可
視にし、未コミットのメッセージの数を減らす。メッセ
ージ待ち行列管理プログラムの局所待ち行列管理プログ
ラム構成要素に、待機中のゲット要求を満足する可能性
のあるメッセージが待ち行列に現れたことを知らせる。
ＭＳＧＧＥＴメッセージが占める空間を解放し、メッ
セージを待ち行列から除去する。未コミット・メッセー
ジ・カウントを減らす。

【００９３】最後に、"ＥＮＤＴＲＡＮ"ログ・レコード
を書き込む。

【００９４】ロールバックトランザクションをロールバックする時には、"ＲＯＬ
ＬＢＡＣＫ"ログ・レコードを書き込まなければならな
い。

【００９５】トランザクションに関連するソフトログを
検査して、トランザクションの結果としてどのメッセー
ジがプットまたはゲットされたかについての詳細を得
る。ソフトログの走査と各レコードの処理は、必要に応
じて待ち行列をロックまたはロック解除しながら、下記
のように行われる。ＭＳＧＰＵＴ前のメッセージから
のリンクが次のメッセージ（存在するならば）を指すよ
うに変更することによって、メッセージを待ち行列から
除去しなければならない。メッセージが持続性であった
場合には、この変更の前に補償ログ・レコードを書き込
んで、この更新を記述しなければならない。メッセージ
によって占められていた空間を解放し、未コミット・メ
ッセージ数を減らす。ＭＳＧＧＥＴ前のメッセージ
（存在するならば）のポインタがこのメッセージを指す
ように変更することによって、メッセージを待ち行列上
で復元しなければならない。メッセージが持続性であっ
た場合には、補償ログ・レコードを書き込んでこの更新
を記述しなければならない。メッセージを可視にし、未
コミット・メッセージ・カウントを減らす。メッセージ
のバックアウト・カウントを増やす。未コミットのゲッ
ト・メッセージによって占められる空間は、関連トラン
ザクションがコミットされるまで解放されないので、ロ
ールバックの間にこのメッセージのために空間を再利用
する必要はない。

【００９６】最後に、"ＥＮＤＴＲＡＮ"ログ・レコード
を書き込む。

【００９７】ＭＳＧＰＵＴログ・レコードとＭＳＧＧＥ
Ｔログ・レコードには、それが変更しつつある区域の前
のイメージは含まれない。これは、単純にログから読み
取るのではなく、この動作の逆を推測しなければならな
いことを意味する。これは、待ち行列の内容の知識を使
用して行われる。

【００９８】再始動システム障害または、単一のトランザクションを越える
範囲に広がる他の障害の場合、不揮発性記憶域からのロ
グ・レコードを使用して処理を再始動しなければならな
い。

【００９９】再始動処理には、ログの３回のパス、すな
わち、再実行パス、未確定パスおよび取消パスが含まれ
る。待ち行列と他のオブジェクトのそれぞれを、必要に
応じてアクセスする。回復に参加しない待ち行列は、ロ
ードしない。回復を正しく進行できるようになる前に、
オブジェクト・カタログを読み込む必要がある。これは
損傷を受けていないと仮定され、損傷の場合には、デー
タ回復のために、それ自体は損傷を受けていないカタロ
グのバックアップ・コピーを提供する必要がある。

【０１００】再実行パス再実行パスは、待ち行列管理プログラムが動作を開始す
る前の再生の状態の確立に関係がある。このパスが完了
する前には、待ち行列ファイルに意味があるとは限らな
い。というのは、待ち行列ファイルに不完全な更新が含
まれる可能性があるからである。このパスは、前のシス
テム・チェックポイント・レコード（存在するならば）
の読み取りから始まる。この位置は、再始動レコードに
保持されている。チェックポイントには、ログの最初の
走査の間に使用されるトランザクション・テーブルが含
まれる。オブジェクト・カタログは、この処理が始まる
前にロードされることになる。というのは、有効なオブ
ジェクトの知識が必要になるからである。

【０１０１】ログを順方向に走査し、現在のチェックポ
イントからログの末尾までのログ・レコードのそれぞれ
について、下記の処置を実行する。１．そのログ・レコードによって既知のトランザクショ
ンの状態が有効な形で変更される場合、必要に応じてト
ランザクションの状態を変更し、完了したならばトラン
ザクションをトランザクション・テーブルから除去す
る。これには、トランザクション・テーブル内のそのト
ランザクションの最後のログ・レコードのＬＳＮを更新
することが含まれる。２．そうでない場合、ログ・レコードに詳細を記された
変更を適用する。存在しないオブジェクト（削除された
可能性がある）に適用されるレコードは、すべて無視さ
れる。

【０１０２】この処理には、必要な時にトランザクショ
ン・テーブル内のそのトランザクションの最後のログ・
レコードのＬＳＮを更新することが含まれる。

【０１０３】この相が終る時点で、最後のチェックポイ
ント以降の変更のすべてが待ち行列に再適用されている
ことになり、トランザクション・テーブルは、待ち行列
管理プログラムが停止した時の状態と矛盾しない状態に
なる。

【０１０４】この時点で、後続の再始動中の再再生の量
を減らすためにチェックポイントをとる。

【０１０５】未確定パス活動状態のどのトランザクションについても、コミット
処理またはロールバック処理を可能にするためには、そ
れに関連するソフトログ２５０を再構成する必要があ
る。これは、未確定トランザクションごとに、ログ・レ
コードのＰｒｅｖＬＳＮ連鎖に従ってログを逆方向に走
査することによって行われる。１．トランザクション・テーブル内のトランザクション
ごとに、ＰｒｅｖＬＳＮ連鎖に従うことによってそのト
ランザクションのログ・レコードの連鎖に沿って逆方向
に走査する。トランザクション内でＣＬＲが見つかる場
合には、その代わりに、このレコードのＮｅｘｔＵｎｄ
ｏＬＳＮリンクに従う（既に取り消されているログ・レ
コードをスキップするため）。２．見つかった"ＭＳＧＰＵＴ"ログ・レコードまたは"
ＭＳＧＧＥＴ"ログ・レコードのそれぞれについて、ど
の待ち行列のどのメッセージが使用されたかを確立し、
必要があればディスクからメッセージを見つけ、そのト
ランザクションに関するソフト・ログに変更を記述した
項目を追加する。メッセージ・リスト内でメッセージを
隠しとしてマークし、未コミット・メッセージの数を減
らさなければならない。

【０１０６】ログのこのパスは、記録された最後のチェ
ックポイントの先頭を越えて逆方向に継続する可能性が
ある。というのは、最も古い活動状態のトランザクショ
ンの先頭まで読み戻す必要があるからである。

【０１０７】このパスが終わる時点で、各トランザクシ
ョンは、そのソフト・ログを変更されておらず、コミッ
ト要求またはロールバック要求の処理の準備ができてい
る。コミットまたはロールバックされたトランザクショ
ンによってプットまたはゲットされたメッセージは、す
べてが必要な状態になっている。未準備のトランザクシ
ョンのロールバックだけが残されている。

【０１０８】取消パスこのパスは、未準備のトランザクションのロールバック
に関係する（システムが停止した時に部分的にロールバ
ックされていたトランザクションが、未準備としてマー
クされていたことを想起する）。これらのトランザクシ
ョンのそれぞれのソフトログは、未確定パスで再構成さ
れているので、これらのトランザクションのそれぞれに
ついて、単に通常のロールバック処理を呼び出すことが
できる。

【０１０９】単一パスの非常に多数のログ・レコードの
ログ読取をもたらす代替設計が、時間的に厳密に逆の順
序で必要な更新を取り消すことである。これには、ルー
プを介するパスのそれぞれで異なるトランザクションか
らの更新を取り消すことが含まれる可能性がある。この
設計の短所は、ループのパスのそれぞれでトランザクシ
ョン・テーブルを検査して、どのトランザクションが最
大のＵｎｄｏＮｅｘｔＬＳＮを有するかを知り、この更
新を最初に取り消さなければならないことである。すべ
ての取消動作が論理更新として実行され、どのような順
序でも適用できるので、これは必要ない。

【０１１０】取消パスが終わる時点で、待ち行列ファイ
ルは、待ち行列を表すメモリ構造と矛盾しない状態であ
り、ロールバックの必要があるすべてのトランザクショ
ンが、ロールバックされている。この時点で、待ち行列
管理プログラムが作業を受け入れ始めることができる。

【０１１１】最後のステップは、システム・チェックポ
イントを取り、再始動の間にロードされたすべての待ち
行列をアンロードすることである。

【０１１２】まとめとして、本発明の構成に関して以下
の事項を開示する。

【０１１３】（１）高速の揮発性記憶域と低速の不揮発
性記憶域とを有し、トランザクションをロールバックす
るかまたはシステムを再始動する必要がある場合に回復
を可能にするために、システムの動作に関連するレコー
ドが前記不揮発性記憶域に回復ログとして記憶される、
トランザクション処理システムであって、前記動作レコ
ードを前記揮発性記憶域に回復リストとして記憶する手
段と、個々のトランザクションのロールバックを前記回
復リストの参照によって行う手段と、システムの再始動
を前記回復ログの参照によって行う手段を有する、トラ
ンザクション処理システム。（２）前記動作レコードが、対応する動作が実行される
前に、前記回復ログおよび回復リストに記憶される、上
記（１）に記載のシステム。（３）回復リストが、処理されるトランザクションごと
に作成される、上記（１）または（２）に記載のシステ
ム。（４）動作を、持続性または非持続性として、かつトラ
ンザクション性または非トランザクション性として定義
でき、持続性動作レコードのすべてが、前記回復ログに
記憶され、持続性動作および非持続性動作の両方を含む
トランザクション性動作レコードのすべてが、前記回復
リストに記憶される、上記（１）乃至（３）に記載のシ
ステム。（５）前記回復ログから１つまたは複数の前記回復リス
トを再構成し、これによって再始動中のトランザクショ
ンのロールバックが前記再構成された１つまたは複数の
回復リストを参照するようにするためにシステムの再始
動中に動作できる手段を含む、上記（１）乃至（４）に
記載のシステム。（６）その動作に待ち行列へのメッセージのプットと待
ち行列からのメッセージのゲットとが含まれるメッセー
ジングおよび待合せシステムである、上記（１）乃至
（５）に記載のシステム。（７）トランザクションをロールバックするかまたはシ
ステムを再始動する必要が生じた場合に回復を可能にす
るため、システムの動作に関連するレコードを記憶する
ステップと、前記動作レコードを、低速不揮発性記憶域
内に回復ログとして記憶するステップとを含む、フォー
ルト・トレラント・トランザクション処理の方法におい
て、さらに、前記動作レコードを、高速揮発性記憶域内
に回復リストとして記憶するステップと、前記回復リス
トを参照することによって個々のトランザクションのロ
ールバックを行うステップと、前記回復ログを参照する
ことによってシステムの再始動を行うステップとを含む
方法。（８）前記回復ログおよび回復リストに動作レコードを
記録する前記ステップの後に、トランザクションを処理
するためシステムの対応する動作を実行するステップを
含む、上記（７）に記載の方法。（９）処理されるトランザクションごとに回復リストを
作成するステップを含む、上記（７）または（８）に記
載の方法。（１０）システム動作を、持続性または非持続性とし
て、かつトランザクション性または非トランザクション
性として定義でき、持続性動作レコードのすべてが、前
記回復ログに記憶され、トランザクション性動作レコー
ドのすべてが、持続性であるか否かにかかわらず、前記
回復リストに記憶される、上記（７）乃至（９）に記載
の方法。（１１）システムの再起動を行うステップが、さらに、
前記回復ログから１つまたは複数の前記回復リストを再
構成するステップと、前記再構成された１つまたは複数
の回復リストを参照することによって再始動の間にトラ
ンザクションのロールバックを行うステップを含む、上
記（７）乃至（１０）に記載の方法。（１２）トランザクション内で実行される資源更新動作
ごとに、更新される資源に関する相互排他セマフォ・ロ
ックを取得するステップと、動作要求に応答してトラン
ザクション内の更新動作を実行するステップと、動作要
求を前記プロセスからアクセス不能にする動作が、トラ
ンザクション内で実行されたという事実の標識をセット
するステップと、相互排他セマフォ・ロックを解放する
ステップと、トランザクションの成功裡の完了時に、標
識がセットされているトランザクション内のすべての動
作をコミットするステップと、トランザクションの解決
の前の障害発生に応答して、標識がセットされているト
ランザクション内のすべての動作をバックアウトするス
テップとを含み、トランザクション内のプロセスによっ
て実行される資源更新が、トランザクションの解決の前
の障害発生の後に原子的にバックアウトされるか、また
はトランザクションの成功裡の完了時にコミットされ
る、フォールト・トレラント・トランザクション指向デ
ータ処理の方法。

【０１１４】

【発明の効果】上述のように、本願発明によれば、特定
のオペレーティング・システムのために効率的なフォー
ルト・トレラント・データ処理をサポートしなければな
らない場合に、そのオペレーティング・システムの非効
率的なログ走査という制約の被害を受けない回復機能が
提供されることとなった。

【図面の簡単な説明】

【図１】トランザクション指向メッセージングおよび待
合せシステムで互いに通信する２つのプログラムの概略
図である。

【図２】本発明の１実施例によるログ・レコード間のリ
ンクを概略的に示す図である。

【図３】本発明の１実施例による、トランザクション・
テーブル間の相互関係、トランザクションに関する動作
の揮発性メモリ・リストの組、および、回復ログ内の動
作のレコードを示す図である。

【図４】本発明の１実施例による、成功裡に完了するト
ランザクションの正方向処理の間に実行される動作のシ
ーケンスを示す図である。

【符号の説明】

１０プログラム２０プログラム３０待ち行列４０待ち行列５０待ち行列管理プログラム６０待ち行列管理プログラム７０ネットワーク・リンク８０回復ログ９０回復ログ２００順次ログ２５０ソフトログ２７０トランザクション・テーブル２８０（ソフトログ）項目２９０（ソフトログ）項目３００ログ・レコード３１０ログ・レコード

───────────────────────────────────────────────────── フロントページの続き (72)発明者アンソニー・ロバート・ウォッシャイギリスエス・オー51 ７アール・ジーハンプシャー州ロムビイクローバー・ウェイ27

Claims

【特許請求の範囲】

【請求項１】高速の揮発性記憶域と低速の不揮発性記憶
域とを有し、トランザクションをロールバックするかま
たはシステムを再始動する必要がある場合に回復を可能
にするために、システムの動作に関連するレコードが前
記不揮発性記憶域に回復ログとして記憶される、トラン
ザクション処理システムであって、前記動作レコードを前記揮発性記憶域に回復リストとし
て記憶する手段と、個々のトランザクションのロールバックを前記回復リス
トの参照によって行う手段と、システムの再始動を前記回復ログの参照によって行う手
段とを有する、トランザクション処理システム。
【請求項２】前記動作レコードが、対応する動作が実行
される前に、前記回復ログおよび回復リストに記憶され
る、請求項１に記載のシステム。
【請求項３】回復リストが、処理されるトランザクショ
ンごとに作成される、請求項１または請求項２に記載の
システム。
【請求項４】動作を、持続性または非持続性として、か
つトランザクション性または非トランザクション性とし
て定義でき、持続性動作レコードのすべてが、前記回復
ログに記憶され、持続性動作および非持続性動作の両方
を含むトランザクション性動作レコードのすべてが、前
記回復リストに記憶される、請求項１、請求項２、また
は請求項３に記載のシステム。
【請求項５】前記回復ログから１つまたは複数の前記回
復リストを再構成し、これによって再始動中のトランザ
クションのロールバックが前記再構成された１つまたは
複数の回復リストを参照するようにするためにシステム
の再始動中に動作できる手段を含む、請求項１、請求項
２、請求項３、または請求項４に記載のシステム。
【請求項６】その動作に待ち行列へのメッセージのプッ
トと待ち行列からのメッセージのゲットとが含まれるメ
ッセージングおよび待合せシステムである、請求項１、
請求項２、請求項３、請求項４、または請求項５に記載
のシステム。
【請求項７】トランザクションをロールバックするかま
たはシステムを再始動する必要が生じた場合に回復を可
能にするため、システムの動作に関連するレコードを記
憶するステップと、前記動作レコードを、低速不揮発性記憶域内に回復ログ
として記憶するステップとを含む、フォールト・トレラ
ント・トランザクション処理の方法において、さらに、前記動作レコードを、高速揮発性記憶域内に回復リスト
として記憶するステップと、前記回復リストを参照することによって個々のトランザ
クションのロールバックを行うステップと、前記回復ログを参照することによってシステムの再始動
を行うステップとを含む方法。
【請求項８】前記回復ログおよび回復リストに動作レコ
ードを記録する前記ステップの後に、トランザクション
を処理するためシステムの対応する動作を実行するステ
ップを含む、請求項７に記載の方法。
【請求項９】処理されるトランザクションごとに回復リ
ストを作成するステップを含む、請求項７または請求項
８に記載の方法。
【請求項１０】システム動作を、持続性または非持続性
として、かつトランザクション性または非トランザクシ
ョン性として定義でき、持続性動作レコードのすべて
が、前記回復ログに記憶され、トランザクション性動作
レコードのすべてが、持続性であるか否かにかかわら
ず、前記回復リストに記憶される、請求項７、請求項
８、または請求項９に記載の方法。
【請求項１１】システムの再起動を行うステップが、さ
らに、前記回復ログから１つまたは複数の前記回復リス
トを再構成するステップと、前記再構成された１つまた
は複数の回復リストを参照することによって再始動の間
にトランザクションのロールバックを行うステップを含
む、請求項７、請求項８、請求項９、または請求項１０
に記載の方法。
【請求項１２】トランザクション内で実行される資源更
新動作ごとに、更新される資源に関する相互排他セマフ
ォ・ロックを取得するステップと、動作要求に応答してトランザクション内の更新動作を実
行するステップと、動作要求を前記プロセスからアクセス不能にする動作
が、トランザクション内で実行されたという事実の標識
をセットするステップと、相互排他セマフォ・ロックを解放するステップと、トランザクションの成功裡の完了時に、標識がセットさ
れているトランザクション内のすべての動作をコミット
するステップと、トランザクションの解決の前の障害発生に応答して、標
識がセットされているトランザクション内のすべての動
作をバックアウトするステップとを含み、トランザクション内のプロセスによって実行される資源
更新が、トランザクションの解決の前の障害発生の後に
原子的にバックアウトされるか、またはトランザクショ
ンの成功裡の完了時にコミットされる、フォールト・トレラント・トランザクション指向データ
処理の方法。