【発明の詳細な説明】
トランザクションの状態の追跡
著作権注意書
この特許文書の開示の一部は、著作権保護の対象であるマテリアルを含む。著
作権の所有者は、特許及び商標局の特許ファイルまたは記録にそれが表される完
全な形式の特許文書または特許開示のあらゆる人による電子写真式再生に異義は
ないが、それ以外はいかなるものについても著作権の権利を留保する。発明の分野
本発明は、データ処理システムに関し、より特定的には、トランザクション管
理を供給しかつユーザ・データの完全性(integrity)を保護するためにオンライ
ン・トランザクション処理に関するデータを追跡（トラッキング）しかつ制御す
る並列処理システムに関する。発明の背景
オンライン・トランザクション処理（“ＯＬＴＰ”）は、例えば、金融のトラ
ンザクションを支援すること（例えば、銀行ＡＴＭｓからの情報をコーディネー
トすること）、ニューヨーク証券取引所に対するデータを追跡すること、電話会
社に対する請求書を追跡すること、及び製品に対する部品（例えば、自動車部品
）を追跡することのような今日の産業において種々のコマーシャル・アプリケー
ションを見出した。ＯＬＴＰに対して利用可能なコマーシャル・アプリケーショ
ンの多くは、エンド・ユーザに対するＯＬＴＰアプリケーションへの連続的利用
可能性と一緒にユーザ・データの完全性の精緻保護(elaborate protection)を必
要とする。例えば、銀行のＡＴＭｓは、優れた完全性を有さなければならない（
即ち、もしあれば、エラーを最小にする）し、かつＡＴＭｓは、拡張された期間
に対してユーザに利用可能でなければならない。ＡＴＭユーザは、それらのトラ
ンザクションに関連付けられた失敗（例えば、ユーザの口座にクレジットされて
い
ない＄５００．００入金）を許容しない。更に、ＡＴＭｓは、一日２４時間、一
週間７日、しばしばユーザに利用可能であるのが好ましい。
ＯＬＴＰアプリケーションにおける連続利用可能性を達成するために、ユーザ
は、支持（支援）システム・ソフトウェアに依存することができなければならな
い。並列処理（プロセス・ペアを利用する処理）は、ＯＬＴＰに複数のプロセッ
サ間に分配された多数の個々のトランザクションまたは小さなタスクを素早く処
理させることにおいて支援する。他の並列処理アプリケーションは、記録保持及
び意思決定動作に対してまたは多くのユーザに対して情報のアクセス可能な記憶
を供給するメディア・サーバとして、大きいデータベースを保守しかつアクセス
することを含む。並列処理の特定な利点は、例えば、多数の記憶機器間に分散す
ることができる多種多様な情報の検索を必要としうる意思決定動作におけるよう
な大量の多種多様なデータを扱うための能力（機能）に存在する。更に、並列プ
ロセッサ・メディア・サーバ・アプリケーションは、非常に多数のカスタマ（顧
客）に、検索可能メモリ（例えば、ディスク記憶機器）に維持された映画の大き
なリザボアへのアクセスを供給すように並列プロセッサに要請する、“movies-o
n-demand（ムービーズ・オン・ディマンド）”のような対話的サービス環境にあ
りうる。この後者のアプリケーションは、要求された映画を捜し出し、選択し、
かつ検索し、そして要求している顧客にセレクションを送ることによって、複数
の要求を同時にサービスすべく並列プロセッサをかなり必要としうる。発明の目的および概要
並列処理がＯＬＴＰケイパビリティを増大すると同時に、トランザクション管
理が供給されかつ（２）データの完全性が保護されるようなＯＬＴＰに関するデ
ータをトラッキング及びコントローリングするための技術が必要である。
好ましい実施例では、トランザクション・モニタリング・ファシリティ（トラ
ンザクション監視設備(Transaction Monitoring Facility)ＴＭＦ）は、トラン
ザクション管理を供給しかつユーザ・データの完全性を保護する。“transactio
（トランザクション）”と呼ばれるプログラム的構造は、データベースの内容を
一つの一貫的状態(consistent state)から別の一貫的状態に変える、明示的に区
切られた動作、または関連動作の組である。トランザクション内のデータベース
動作は、単一ユニットとして処理される。トランザクションによって実行された
変更の全てが完遂されかつパーマネント（永続）にされるか、またはいずれの変
更もパーマネントにされない（トランザクションは、中止される）。トランザク
ションの実行中に故障が発生したならば、データベースに対してなされたいかな
る部分的変更も自動的に取り消され、それゆに、データベースを一貫的状態のま
まにする。
一つの好ましい実施例では、本発明は、それがオリジナル・ワークを処理する
ようにトランザクションに対する取消しワーク(undo work)を処理する方法を提
供する。特に、同じ方法は、ログ記録（またはオーディット・トレール(Audit T
rail)記録）がディスクに定着されかつ失われたログ記録が、もし存在するなら
ば、確実に検出されるということを確実にするために用いられる。方法は、また
、更新に対する新しく到着した要求が中止されたトランザクションがそれにより
動作されないようにあまりにも遅く到着した場合を決定することもできる。
本発明の別の好ましい実施例では、トランザクション制御ブロック“fault-in
（フォールト・イン）”が利用される。この特徴は、そのような構造が既に存在
していないならば、ＣＰＵにトランザクション・コントロール・ブロック（Tran
saction Control Block（ＴＣＢ））データ構造を生成するための機能（能力）
を取り扱う。ＴＣＢは、個人フィールドを有するパブリック（大衆）コンテナー
であり、かつそれは、その関連トランザクションに対する説明（記述）を供給す
る。各フィールドに対するコメントは、どのモジュールがどのフィールドへのア
クセスを有するかを特定する。
ＴＣＢデータ構造を利用することによって、システムは、トランザクションの
開始において各ＣＰＵにＴＣＢを割り当てないで線形性（リニアリティ）を改良
する。代わりに、各ＣＰＵは、最も高いシーケンス番号及びそのシーケンス番号
に関連付けられた最も高いエポック・フィールドを含んでいる表を有する。ＴＣ
ＢがＣＰＵで生成される必要がある場合、表におけるシーケンス番号及びエポッ
ク番号は、ＴＣＢの“フォールティング・イン(faulting in)”を許容すべく適
切な値を有さなければならない。“フォールティング・イン(faulting in)”
は、要求がＣＰＵに到着するがＴＣＢが存在しない場合に生じ、それゆえにＴＣ
Ｂが生成される。ある一定のシーケンス番号に対する値が適切でないならば、フ
ォールト・インは、それが“あまりにも遅い(too late)”ので拒否される。これ
は、トランザクションがある他のＣＰＵ における故障による中止の処理にある
か、またはトランザクションがあまりにも古いので長期間にわたりシステムから
離れてしまっているならば、一般に生じる。古いトランザクションのフォールト
・インは、サーバがその現行トランザクションとしてトランザクションを有しか
つトランザクションが完全に中止された後にそれを用いることを試みるならば要
求することができる。
上示した設計特徴を含むことによって、ＴＭＦは、その利用可能性を改良し、
管理することがより容易であり、かつ向上した性能を有する。
これら及び他の利点は、添付した図面に共に取り入れられるべきである、本発
明の以下の詳細な説明を読むことによりこの分野における当業者に対して明らか
になるであろう。図面の簡単な説明
図１は、２から１６のプロセッサを有するプロセッサ・システムの簡略化され
た図である；
図２は、複数のＣＰＵ’ｓが同じトランザクション上で動作しうる方法を示す
；
図３は、システム内のＣＰＵｓに配置される対応スタックを示す；
図４は、要求がＣＰＵによって受け取られるときに発生する処理に対するシー
ケンス・フロー・チャートを供給する；
図５は、フェーズ１(Phase 1)時間で行われる処理に対するシーケンス・フロ
ー・チャートを供給する；
図６は、フェーズ２(Phase 2)時間で行われる処理に対するシーケンス・フロ
ー・チャートを供給する；及び
図７は、システムのＣＰＵｓの数が増大されるときに本発明のスループットが
改良される方法を示すグラフである。実施例
ここで図、さしあたり主に図１を参照すると、簡略化された形式で示されるの
は、参照番号１０で一般的に指定された、２〜１６のプロセッサを有するプロセ
ッサ・システムである。図示するように、プロセッサ・システム１０は、複数の
プロセッサ１２、１４、．．．（ＣＰＵｓ）を備えている。各ＣＰＵ１２、１４
、．．．は、それ自体のＲＡＭ２２、２４、．．．を含む。２〜１６のＣＰＵｓ
は、二つの高速バス２６及び２８によって接続され、かつ各ＣＰＵ１２、１４、
．．．は、それ自体の入出力回線３０、３２、．．．（Ｉ／Ｏ）を有する。Ｉ／
Ｏ回線３０、３２、．．．は、ＣＰＵｓ１２、１４、．．．をディスク・コント
ローラ３４及び通信コントローラ３６に接続する。
ディスク・コントローラ３４は、Ｉ／Ｏバス３０、３２、．．．からディスク
によって必要である実際の電気信号までのプロトコル間をトランスレートする。
好ましい実施例では、８つのディスクに対して一つのディスク・コントローラが
設けられている。同様に、通信コントローラ３６は、Ｉ／Ｏバス３０、３２、．
．．から外部通信回線までのプロトコル間をトランスレートしかつ通信プロトコ
ルのあるものを実行する。異なる型の通信コントローラは、異なる通信回線を扱
うために用いられる。
このプロセッサ・システム構成１０は、プロセス・ペア・スキームを用いる。
プロセス・ペアに二つのＣＰＵｓがあり、一つは、一次ＣＰＵ、他のものは、他
の一次ＣＰＵが動作不能であるときにだけ利用されるスタンバイ（待機）ＣＰＵ
である。スタンバイＣＰＵは、エラーが発生しかつ一次ＣＰＵがトランザクショ
ンを実行できないならば、スタンバイＣＰＵが要求された情報の一部へのアクセ
スを有しかつ、それゆえに、トランザクションを独立して終了することができる
ように継続的に更新される。
このプロセッサ・システム１０は、全てのトランザクションに適用する多くの
他の特徴を有する。例えば、システムで生じる各要求に対して、応答は、トラン
ザクション・マネージャに送られなければならない。更に、失敗または故障が生
じたならば、システム１０は、あたかもトランザクションが開始されなかったか
のようにその前の状態へ戻る。それゆえに、トランザクションの一部または要求
は、必要ならば“undone”されうる（取り消されうる）。
トランザクションがシステム１０によって扱われる場合、そのようなトランザ
クションは、２〜１６のＣＰＵ’ｓ１２、１４、．．．の複数を通過しうる。ト
ランザクションに関連付けられたオペレーションが適宜に生じるならば、トラン
ザクションは、完遂されかつ完全（完了）である。失敗、故障、等が生じれば、
システム１０は、あたかもトランザクションが作用されなかったかのようにその
前の状態に戻る。それがシステムに入力する前後のトランザクションに関する情
報は、監査トレイル（監査証跡）（ログとしばしば呼ばれる）に記録される。
図２は、複数のＣＰＵ’ｓが同じトランザクションで動作しうる方法を示す。
例えば、トランザクションは、ＣＰＵ４０に入力しうるし、かつＣＰＵｓ４２及
び４４は、参照番号４６によって指定された、変更１〜５を実行しうる。トラン
ザクションに関する全ての動作が実行された後、変更４６は、監査トレイルへ送
られ、かつ問題が生じなかったならば、それらの変更は、完遂されかつトランザ
クションは、完全（完了）であると考えられる。このシナリオでは、故障または
他の問題が生じないので、前の状態への戻りがない。問題／エラーが生じるなら
ば、番号４８で示された、トランザクションをその前の状態へ戻すために取り消
し(undos)１〜５が自動的に実行される。取り消し(undos)は、記録された変更と
同じ方法で監査トレイルに記録される。
表１は、エポック番号(epoch numbers)が監査トレイルに記憶された変更及び
取り消し(undos)に関連付けられうる方法の簡単な表現を提供する。エポック第
０番は、監査トレイルに記憶された、変更１〜５を参照する。エポック第１番は
、これらもまた監査トレイルに記憶された、取り消し番号１〜５を参照する。図
２の変更４６と同様に、取り消し４８もまたその前の状態に戻るためにシステム
１０に対する問題なしで完遂されることが必要である。取り消しが問題またはエ
ラーに遭遇するならば、取り消し(undos)の取り消し(undo)が生じる。
表２は、エポック番号が変更、取り消し、及び監査トレイルに記録される取り
消し(undos)の取り消し(undos)に関連付けられうる方法のさらに複雑な表現を提
供する。例えば、表２は、更新／変更３及び４が失われたので３及び４なしで監
査トレイルに記録された変更１、２及び５を参照するエポック第０番を示す。そ
れゆえに、変更３及び４は、ミッシングしており、かつ、従って、エポック第０
番は、完遂することができない。エポック第１番は、取り消し(undo)１の更新が
失われたので取り消し(undos)２及び５だけを有する。問題またはエラーが生ず
るので、エポック第２番は、（１）２及び５は、エポック第１番で生じた取り消
し(undo)の取り消し(undo)でありかつ（２）１、２及び５は、エポック第０番で
生じた変更の取り消し(undos)であるということ示す。それゆえに、エポック第
２番ではなにも失われていない。エポック第２番が完遂されるとき、システム１
０は、その前の状態に戻る。関連監査トレイル・セグメントは、３つのエポック
の結果を含む：変更１、２及び５；取り消し(undos)２及び５；取り消し(undos)
２及び５の取り消し(undos)；及び取り消し(undos)１、２及び５。
表２に示した手順は、トランザクションが完全に取り消されるまで継続する。
これは、トランザクションが完全に生じるか、またはシステムがその前の状態に
戻ることを確実にする。更に、取り消し(undo)がトランザクションに対する正規
の変更(regular change)と同じように処理されるので、変更、取り消し(undos)
、取り消しの取り消し(undos of undos)、等の多重サイクルは、トランザクショ
ンが完了（終了）するまでまたはシステムがその前の状態に戻るまで簡単なファ
ッションで生じることができる。通常の走行システムではエポック番号は、めっ
たに２に到達せずかつほとんどまったく３に到達しない。
図３は、システム１０のＣＰＵ’ｓ７０、７２、７４及び７６の全てに配置さ
れる対応スタック６０、６２、６４及び６６を示す。スタック６０、６２、６４
及び６６のそれぞれは、多重セクション８０、８２、８４及び８６を含み、かつ
セクション８０、８２、８４及び８６のそれぞれは、多重スロットを含む。例え
ば、０−９とラベル付けされた１０のスロット（またはインデックス）は、図３
に示されている。各スロットは、トランザクションの記述（説明）、シーケンス
番号、及びエポック番号を供給するトランザクション制御ブロック（ＴＣＢ）に
対する記憶プリンタを含む。シーケンス番号は、他のトランザクションが終了（
完了）されたときに順番に各入力トランザクションに割り当てられる。上に提示
したように、エポック第０番は、オリジナル・ワークを参照し、エポック第１番
は、第１の取り消し試み（トランザクションが中止されると生じる）を参照し、
エポック第２番は、第２の取り消し試みを参照する、等。
ＣＰＵ７０、７２、７４または７６がトランザクションに対するシーケンス番
号を受け取るとき、そのシーケンス番号は、スロットの数によって分割されかつ
残りは、そのトランザクションに対するスロット番号を決定するために用いられ
る。計算された残りによって参照されたスロットは、シーケンス番号を示してい
るポインタ、エポック番号、及びそのスロットにおいて最近であったトランザク
ションに対して、もしあれば、最近起こったものを含む。ポインタが現在のシー
ケンス番号よりも低いシーケンス番号をポイントするならば、現在のシーケンス
番号は、スロットに挿入される。ポインタがより高いシーケンス番号をポイント
するならば、現在のトランザクションは、低いシーケンス番号を含んでいるスロ
ットによって示されるようにそれが“あまりにも遅い”ので、古くなりかつ廃棄
される。上記したように、トランザクションが他のＣＰＵにおける故障による中
止の処理中であるならば、またはトランザクションがあまりにも古いのでそれが
長期間システムから離れていたならば、これは、一般的に生じる。更に、好まし
い実施例では、受け取ったシーケンス番号は、４０９６によって分割され、そし
て残りは、ポインタのために取られる。
図４は、要求がＣＰＵによって受け取られるときに生ずる処理に対するシーケ
ンス・フロー・チャートを提供する。要求がブロック９０を入力するとき、関連
スロットが決定される（例えば、要求は、スロットの数によって分割されかつ残
りが取られる）。意思ブロック９２は、要求が“too late（あまりにも遅い）”
かどうかを次いで決定する。スロットにおけるトランザクションのシーケンス番
号が要求のシーケンス番号よりも大きいならば、要求は、“too late（あまりに
も遅い）”、またはスロットにおけるトランザクションのシーケンス番号が要求
のシーケンス番号に等しくかつスロットのエポック番号が要求のエポック番号よ
りも大きいならば、要求は、“too late（あまりにも遅い）”。それが既に完了
されたかまたは中止されたならば、またはそれが中止される処理中であるならば
、要求は、“too late（あまりにも遅い）。それゆえに、この意思決定処理は、
ステール要求が作用されないということを確実にする。要求が“too late（あま
りにも遅く）”ないならば、ブロック９４に示したアクティビティが生じ、スロ
ットのシーケンス番号は、要求のシーケンス番号によって置換されかつスロット
のエポック番号は、要求のエポック番号によって置換される。
ブロック９４のアクティビティが完了した後、ブロック９６は、トランザクシ
ョンについての情報を更新させる。スロットＴＣＢポインタがヌル(null)（また
は何も含んでいない）ならば、ＴＣＢは、トランザクションの記述が供給される
ように生成されかつＴＣＢポインタは、有効になる。それがトランザクションの
有効の記述を含むのでスロットＴＣＢポインタがフル（いっぱい）であれば、ト
ランザクションの記述は、既に生成され（このトランザクションは、以前にこの
特定ＣＰＵによって見られている）かついかなる追加情報もトランザクションの
記述のために必要ではない。この初期処理後、要求を作用させることができる。
纏めると、図４は、３つの結果（成果）を有する。まず、それが要求を行うのに
“too late（あまりにも遅く）”かつ要求は、作用されない。第２に、それが要
求を行うのに“too late（あまりにも遅く）”ないがトランザクションの記述は
、要求を作用させることができる前に生成されなければならない。第３に、それ
が要求を行うのに“too late（あまりにも遅く）”なくかつトランザクションに
ついての情報は、既に存在しそこで要求を作用させることができる。
図５は、Ｐｈａｓｅ １ ｔｉｍｅ（フェーズ１タイム）で生じる処理に対す
るシーケンス・フロー・チャートを提供する。フェーズ１は、“flush（フラッ
シュ）”と考えることができる。フェーズ１処理は、情報の全てが監査トレイル
に送られるときに（全ての要求が終了した後）完遂期間中に生じる。フェーズ１
は、また、エポックの終りも示す；それゆえに、エポック番号は、一つ増分され
る。フェーズ１が生ずるとき、情報は、システム１０の全てのＣＰＵ’ｓ７０、
７２、７４及び７６に送られる。各ＣＰＵ７０、７２、７４及び７６では、正し
いスロットがブロック１００に示されるように見出されかつそのフェーズ１でキ
ャリーされたシーケンス番号は、スロットのシーケンス番号がフェーズ１のシー
ケンス番号で置換されるようにスロットに配置される。更に、スロットのエポッ
ク番号は、フェーズ１のエポック番号プラス１で置換される。従って、エポック
番号は、フェーズ１が全てのＣＰＵに送られた後に１だけ増分される。この処理
は、ブロック１０２に示されている。
フェーズ１がエポックの終りを示すと同時に、フェーズ２は、トランザクショ
ンの終り（または完了）を示す。図６は、フェーズ２タイム（Phase２time）で
生ずる処理に対するシーケンス・フロー・チャートを提供する。フェーズ１処理
中に、各ＣＰＵは、それが有効ＴＣＢを含むかどうかの表示を戻す。フェーズ２
タイムでは、（フェーズ１の間に決定されたように）有効ＴＣＢを有するＣＰＵ
’ｓだけが作用される。例えば、システム１０が４つのＣＰＵ’ｓを含みかつ４
つのＣＰＵ’ｓのＣＰＵ１だけが有効ＴＣＢを有するならば、ＣＰＵ１だけが図
６に示した処理によって影響を及ぼされるであろう。トランザクションの記述が
既にそのＴＣＢに対して生成されているので、ＴＣＢポインタがヌル(null)に等
しくないならば、ＴＣＢは、有効である。フェーズ２タイムでは、有効ＴＣＢを
有する各ＣＰＵにおいて、ブロック１１０で示したように、スロットが見出され
る。ソフトウェアは、次いで、ブロック１１２によって示したように、ＴＣＢポ
インタがヌルに等しいかどうかを決定する。ＴＣＢポインタがヌルに等しくない
ならば、ＴＣＢポインタは、ブロック１１４に示したように、ヌルに設定される
。ＴＣＢポインタがヌルに既に等しいならば、フェーズ２処理は、そのＣＰＵに
対して完了である。
図４から図６に示した処理を更に説明するために、表３は、トランザクション
中に生じうる事象の可能なシーケンスを示す。各トランザクションに対して個別
ＴＣＢが存在し、かつＴＣＢポインタは、各トランザクションに対する記述をポ
イントするということを思い出すでしょう。表３は、ＣＰＵ３におけるスロット
３の例を提供し、かつ、（１）ＴＣＢポインタ、（２）シーケンス番号及び（３
）タイム０から５に対するエポック番号において、ＣＰＵ３のスロット３内で生
ずるアクティビティを示す。この例示トランザクションに対してなにかが生じる
まえである、タイム０では、（１）トランザクションの記述がないのでＴＣＢポ
インタは、ヌルである；（２）シーケンス番号は、０である；かつ（３）エポッ
ク
番号は、０である。
タイム１では、“３．３．０”に対する要求は、ＣＰＵ３によって受け取られ
る。この番号、“３．３．０”は、“ＣＰＵ番号．シーケンス番号．エポック番
号．”を表す。要求“３．３．０”の受け取りにより、図４に示した手順が生じ
る。ブロック９０に示されるように、正しいスロットが見出され、かつブロック
９２に示すように、要求のシーケンス番号は、タイム０におけるシーケンス番号
と比較される。この例では、シーケンス(Sequence)第３番は、スロットの番号０
よりも大きい；従って、要求のシーケンス番号及び要求のエポック番号は、ブロ
ック９４及び表３（タイム１で）に示すように、スロットのシーケンス番号及び
スロットのエポック番号を置換する。次に、ブロック９６に示されるように、ス
ロットＴＣＢポインタがチェックされる。スロットＴＣＢポインタがヌルなので
、
ＴＣＢが生成されかつ有効ＴＣＢポインタが表３のタイム１に示されるようにス
ロットに配置される。
表３のタイム２では、フェーズ１は、要求(Request)番号３．３．０に対して
生じる。ここで図５を参照すると、ブロック１００に示すように、システム１０
の全てのＣＰＵにおいて、正しいスロットが見出される。フェーズ１のシーケン
ス番号は、スロットのシーケンス番号を置換するために用いられかつフェーズ１
のエポック番号プラス１は、スロットのエポック番号を置換する。この更新は、
表３のタイム２に示される。
タイム３では、“３．３”に対するフェーズ２が受け取られる。この番号、“
３．３”は、“ＣＰＵ番号．シーケンス番号．”を表す。ここで図６を参照する
と、（タイム２のフェーズ１中に見出された）有効ＴＣＢを有する全てのＣＰＵ
ｓに対するスロットは、ブロック１１０によって示されるように決定される。次
に、ＴＣＢポインタは、ブロック１１２において示されるように、試験され、か
つＴＣＢポインタが既にヌルに設定されていないならば、ブロック１１４におい
て示すように、それは、ヌルに設定される。このアクティビティは、表３のタイ
ム３で示される。
タイム４では、“３．１３．０”に対するフェーズ１が受け取られる。再び、
図５に示すように、スロットのシーケンス番号は、フェーズ１のシーケンス番号
によって置換され、かつスロットのエポック番号は、ブロック１０２に示すよう
に、フェーズ１のエポック番号プラス１によって置換される。これは、表３のタ
イム４で示される。
タイム５では、要求は、“３．２３．０”に対して受け取られる。ここで図４
を参照すると、正しいスロットは、ブロック９０に示すように見出される。次に
、要求のシーケンス番号がスロットのシーケンス番号よりも大きいので、ブロッ
ク９２及び９４に示すように、スロットのシーケンス番号は、要求のシーケンス
番号によって置換されかつスロットのエポック番号は、要求のエポック番号によ
って置換される。ブロック９６に示したように、本ＴＣＢポインタがヌルなので
、ＴＣＢが次いで生成される。この処理は、有効ＴＣＢポインタ、２３のシーケ
ンス番号、及び０のエポック番号を有しているタイム５を結果として生ずる。
トランザクションを開始するＣＰＵもまた、フェーズ１及びフェーズ２が生ず
るときに制御することによってそれを終了する。更に、トランザクションを開始
するＣＰＵは、そのトランザクションを開始するために総括システム１０によっ
て明示的に告げられなくともよい。ＣＰＵは、独立して作動しかつその自体でト
ランザクションを開始する。一度トランザクションを開始するＣＰＵがＴＣＢを
有するならば、全ての他のＣＰＵは、そのＴＣＢへのアクセスを有する。開始Ｃ
ＰＵは、まずそのＴＣＢを生成しかつ最後にそのＴＣＢを破壊する。更に、トラ
ンザクションを開始するＣＰＵは、（上述したように）要求の最初の番号によっ
て示される。それゆえに、全要求番号は：“beginning CPU number.TCB number.
sequence number.epoch number．”（開始ＣＰＵ番号．ＴＣＢ番号．シーケンス
番号．エポック番号．）として示される。システム１０の各ＣＰＵは、独立して
走りかつ継続的に更新される。
そして、フェーズ２は、図６に示したように、ＴＣＢだけを削除するので、他
の情報（即ち、シーケンス番号及びエポック番号）は、図４のブロック９２に示
されるように、削除されることが必要でありかつより大きな要求シーケンス番号
または要求エポック番号が関連スロットにおいて受け取られるときに、削除され
る。この削除（または更新）は、図４のブロック９４に示すように、スロットの
シーケンス番号が要求のシーケンス番号によって置換されかつスロットのエポッ
ク番号が、要求のエポック番号によって置換されるときに生ずる。
この通信スキームは、ＣＰＵ’ｓ間に送られたメッセージの数がかなり低減さ
れるので、改良されたスループットと共により低い通信コストを供給する。メッ
セージの数におけるこの低減は、複数の理由により生ずる。第１に、フェーズ２
では、メッセージは、上述したように、有効ＴＣＢを有するＣＰＵ’ｓへのみ送
られる。第２に、ＣＰＵ’ｓは、それらがトランザクションを独立して開始しか
つ要求を独立して作用させるので、どのトランザクションが入力されるかについ
て警告されなくてもよい。開始ＣＰＵだけがそのトランザクションを開始すべく
トランザクションについて知る必要があるのでトランザクションが開始するとき
に全てのＣＰＵがメッセージを受け取るのではない。更に、システム１０では、
トランザクションの開始中及びトランザクションが完了されたときにフェーズ２
中で必要なＣＰＵｓだけが用いられかつ更新される。それゆえに、ＴＣＢは、全
てのＣＰＵ’ｓにおいて生成されるのではなく、ＴＣＢ’ｓは、必要なＣＰＵ’
ｓにおいてのみ生成される。これがシステム１０を線形的に改良させる。
図７は、システム１０におけるＣＰＵｓの数が増大されるときに本発明におけ
るスループットが改良される方法を示すグラフである。ライン１２０は、スルー
プットがＣＰＵ’ｓの数における増大によって妨げられない線形−理想情況を示
す。従来技術のシステムでは、メッセージは、（１）トランザクションの開始、
（２）フェーズ１または完遂シーケンス、及び（３）フェーズ２または完全トラ
ンザクションに対して全てのＣＰＵ’ｓへ送られなければならない。従来技術は
、ライン１２２によって示される。本発明では、メッセージは、フェーズ１の間
にだけ全てのＣＰＵ’ｓへ送られる。ＣＰＵｓの数が増大されるときの本発明の
スループットのこの改良は、ライン１２４によって示される。
擬似−コードの例は、好ましい実施例における上述した機能性をインプリメン
トする方法の例を更に提供するために添付資料に含まれる。
本発明の全てかつ完全な開示が上記に供給されたが、種々の変更及び変形がな
されうるということは、当業者に自明であろう。
DETAILED DESCRIPTION OF THE INVENTION Transaction State Tracking Copyright Notice A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner shall have no objection to the electrophotographic reproduction by anyone of the complete patent document or patent disclosure as represented in the Patent and Trademark Office patent files or records, but nothing else. Also reserves the right to copyright. Field of the invention The present invention relates to data processing systems, and more particularly to tracking and controlling data for online transaction processing to provide transaction management and protect the integrity of user data. It relates to a parallel processing system. Background of the Invention Online transaction processing ("OLTP") includes, for example, supporting financial transactions (eg, coordinating information from bank ATMs), tracking data against the New York Stock Exchange, billing telephone companies. And has found various commercial applications in today's industry, such as tracking parts for products (eg, automotive parts). Many of the commercial applications available for OLTP require elaborate protection of user data integrity along with continuous availability to the OLTP application to end users. For example, bank ATMs must have good integrity (ie, minimize errors, if any) and ATMs must be available to users for an extended period of time. No. ATM users do not tolerate the failures associated with those transactions (eg, $ 500.00 deposits not credited to the user's account). In addition, ATMs are preferably available to users, often 24 hours a day, 7 days a week. In order to achieve continuous availability in OLTP applications, users must be able to rely on supporting (support) system software. Parallel processing (processing utilizing a process pair) assists in making OLTP quickly process many individual transactions or small tasks distributed among multiple processors. Other parallel processing applications include maintaining and accessing large databases for record keeping and decision making operations or as a media server that provides accessible storage of information to many users. A particular advantage of parallel processing is its ability to handle large amounts of disparate data, such as in decision-making operations that may require the retrieval of disparate information that can be distributed among many storage devices (functions). ). In addition, the parallel processor media server application provides a parallel processor to provide a large number of customers with access to a large reservoir of a movie maintained in searchable memory (eg, disk storage). To an interactive service environment such as "movies-on-demand". This latter application may require significant parallel processors to service multiple requests simultaneously by locating, selecting, and retrieving the requested movie, and sending a selection to the requesting customer. Object and Summary of the Invention While parallel processing increases OLTP capabilities, there is a need for techniques for tracking and controlling data related to OLTP such that transaction management is provided and (2) data integrity is protected. In the preferred embodiment, a transaction monitoring facility (Transaction Monitoring Facility TMF) provides transaction management and protects the integrity of user data. A programmatic structure, called a "transactio", is a set of explicitly delimited or related actions that change the contents of a database from one consistent state to another. . Database operations within a transaction are treated as a single unit. Either all of the changes performed by the transaction are completed and made permanent, or no changes are made permanent (the transaction is aborted). If a failure occurs during the execution of a transaction, any partial changes made to the database are automatically undone, thus leaving the database in a consistent state. In one preferred embodiment, the present invention provides a method for processing undo work for a transaction as it processes the original work. In particular, the same method ensures that log records (or Audit Trail records) have been established on disk and that missing log records, if present, are reliably detected. Used for The method may also determine when a newly arriving request for an update arrives too late so that the aborted transaction is not operated on by it. In another preferred embodiment of the present invention, a transaction control block "fault-in" is used. This feature deals with the ability to generate a Transaction Control Block (TCB) data structure in the CPU if such a structure does not already exist. The TCB is a public container with a private field, and it provides a description for its associated transaction. The comments for each field specify which module has access to which field. By utilizing the TCB data structure, the system improves linearity without assigning a TCB to each CPU at the start of a transaction. Instead, each CPU has a table containing the highest sequence number and the highest epoch field associated with that sequence number. If the TCB needs to be generated by the CPU, the sequence numbers and epoch numbers in the table must have appropriate values to allow for a "faulting in" of the TCB. A "faulting in" occurs when a request arrives at the CPU but the TCB does not exist, thus generating a TCB. If the value for a certain sequence number is not appropriate, the fault-in is rejected because it is "too late". This generally occurs if the transaction is in the process of aborting due to a failure in some other CPU, or if the transaction is too old and has been away from the system for an extended period of time. Faulting in an old transaction may be required if the server has the transaction as its current transaction and attempts to use it after the transaction has been completely aborted. By including the design features shown above, TMF improves its availability, is easier to manage, and has improved performance. These and other advantages will become apparent to those skilled in the art from a reading of the following detailed description of the invention, which should be taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE FIGURES FIG. 1 is a simplified diagram of a processor system having 2 to 16 processors; FIG. 2 shows how multiple CPU's can operate on the same transaction; FIG. FIG. 4 provides a sequence flow chart for the processing that occurs when a request is received by a CPU; FIG. 5 takes place in Phase 1 time. FIG. 6 provides a sequence flow chart for processing performed in Phase 2 time; and FIG. 7 provides an increase in the number of CPUs in the system. 5 is a graph illustrating a method of sometimes improving the throughput of the present invention. Example Referring now to the drawings, and primarily to FIG. 1 for the moment, shown in simplified form is a processor system generally designated by the reference numeral 10 and having two to sixteen processors. As shown, processor system 10 includes a plurality of processors 12, 14,. . . (CPUs). Each of the CPUs 12, 14,. . . Has its own RAM 22, 24,. . . including. 2-16 CPUs are connected by two high-speed buses 26 and 28, and each CPU 12, 14,. . . Have their own input / output lines 30, 32,. . . (I / O). The I / O lines 30, 32,. . . Are CPUs 12, 14,. . . Is connected to the disk controller 34 and the communication controller 36. Disk controller 34 includes I / O buses 30, 32,. . . To translate between protocols from the actual electrical signal required by the disk. In the preferred embodiment, one disk controller is provided for eight disks. Similarly, the communication controller 36 controls the I / O buses 30, 32,. . . And translates between protocols from the external communication line and executes a certain communication protocol. Different types of communication controllers are used to handle different communication lines. The processor system configuration 10 uses a process pair scheme. There are two CPUs in the process pair, one is the primary CPU and the other is a standby CPU that is used only when the other primary CPU is inoperable. The standby CPU has access to some of the requested information if an error occurs and the primary CPU cannot execute the transaction, and therefore can independently end the transaction. Will be updated continuously. This processor system 10 has many other features that apply to all transactions. For example, for each request that occurs in the system, a response must be sent to the transaction manager. Further, if a failure or failure occurs, system 10 returns to its previous state as if the transaction had not been started. Therefore, parts or requests of a transaction can be "undone" (cancelled) if necessary. If a transaction is handled by the system 10, then such a transaction may involve 2-16 CPU's 12, 14,. . . Can be passed through. A transaction is completed and complete (completed) if the operation associated with the transaction occurs as appropriate. If a failure, failure, etc. occurs, the system 10 returns to its previous state as if the transaction had not been acted upon. Information about the transaction before and after it enters the system is recorded in an audit trail (often called a log). FIG. 2 illustrates how multiple CPU's can operate on the same transaction. For example, a transaction may be input to CPU 40 and CPUs 42 and 44 may perform changes 1-5, designated by reference numeral 46. After all operations on the transaction have been performed, changes 46 are sent to the audit trail, and if no problems occur, those changes are completed and the transaction is considered complete. . In this scenario, there is no failure or other problem, so there is no return to the previous state. If a problem / error occurs, undos 1-5, shown at 48, are automatically executed to return the transaction to its previous state. Undos are recorded in the audit trail in the same way as recorded changes. Table 1 provides a simple expression of how epoch numbers can be associated with changes and undos stored in the audit trail. Epoch 0 refers to changes 1-5 stored in the audit trail. Epoch 1 refers to revocation numbers 1-5, which are also stored in the audit trail. As with the change 46 in FIG. 2, the cancel 48 also needs to be completed without problems to the system 10 to return to its previous state. If undo encounters a problem or error, undo of undos occurs. Table 2 provides a more complex expression of how epoch numbers can be associated with changes, undos, and undos recorded in the audit trail. For example, Table 2 shows epoch number 0 which refers to changes 1, 2 and 5 recorded in the audit trail without updates 3 and 4 since updates 3 and 4 were lost. Therefore, changes 3 and 4 are missing, and therefore epoch number 0 cannot be completed. Epoch # 1 has only undos 2 and 5 because the update of undo 1 was lost. Since a problem or error occurs, epoch number 2 is (1) 2 and 5 is the undo of the undo that occurred in epoch number 1 and (2) 1, 2 and 5 are Indicates that this is an undo of the changes that occurred at epoch number 0. Therefore, nothing was lost in Epoch No. 2. When epoch number 2 is completed, system 10 returns to its previous state. The relevant audit trail segment contains the results of three epochs: changes 1, 2 and 5; undos 2 and 5; undos 2 and 5 undos; and undos 1; 2 and 5. The procedure shown in Table 2 continues until the transaction is completely canceled. This ensures that the transaction occurs completely or the system returns to its previous state. In addition, since undo is treated like a regular change to a transaction, multiple cycles of changes, undos, undos of undos, etc. It can occur in a simple fashion until (ending) or until the system returns to its previous state. In a normal driving system, the epoch number rarely reaches 2 and almost never reaches 3. FIG. 3 shows corresponding stacks 60, 62, 64 and 66 located on all of the CPUs 70, 72, 74 and 76 of the system 10. Each of the stacks 60, 62, 64 and 66 includes multiple sections 80, 82, 84 and 86, and each of the sections 80, 82, 84 and 86 includes multiple slots. For example, ten slots (or indices) labeled 0-9 are shown in FIG. Each slot includes a storage printer for a transaction control block (TCB) that provides a description of the transaction, a sequence number, and an epoch number. A sequence number is assigned to each input transaction in turn as other transactions are completed (completed). As presented above, epoch number 0 refers to the original work, epoch number 1 refers to the first cancellation attempt (which occurs when the transaction is aborted), and epoch number 2 refers to See second cancellation attempt, etc. When the CPU 70, 72, 74 or 76 receives a sequence number for a transaction, that sequence number is divided by the number of slots and the rest is used to determine the slot number for that transaction. The slot referenced by the computed remainder includes the pointer to the sequence number, the epoch number, and the most recent transaction, if any, for the transaction that was recent in that slot. If the pointer points to a sequence number lower than the current sequence number, the current sequence number is inserted into the slot. If the pointer points to a higher sequence number, the current transaction is stale and discarded because it is "too slow" as indicated by the slot containing the lower sequence number. As noted above, this generally occurs if the transaction is in the process of being aborted due to a failure in another CPU, or if the transaction has been out of the system for too long because it is too old. Further, in the preferred embodiment, the received sequence number is divided by 4096 and the remainder is taken for pointers. FIG. 4 provides a sequence flow chart for the processing that occurs when a request is received by a CPU. When a request enters block 90, the relevant slot is determined (eg, the request is divided by the number of slots and the rest is taken). Decision block 92 then determines whether the request is "too late". If the sequence number of the transaction in the slot is greater than the sequence number of the request, the request is "too late", or the sequence number of the transaction in the slot is equal to the sequence number of the request and the epoch number of the slot is If it is greater than the epoch number of the request, the request is "too late". If it has already been completed or aborted, or if it is in the process of being aborted, the request is “too late. If the request is not "too late", the activity shown in block 94 occurs, the slot sequence number is replaced by the request sequence number and the slot epoch. The number is replaced by the epoch number of the request After the activity of block 94 is completed, block 96 causes the information about the transaction to be updated, if the slot TCB pointer is null (or contains nothing). If the TCB is generated such that a description of the transaction is provided and the TCB If the slot TCB pointer is full because it contains a valid description of the transaction, the transaction description has already been created (this transaction was previously seen by this particular CPU). And no additional information is needed for the description of the transaction.After this initial processing, the request can be effected.In summary, Figure 4 has three results. The request is “too late” to make the request and the request is not effected.Second, it is not “too late” to make the request, but the transaction description is Must be generated before it can work. Third, it must be "too late" to make the request and Figure 5 provides a sequence flow chart for the processing that occurs in Phase 1 time, where information about the transaction already exists and the request can be acted on. (Flash). Phase 1 processing occurs during the completion period when all of the information is sent to the audit trail (after all requests have been completed). Phase 1 also ends the epoch Therefore, the epoch number is incremented by 1. When Phase 1 occurs, the information is sent to all CPU's 70, 72, 74 and 76 of system 10. Each CPU 70, 72, 74 and At 76, the correct slot is found as shown in block 100 and the sequence carried in phase 1 thereof. The sequence numbers are arranged in the slots such that the sequence numbers of the slots are replaced by the sequence numbers of phase 1. Further, the epoch number of the slot is replaced by the epoch number of phase 1 plus one. Thus, the epoch number is incremented by one after phase one has been sent to all CPUs. This process is indicated by block 102. Phase 2 indicates the end (or completion) of the transaction, while phase 1 indicates the end of the epoch. FIG. 6 provides a sequence flow chart for the processing that occurs at Phase 2 time. During the phase 1 process, each CPU returns an indication whether it contains a valid TCB. In the phase 2 time, only CPU's with a valid TCB are activated (as determined during phase 1). For example, if system 10 includes four CPU's, and only CPU 1 of the four CPU's has a valid TCB, only CPU 1 will be affected by the process shown in FIG. The TCB is valid if the TCB pointer is not equal to null, since the description of the transaction has already been generated for that TCB. During the phase 2 time, a slot is found at each CPU with a valid TCB, as indicated by block 110. The software then determines whether the TCB pointer is equal to null, as indicated by block 112. If the TCB pointer is not equal to null, the TCB pointer is set to null, as shown in block 114. If the TCB pointer is already equal to null, phase 2 processing is complete for that CPU. To further illustrate the process shown in FIGS. 4-6, Table 3 shows a possible sequence of events that can occur during a transaction. You will recall that for each transaction there is a separate TCB and the TCB pointer points to the description for each transaction. Table 3 provides an example of slot 3 in CPU 3 and shows the activities occurring in slot 3 of CPU 3 at (1) TCB pointer, (2) sequence number and (3) epoch number for times 0-5. . At time 0, before anything happens to this example transaction, (1) the TCB pointer is null because there is no transaction description; (2) the sequence number is 0; and (3) the epoch. The number is 0. At time 1, a request for "3.3.0" is received by CPU3. This number, "3.3.0", represents "CPU number. Sequence number. Epoch number." Receiving the request "3.3.0" causes the procedure shown in FIG. The correct slot is found, as shown at block 90, and the sequence number of the request is compared to the sequence number at time 0, as shown at block 92. In this example, the sequence number 3 is greater than the slot number 0; therefore, the sequence number of the request and the epoch number of the request are in the slot 94, as shown in Table 3 (at time 1). And the epoch number of the slot. Next, as shown in block 96, the slot TCB pointer is checked. Since the slot TCB pointer is null, a TCB is generated and a valid TCB pointer is placed in the slot as shown at time 1 in Table 3. At time 2 in Table 3, phase 1 occurs for Request number 3.3.0. Referring now to FIG. 5, as shown in block 100, the correct slot is found in all CPUs of system 10. The phase 1 sequence number is used to replace the slot sequence number and the phase 1 epoch number plus 1 replaces the slot epoch number. This update is shown at time 2 in Table 3. At time 3, phase 2 for "3.3" is received. This number, “3.3”, represents “CPU number.sequence number.” Referring now to FIG. 6, the slots for all CPUs with valid TCBs (found during Phase 1 of Time 2) are determined as indicated by block 110. Next, the TCB pointer is tested, as shown at block 112, and if the TCB pointer has not already been set to null, it is set to null, as shown at block 114. This activity is shown at time 3 in Table 3. At time 4, phase 1 for "3.13.0" is received. Again, as shown in FIG. 5, the slot sequence number is replaced by the phase 1 sequence number, and the slot epoch number is replaced by the phase 1 epoch number plus 1, as shown in block 102. This is shown at time 4 in Table 3. At time 5, a request is received for "3.23.0". Referring now to FIG. 4, the correct slot is found as shown in block 90. Next, since the sequence number of the request is greater than the sequence number of the slot, the sequence number of the slot is replaced by the sequence number of the request and the epoch number of the slot is the epoch number of the request, as shown in blocks 92 and 94. Is replaced by As shown in block 96, the TCB is then generated because the TCB pointer is null. This process results in time 5 having a valid TCB pointer, a sequence number of 23, and an epoch number of 0. The CPU initiating the transaction also ends it by controlling when phase 1 and phase 2 occur. Further, the CPU initiating the transaction need not be explicitly told by the overall system 10 to initiate the transaction. The CPU operates independently and initiates a transaction on its own. Once the CPU that initiates a transaction has a TCB, all other CPUs have access to that TCB. The starting CPU first generates its TCB and finally destroys it. Further, the CPU initiating the transaction is indicated by the first number in the request (as described above). Therefore, the total request number is indicated as: "beginning CPU number.TCB number.sequence number.epoch number." Each CPU of the system 10 runs independently and is continuously updated. Since the phase 2 deletes only the TCB as shown in FIG. 6, other information (ie, the sequence number and the epoch number) is deleted as shown in block 92 of FIG. Is required and is deleted when a larger request sequence number or request epoch number is received in the associated slot. This deletion (or update) occurs when the slot sequence number is replaced by the request sequence number and the slot epoch number is replaced by the request epoch number, as shown in block 94 of FIG. This communication scheme provides lower communication costs with improved throughput since the number of messages sent between CPU's is significantly reduced. This reduction in the number of messages occurs for several reasons. First, in phase 2, the message is sent only to CPU's with a valid TCB, as described above. Second, CPU's need not be warned about which transactions will be entered because they start transactions independently and act on requests independently. Not all CPUs receive the message when a transaction starts because only the initiating CPU needs to know about the transaction to start the transaction. Further, in system 10, only the necessary CPUs are used and updated during phase 2 during the start of the transaction and when the transaction is completed. Therefore, TCB's are generated only at the required CPU's, rather than at all CPU's. This allows the system 10 to improve linearly. FIG. 7 is a graph illustrating how throughput is improved in the present invention as the number of CPUs in system 10 is increased. Line 120 illustrates a linear-ideal situation where throughput is not hindered by an increase in the number of CPU's. In prior art systems, messages must be sent to all CPU's for (1) the start of a transaction, (2) a phase 1 or completion sequence, and (3) a phase 2 or complete transaction. The prior art is indicated by line 122. In the present invention, the message is sent to all CPU's only during phase one. This improvement in the throughput of the present invention as the number of CPUs is increased is indicated by line 124. Pseudo-code examples are included in the appendix to further provide examples of how to implement the above-described functionality in the preferred embodiment. While all and complete disclosures of the present invention have been provided above, it will be apparent to those skilled in the art that various modifications and variations can be made.
─────────────────────────────────────────────────────
フロントページの続き
(72)発明者 ショロフ スリカント
アメリカ合衆国 ワシントン州 98027
イサカー サウスイースト フォーティセ
カンド ストリート 25049
(72)発明者 ライオン ジェイムズ エム
アメリカ合衆国 カリフォルニア州
95125 サン ホセ マーリン ウェイ
1766
(72)発明者 カーリイ ウィリアム ジェイ
アメリカ合衆国 カリフォルニア州
95117 サン ホセ メイプルウッド ア
ベニュー 457
(72)発明者 ジョンソン チャールズ エス
アメリカ合衆国 カリフォルニア州
95117 サン ホセ ウィリアムズ ロー
ド 3954
(72)発明者 フィンケルスティン シェルドン ジェイ
アメリカ合衆国 カリフォルニア州
94022 ロス アルトス ヒルズ ヴォー
グ コート 27664────────────────────────────────────────────────── ───
Continuation of front page
(72) Inventor Shorov Slicant
United States of America Washington 98027
Ithaca Southeast Fortis
Khand Street 25049
(72) Inventor Lion James M
United States California
95125 San Jose Marlin Way
1766
(72) Inventor Carly William Jay
United States California
95117 San Jose Maplewood A
Venue 457
(72) Inventor Johnson Charles S
United States California
95117 San Jose Williams Row
De 3954
(72) Inventor Finkelstin Sheldon Jay
United States California
94022 Los Altos Hills Vaud
Gukot 27664