JPH0296849A - Ｔｐキューイングシステムにおける正確に１回のセマンティクス - Google Patents

Abstract

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

Description

【発明の詳細な説明】 （産業上の利用分野） 本発明は一般に高信鯨の分散演算に関し、さらに詳しく
はトランザクション処理（ＴＰ）に関する。特に本発明
は、トランザクションの処理中に部分的なシステム故障
が起きた場合でも、所望のトランザクションが全体とし
て正確に１回生じるかあるいは全く生じないことを保証
する方法に関する。

（従来の技術） 計算システムの望ましい特徴は、部分的なシステム故障
からできる能力にある。部分的なシステム故障は、例え
ば、オペレーティングシステムにおけるまれなソフトウ
ェアのエラーによってシステムが“クラッシュ”しする
と発生し、オペレーティングシステムはその後再スター
ト可能である。

アプリケーションプログラムがシステム故障時にメモリ
書込動作を進行中であると、メモリレコードが誤ったも
のになる恐れが強い。部分的なシステム故障後にメモリ
レコードの回復を可能とするには、アプリケーションプ
ログラムがレコードのバックアップコピーを非揮発性メ
モリ内に保持する必要がある。オペレーティングシステ
ムが再スタートされるとき、回復すべきメモリレコード
はバックアップコピーと交換される。そしてアプリケー
ションプログラムが再スタートされ、バックアップコピ
ーが取られた後に行われた生じた動作を繰り返さねばな
らない。

バックアップコピーの作成とメモリレコードの回復を容
易とするため、オペレーティングシステムは一般に、ア
プリケーションプログラムから呼出つまりコール可能な
確立された一組のメモリ管理手段を用意している。代表
的な例は、ＶＡＸ／ＶＭＳオペレーティングシステムと
組み合わせて使われる。米国マサチューセッツ州０１７
５４、メイナード所在のデジタル・エクイソブメント社
から市販されているレコード管理サービス（ＲＭＳ）ソ
フトウェアの“回復ユニットジャーナル（動作記憶）”
機能である。メモリレコードの回復のために、アプリケ
ーションプログラムの最初の部分は、プログラムステー
トメント“＄ＳＥＴ　ＦＩＬＥ　［ＦＩＬＥＮＡＭＥ］
　／　ＲｌｊＪＯ［ＩＲＮＡＬ”　ニよ、）７コールさ
れるＲＭＳ手順を呼び出すことによって非揮発性メモリ
をバックアップコピーに割り振る。但し、ＦＩＬＥＮＡ
ＭＥは回復すべきメモリレコードを含むファイルの名前
である。実際にバックアップコピーを取り、“回復ユニ
ット”を開始させるには、アプリケーションではダラム
がステートメント“＄５ＴＡＲＴ　ＲＵ”によってコー
ルされるＲＭＳ手順を呼び出す。

“回復ユニット′の実行中に部分的システム故障が発生
したら、メモリレコードはバンクアップコピーから回復
される。

“回復ユニット”は、”　＄５ＴＡＲＴ　Ｒ１１’　ス
テー　）　メント“＄ＣＯ？ｌ旧Ｔ　ＲＵ”ステートメ
ント間の一組のプログラムステートメントからなる。“
回復ユニット“内のステートメントは全て、回復ユニッ
トのステートメントによって変更されたメモリレコード
が続く処理で利用可能となる前に完了されねばならない
。言い換えれば、“回復ユニット”内のステートメント
は１つの１トランザクシヨン”における動作を指定する
。“トランザクション”における動作は全て同時に完了
されるか、あるいはそのいずれもが完了されない。

トランザクションにおける動作は、分散計算システム内
の複数のプロセッサまたはノードによってアクセス可能
な、異なるデータベース中の複数のファイルを変更する
ことがある。この場合、１つのプロセッサまたはノード
が各−組のファイルを変更するトランザクションを行っ
ていると、他のいずれのプロセッサもその一組のファイ
ルを変更し得ない。このため、アプリケーションプログ
ラムは、ファイル内に記憶されたデータの内部一貫性を
保証できる。例えば第１勘定の借方記入と第２勘定の貸
方記入を含む資金の移し換えなど、−群の関連した動作
を回復ユニットとして定義することによって、プログラ
マ−は、更新レコードがその後利用可能となる前に、ト
ランザクションにおける全ての動作が完了することを保
証できる。

部分的なシステム故障またはその他アプリケーションプ
ログラムの異常な終了（システムの゛すセット”など）
が発止すると、回復可能として定義されたファイルは最
新の完了回復ユニ７トにだけ回復つまり更新され、ファ
イル内のデータは一貫される。例えば、資金アプリケー
ションの移し換えでは、システムの故障が第２勘定を貸
方記入しないで、第１勘定を借方記入するような事態を
生じない。

−Ｃ的な“トランザクション処理１システムにおいて、
トランザクションによって操作される“オブジェクト”
の状態はいずれも、永久メモリ内に記憶されるものと見
なされる。例えば、多重プロセッサシステムにおける交
信の一般的な方法は、オブジェクトの状態を保持する共
通の永久メモリへの共用アクセスによっている。いずれ
か１つのプロセッサの１クラツシヱ”後にシステムの状
態を復元させるために、回復ユニットジャーナル用のメ
モリ管理手順は、周知の“状態復元方法”を実施する。

状態復元方法では、　　５ＴＡＲＴ　（スタート）″動
作によって、それぞれのトランザクションで操作される
全てのオブジェクトに関する永久メモリレコードに、“
書込ロック”がかけられる。次いで’　５ＴＡＲＴ”動
作は、オブジェクトの状態を保持すべき永久メモリレコ
ードにオブジェクトの状態を退避させ、回復ユニットの
実行中コピーが変更されないようにレコードがコピーさ
れる。その後、回復ユニットによって定義されたトラン
ザクションが、変更されないように保たれたコピーに対
して行われる。トランザクションが終了すると、ＣＯ？
１ＭＩＴ　（コミット）″が、回復ユニットによって操
作された全てのオブジェクト永久メモリ内の状態を、ト
ランザクション中になされた変更に従って１回の“アト
ミック”動作で更新させる。最後に、更新された永久メ
モリレコードに対する書込ロックが解かれる。

状態復元方法の実施は、唯一困難なステップ、つまり回
復ユニットによって操作された全てのオブジェクトの永
久メモリ状態を更新する“アトミックステップを含んで
いることが明かであろう。

ここで“アトミック”ステップとは、部分的なシステム
故障またはアプリケーションプログラムの異常な終了に
関わりなく、全体として行われるかあるいは全く行われ
ないかというステップとして定義される。このような“
アトミック”は特別に設計されたメモリ装置によって直
接実施可能だが、トランザクション中に操作された各オ
ブジェクト毎に２つの永久メモリレコードを割り振ると
共に、どの永久メモリレコードがオブジェクトの永久状
態を保持しているのかを示すフラグまたはスイッチとし
て追加の永久メモリロケーションを割り振ることによっ
ても、間接的に実施できる：他方の永久メモリレコード
は、オブジェクトの揮発状態が永久メモリへ書き込まれ
る都度使われる。従って、回復ユニットによって操作さ
れた全てのオブジェクトの永久メモリ状態の更新は、ト
ランザクションによって変更されたオブジェクトの永久
メモリレコードに関するフラグまたはスイッチを変える
１つのマシン命令の実行による１１１ｉ２１１のアトミ
ックステップで行うことができる。

上記の実施において、“部分的システム故障″は、１つ
のマシン命令が全体として完了されるかあるいは全く完
了されないことを保証する任意の故障である。“５ＴＡ
ＲＴ”動作が各プロセッサについて定義されたそれぞれ
の永久メモリファイルを他のプロセッサによるアクセス
に対して書込ロックすると共に、永久メモリへの書込毎
に使われるフラグ付き永久メモリへのコピーに対してい
ずれの書込動作も行われるようにすることによって、そ
れぞれのファイルを退避させる。“ＣＯＭＭＩＴ”動作
が各ファイル用フラグを切り換え、最終の書込ロックを
取り除く。

（発明が解決しようとする課題） 前記したように、状態復元方法は、クラッシュが全ての
更新をあるいずれかのノードで行えなくするような場合
でも、あるいずれかのプロセッサによってなされる更新
が一貫することを保証する。

もっと困難な問題は、クラッシュ後に、システムの状態
が自動的に復元可能とし、クラッシュによって中断され
たトランザクションが正確に１回完了されることが保証
された完了まで、処理をＮ１続できるようにすることで
ある。一部のトランザクションでは、少なくとも１回の
セマンティクス（意味：　　ｓｅｍａｎｔｉｃｓ）が許
容可能である。例えば、新聞購入者の郵送住所に更新す
るトランザクションは、１回より多〈実施されても何等
の悪影響も伴わない。しかし他のトランザクションでは
、正確に１回のセマンティクスが重要である。例えば財
務会計システムにおいて、一方の勘定を借方記入し他方
の勘定を貸方記入するトランザクションは、実世界での
各合計トランザクション（取引）毎に、正確に１回行わ
れねばならない。

正確に１回のセマンティクスは、“２相コミフトプロト
コル”及びその派生体等の手順を用いて保証されてきた
。これらの手順は、Ｊ、　Ｅｌｉｏｔと８、　？１ｏｓ
ｓ著、ネスト式トランザクションー信頼できる分散計算
への手法、Ｔｈｅ　ＭＩＴ　Ｐｒｅｓｓ、米国マサチュ
ーセッツ州ケンブリッジ、１９８５に記載されている。

“２相コミツトプロトコル”は、ファイルの更新がシス
テム内の異なる多数のプロセッサによって行われる場合
でも、正確に１回のセマンティクスでの回復を可能とす
る。一般にこのようなシステムでは、任意のあるプロセ
ッサによるトランザクションのために実施またはアクル
ジ（確認応答）されるべき各動作がトランザクション識
別番号の送受によって信号発生でき、またオブジェクト
の状態に対する変更がオブジェクト識別番号と共に交信
できるように、各トランザクションに固有の“トランザ
クシコン識別番号（ＩＤ）”が割り当てられ、また各オ
ブジェクトに固有の“オブジェクト識別番号”が割り当
てられる。

システム内の１つのプロセッサに、トランザクションを
開始するコープイネ−夕の役割が割り当てられる。トラ
ンザクションを開始するには、コーデイネータがそのト
ランザクションに参加している全てのプロセッサに準備
コマンドを送る。

トランザクションに参加している各プロセッサは“準備
”コマンドを受は取ると、前記の５ＴＡＲＴ”動作を行
い、トランザクションＩＤを永久メモリに書き込んで、
トランザクションの用意が整っていることを知られた後
、アクルジをコーデイネータプロセッサに送り戻すが、
そのトランザクション部分はまだ実施していない。コー
デイネータは、全ての参加者からのアクルジを待つ。全
ての参加者からのアクルジを受は取ると、コーデイネー
タは参加者のリストとトランザクションが今完了されつ
つある旨のメモを永久メモリに記録する。

その後コーデイネータは、Ｃ０ＭＭＨ”コマンドを全て
の参加者に送る。”　ＣＯＭ旧Ｔ″コマンドを受は取っ
た各参加者は、その永久メモリでトランザクションｌＤ
をチエツクしてトランザクションのための用意が整って
いるかどうかを判定し、整っていればそのトランザクシ
ョン部分を実施した後、前述の“ＣＯＭ旧Ｔ゛動作を行
い（この処理で、永久メモリが更新されたときトランザ
クションｒＤを永久メモリからクリアする）、最後にア
クルジをコーデイネータに送り戻す：永久メモリでトラ
ンザクションＩＤが見つからなかったら、参加者はアク
ルジだけをコーデイネータに送り戻す。

コーデイネータは全ての参加者からアクルジを受は取る
と、参加者のリスト永久メモリから消去し、トランザク
ションが終了する。

トランザクション中にクラッシュが発生したら、コーデ
イネータはその参加者リストを使い、トランザクション
の完了について、完了していたかまたは終っていなかっ
たかを確かめられる。“ＣＯＭＭＩＴ″コマンドが、リ
ストに含まれている各参加者に再送信される。クラッシ
ュのためトランザクションの一部を完了していなかった
いずれの参加者（トランザクションＩＤの準備レコード
を有する永久メモリによって指示される）も、その一部
を最初からやり直して完了する。上記トランザクション
の一部をすでに完了し終っている参加者（トランザクシ
ョンｒＤの準備レコードを持たない永久メモリによって
指示される）は、いずれもそのトランザクションの一部
を繰り返さない。従って２相コミントプロトコルは、回
復の終了時点で、中断されたトランザクションの全ての
部分が正確に１回実施されることを保証する。

（課題を解決するための手段） トランザクション処理システムにおける正確に１回のセ
マンティクスは、データベーストランザクジョンに対す
る要求を“タスクキュー内にキュー入れし、タスクキュ
ー内に入れられた各要求つまり“タスク”に固をの識別
番号（ＴＡＳＫｊＤ）を割り当てることによって当えら
れる。識別番号は、要求されたデータベーストランザク
ジョンの実行中使われる。特に、識別番号は、要求され
たトランザクションの実行の結果更新がなされると、そ
れと同時に（すなわち同じ“回復ユニット”中に）デー
タベースに書き込まれる。

部分的なシステム故障つまり“クラッシュ”の発生時、
更新が正確に１回行われることを保証するため、データ
ベースが読み取られて、更新がなされた前に存在してい
た全ての識別番号を得る。

データベースのうち識別番号に割り当てられた部分が最
初にフォーマント化つまりクリアされるものとすれば、
データベースから読み取られた番号は、タスクがすでに
完了された場合にのみタスクの識別番号と合致する。そ
のため、要求されたトランザクションの現実行は、２回
目の更新を行うことなく終了される。

正確に１回のセマンティクスを保証するこの方法は、タ
スクキューと組み合わされて、簡潔な回復機構を提供す
る。タスクキューに入れられた各タスクの完了後、タス
クはキューから取り出される。タスクキューの処理中に
部分的なシステム故障が生じた場合、その処理はキュー
の先頭のタスクを処理することによって、通常の方法で
再スタートし得る。タスクの完了直後であるが、タスク
がタスクキューから取り出される前に部分的なシステム
故障が生じた場合には、そのタスクの番号が部分的なシ
ステムの故障直前にデータベースに書き込まれた識別番
号と合致することを見いだされると、同一タスクの再処
理は放棄される。

発明のその他の目的及び利点は、以下の詳細な説明と添
付の図面を参照することによって明らかとなろう。

（実施例） 発明は各種の変形及び代替の態様を取り得るが、その特
定の実施例を例示として図面に示し、以下詳しく説明す
る。しかしもちろん、発明はここに開示する特定の態様
に限られず、逆に発明は特許請求の範囲に限定される発
明の精神及び範囲内に入る全ての変更、同等及び代替物
を包含するものである。

第１図を参照すると、全体が１０で表わされ、本発明の
各種特徴を具備したトランザクション処理システムのブ
ロック図が示しである。前記したようにトランザクショ
ンは、単位として実行されるかあるいは全く実行されな
い一連のオペレーションである。データ処理のオペレー
ションを個々のトランザクションへ細分することで、シ
ステムによって管理されるオペレーション及びデータが
一貫した状態に保たれる。また、データ処理のオペレー
ションが個々の単位に細分されるため、トランザクショ
ンを定義するプログラミングを変えずに、システムの構
成を拡張または変更可能である。

一般にトランザクション処理は、システムが中から多数
のユーザを同時にサポートしなければならなかったり、
データ処理のオペレーションが同−組のデータファイル
またはデータベースを用いるトランザクションに細分さ
れていたり、さらにデータ処理のオペレーションが予め
定義された構造化作業を含む場合に、時分割またはバッ
チ処理などの択一方式よりも好ましい。トランザクショ
ン処理は、例えばインベントリ　（在庫）システム、予
約システム、及びその他のデータベース管理システムに
おいて有用である。

ユーザは一般に、端末に表示された書式に情報を入力す
ることによって、トランザクション処理システムでのト
ランザクションを開始する。この目的のため、第１図の
システム１０は５つの画像表示端末１１〜１５を含んで
いる。システム１０が情報を処理して、アプリケーショ
ンデータベース１６内の１つ以上のファイルと対話する
。

トランザクション処理システムの性能は、データベース
及び演算機能と別個に、端末及びメニュー機能を実行す
ることによって向上可能である。

例えば第１図に示すように、システム１０はアプリケー
ションデータベース及び演算プロセス１８と別個に、端
末及びメニュープロセス１７を有する。端末及びメニュ
ー機能を制御するプロセス１７がトランザクション処理
システムの１フロントエンド”と称され、データベース
及び演算プロセス１８が同じシステムの“バンクエンド
”と称される。

端末及びメニュープロセス１７とアプリケーションデー
タベース及び演算プロセス１８は、別個のデータプロセ
ッサによって実施することもできるし、あるいは多重処
理環境をサポートするオペレーティングシステムを備え
た単一のデータプロセッサによって実施することもでき
る。単一プロセッサを用いたシステム１０は°単一ノー
ド”システムと称され、１つより多いデータプロセッサ
を有するシステムは“多重ノード１システムまたはネッ
トワークと称される。多重ノードシステムでは、端末及
びメニュープロセス１７を１つのコンピュータまたは一
組のコンピュータにインストールし、アプリケーション
データベース及び演算プロセス１８を別の１つのコンピ
ュータまたは別の一組のコンピュータにインストールす
ることによって、システムの性能及び資源共用が改善さ
れる。

システム１０の性能をさらに向上させるため、端末及び
メニュープロセス１７によって与えられるデータは、“
タスクキュー°１９を介してアプリケーションデータベ
ース及び演算プロセス１８に伝送される。システム性能
は特に、データの検索とデータの据置処置、高いアプリ
ケーションの利用性及びトランザクションの持続性を必
要とするトランザクシジン処理のアプリケーションにお
いて改善される。このようなアプリケーションの例は、
勤務交替時間だけの非常に短い時間中にシステムに入力
されるタイムカードデータの処理である。このようなア
プリケーションでは、各データ項目の処理がシステムの
全体性能に即座に悪影響を及ぼすことがあるので、以後
の処理のためデータを検索してからそれをタスクキュー
１９内に記憶できることが有用である。この種の処理は
、データの検索とデータの処理が同期されていないため
、５弁開期処理”としても知られている。

タスクキュー１９は、端末及びメニュープロセス１７が
アプリケーションデータベース及び演算プロセス１６を
実施する１つ以上のプロセッサと別個な少なくとも１つ
のプロセッサによって実施される場合に、システムの利
用性を高める。つまりこのような分散環境では、１つ以
上のバックエンドプロセッサが故障しても、１つ以上の
フロントエンドプロセッサはタスクキュー１９にタスク
を提出することによって処理を続けられる。

以下詳しく説明するように、タスクキュー１９は、部分
的なシステム故障またはその他の異常な終了がトランザ
クションの処理を中断した後トランザクションの完了を
可能とするキューイング機構と組み合わせて使用可能で
ある。例えば、第１図に示したシステム１０は、タスク
の完了まで、中断されたタスクを再び開始させる待機タ
スク開始プログラム２０を有する。タスクが完了すると
、そのタスクはタスクキュー１９から取り出される。

タスクの完了は、そのタスクに関連したアプリケーショ
ンが首尾よ〈実施されたことが必ずしも意味しない。ア
プリケーションデータベース及び演算プロセス１８が処
理すべきデータ中におけるエラーの存在や、アプリケー
ションの実施を妨げるシステム１０内の故障を検出する
かもしれないからである。いずれの場合にも、待機タス
ク開始プログラム２０はタスクキュー１９からタスクを
取り出す前に、そのタスクのエラーコードをエラーキュ
ー２１内に入れる。またアプリケーションによっては、
それぞれのアプリケーションが正常に完了しなかった場
合、エラーデータの補正かあるいはシステム１０の補修
後にタスクが完了されるのを可能とするため、待機タス
ク開始プログラム２０がタスクデータの一部または全て
をタスクキュー１９からエラーキュー２１へ移すのが望
ましいこともある。エラーキュー２１内に入れられたエ
ラーコードは、例えばシステムオペレータ（図示せず）
によって定期的に調べられ、適切な補正措置が取られる
。

本発明の重要な特徴によれば、アプリケーションデータ
ベース及び演算プロセス１８が正確に１回のセマンティ
クスインタフェース２２を介してアプリケーションデー
タベース１６を更新し、該インタフェース２２によって
システム１０は、中断された１つ以上のタスクが正確に
１回行われる方法で部分的なシステム故障またはその他
アプリケーションの異常な終了から自動的に回復可能で
ある。正確に１回のセマンティクスインタフェース２２
が存在しないと、システム１０は中断されたタスクによ
って、アプリケーションデータベースＩ６を２回更新し
てしまう可能性がある。例えば、待機タスク開始プログ
ラム２０がアプリケーションデータベース及び演算プロ
セス１８にタスクを送ることになっていて、要求された
トランザクションの完了後だが、待機タスク開始プログ
ラム２０がタスクキュー１９からタスクを取り出す前に
、部分的なシステム故障またはアプリケーションの異常
な終了が生じたとすると、自動回復中に待機タスク開始
プログラム２０が中断されたタスクを再び開始したとき
、アプリケーションデータベースが２回更新される可能
性がある。

正確に１回のセマンティクスインタフェース２２は、部
分的なシステム故障またはその他アプリケーションプロ
セスの異常な終了後に動作して、中断されたアプリケー
ションの再開始がアプリケーションデータベース１６の
二重更新を試みようとしていることを検出する手段を含
んでいる。そのようなアプリケーションプロセスの再開
始を検出すると、正確に１回のセマンティクスインタフ
ェース２２はアプリケーションデータベース１６のいか
なる二重更新も防ぎ、完了メツセージを待機タスク開始
プログラム２０に戻す。完了信号を受は取ると、待機タ
スク開始プログラム２０はそのタスクをタスクキューか
ら取り出す。

以下詳しく説明するように、正確に１回のセマンティク
スインタフェース２２は、待機タスク開始プログラム２
０によって開始された各タスクに対応する固有のタスク
識別番号を、その前にアプリケーションデータベース１
６内に記憶された１つ以上のタスク識別番号のレコード
と比較することによって、アプリケーションデータベー
ス１６の二重更新が試みられているのを検出するのが好
ましい。但し、最初の状態で認識可能なタスク識別番号
がアプリケーションデータベース内に記録されていない
ように、アプリケーションデータベースは最初にフォー
マント化されるものとする。

インタフェース２２は、実施されるタスクのタスク識別
番号とその前に記録されたタスク識別番号との合致を見
い出す毎に、アプリケーションデータベース１６の二重
更新が試みられようとしていると判定し、二重更新の発
生を防止する。

次に第２図を参照すると、タスクキュー（第１図の１９
）内に記憶されるタスクデータベースのレコード用の好
ましいフォーマットが示しである。

端末及びメニュープロセス１７がアプリケーションデー
タベース及び演算プロセス（第１図の１８）によって実
施されるべきトランザクションのためのデータを収集す
るとその都度、端末及びメニュープロセス１７は、タス
クキュー１９内に入れられるべき要求トランザクション
つまりタスクについてＴＡＳＫ　１０　“　（タスク識
別番号（ｒＤ）を生成する。正確に１回のセマンティク
スインタフェース（第１図の２２）が二重更新の試みを
検出可能とするため、ＴＡＳＫ−１０は時間と空間にわ
たって固有である。すなわち、端末及びメニュープロセ
ス１７によって異なる時点に発生される２つのタスクは
いずれも必然的にそれぞれ異なるタスク識別番号を有し
、また（例えば多重プロセッサシステムの異なるプロセ
ッサで生成される結果）異なるプロセスが全く同一時点
にそれぞれのタスクを生成したとしても、タスク識別番
号は異なるものとされる。第２図に示したように、タス
ク識別番号の時間と空間にわたる一意性は、システム内
のクロックから信号発生されたタスク生成の時刻３１と
、タスクを生成したプロセッサつまりノードの識別番号
３２との連結からタスク識別番号を形成することによっ
て保証される。

各タスク毎にタスクキュー内に記憶されるタスクデータ
は、タスクによって要求されている各アプリケーション
プロセスの名前３３をさらに含む。

かかる名前がアプリケーションデータベース及び演算プ
ロセス１８によって認識されると、予め記憶されたルー
チンまたはアプリケーションプログラムが実行され、タ
スクによって要求されているトランザクションを行う。

各タスク毎にタスクキュー１９内に記憶されるタスクデ
ータはさらに、タスクによって要求されているトランザ
クションの実施のため、端末及びメニュープロセス１７
によって収集されたタスクデータ３４を含むこともでき
る。アプリケーションデータベース及び演算プロセス１
８がタスクによって要求されているトランザクションを
実施するとき、場合によって端末及びメニュープロセス
１７によって収集された各タスクデータが、アプリケー
ションデータベース１６から読み取られたその他の入力
データと組み合わせられ入力データとして使われる。

端末及びメニュープロセス１７に影響を及ぼす部分的な
システム故障にもかかわらず、タスクキュー１９は第２
図のフォーマントのタスクデータを受は取ると見なされ
る。すなわち、タスクキュー１９は永久メモリ内にファ
イルとして編成され、任意の与えられたタスクに関する
全てのタスクデータを１回の“アトミック”動作でタス
クキュー内へと書込可能としていると見なされる。この
点は例えば、米国マサチューセッツ州０１７５４、マナ
ード所在のデジタル・エクイフブメント社から市販され
ているＲＭＳ　（レコード管理サービス）システムなど
、任意の数の通常のデータベース管理プログラムからな
る“回復ユニットジャーナル”機能を用いることによっ
て行える。この場合、タスクデータをデータキュー１９
内に書き込むためのプログラム命令は、１つの“回復ユ
ニット“内に含まれている。但し、通常のプログラミン
グ技術を有するものであれば第５〜９図に関する以下の
説明から、タスクキュー１９をどのように編成すれば、
第２図のタスクデータを１回の“アトミック”動作でタ
スクキュー内に入れられるか理解できるであろう。

ユーザが端末１１〜１５のいずれか１つでデータを入力
している間に部分的なシステム故障が生じると、その故
障は、タスクに関するデータを再人力することをユーザ
に要求することが多い。あるいは、各端末で現在入力さ
れているタスクに関するデータをそれぞれのキューに記
憶しておき、部分的なシステム故障が生じたらキュー内
のデータをキュー出しし、ユーザが中断地点からデータ
の入力を続けるようにするごともできる。一般に、シス
テム１０との対話的なデータ入力が可能である限り、揮
発性メモリ内に入れられたが、非揮発性つまり永久メモ
リ内にはまだ入れられていないいずれかのデータまたは
ユーザコマンドが部分的なシステム故障によって破壊さ
れているかもしれないため、部分的なシステム故障がシ
ステムに人力されていた一部のデータを破壊したかある
いは破壊しなかったかという問題が必ず生じる。しかし
以下さらに説明するように、処理すべきデータがタスク
キュー１９などの永久メモリ内に入れられている限り、
システムは部分的なシステム故障またはその他アプリケ
ーションプログラムの異常な終了から自動的に回復する
ように設計可能である。

タスクキュー（第１図の１９）は、シングルキー式索引
ファイルとして構成されるのが好ましい。

ファイルのキーは、タスクが生成されたときのシステム
のクロック時刻に予め割り当てられた優先順位番号を連
結して形成され、キーの数値順序が、タスクがキュー内
に入れられ且つ開始されるべき順序と対応するようにな
すのが好ましい。その後、タスクのキュー入れ、タスク
のキュー出し、及び次タスク用データの読取の各動作は
、前記ＲＭＳソフトウェアによって与えられる機構など
、キー索引ファイルを管理するための通常の機構によっ
て実施できる。

次に第３図を参照すると、待機タスク開始プログラム（
第１図の２０）によって実施される手順のフローチャー
トが、全体を４０で示しである。

最初のステップ４１では、待機タスク開始プログラムが
タスクキュー１９を読み、キュー内の次タスクに関する
データを得る。（単一のアプリケーションプロセッサを
有するシステムでは、データがキューの先頭に現れる）
。ステップ４２では、タスクキューが空かどうかテスト
される。空の場合はステップ４３で、待機タスク開始プ
ログラムがある一定の時間遅延され、待機タスク開始プ
ログラムが再びタスクキューを読む前に、端末及びメニ
ュープロセス（第１図の１７）によってタスクキューが
満たされるのを可能とする。

タスクデータがキューから得られたら、待機タスク開始
プログラムがステップ４４を実施し、タスクデータ内の
名前（第２図の３３）のアプリケーションプロセスを呼
び出し、タスク識別番号とその他のタスクデータ（第２
図の３４）をアプリケーションプロセスに渡す。ステッ
プ４５で待機タスク開始プログラムは、アプリケーショ
ンプロセスが完了しているかどうかをチエツクする。完
了していないと、待機タスク開始プログラムはステップ
４６で、アプリケーションプロセッサが利用可能かどう
かをチエツクする。アプリケーションプロセッサが利用
可能でないと、ステップ４５が再び行われる。利用可能
なら、タスクキュー内の次タスクのデータをステップ４
Ｉで読み取ることができる。　（単一プロセソサシステ
ムでは、現プロセスが終るまで唯一のアプリケーション
プロセッサが利用可能とならないので、ステップ４６は
単一プロセッサシステムで行う必要がない）。

呼び出されたアプリケーションプロセスが完了したら、
待機タスク開始プログラム２０はステップ４７で、プロ
セスが首尾よ（完了したかどうかを判定する。してない
と、首尾よく完了しなかったことを示すエラー状態コー
ドとタスク識別番号が、ステップ４８でエラーキュー２
１内に入れられる。

最後にステップ４９で、完了したタスクがキューから取
り出され、タスク開始サイクルがステップ４６から再び
繰り返される。

単一のコンピュータまたばプロセッサがアプリケーショ
ンデータベース及び演算プロセス（第１図の１８）の全
てを行うようなシステム１．０では、ステップ４４にお
いて、呼び出されたアプリケージクンプロセスが完了す
るまでその呼び出されたアプリケーションプロセスに実
行権を渡すサブルーチンコールを行うだけでよい。多数
のコンピュータまたはプロセッサが異なるアプリケーシ
ョンプロセスを同時に実施するような多重プロセッサシ
ステムでは、同時に発生するアプリケーションプロセス
間で衝突が生じないことを、システムが保証する必要が
ある。

“デッドロック′として知られる潜在的な衝突は、例え
ば、一対のプロセッサの各プロセッサが現在他方のプロ
セッサによって使われている資源を必要とするときに生
じ得る。この場合、デッドロックが解消されてから、ど
ちらのプロセッサもそれぞれの割当アプリケージタンを
完了できなければならない。潜在的な衝突の他の原因は
、２つの同時に実施されているアプリケージタンの正味
の結果が、一方のアプリケーションの特定ステップが他
方のアプリケーションの特定ステップの前または後に行
われることに依存している場合に生じる。ごのような場
合、システムは、タスクキュー１９にタスクが現れる順
序にだけ応じた一貫した結果を与えることが望ましい。

これらの衝突を処理する方法は数多く存在するが、特に
簡単な方法は待機タスク開始プログラム２０がキュー内
の次タスクを読み取ってそれを次の利用可能なアプリケ
ーションプロセッサへ送出するのを、前に呼び出された
タスクが制御権を掌握するまで、つまり必要になるかも
しれない全てのファイルを“オーブン８にするまで禁止
することである。言い換えれば、呼び出されたプロセス
が必要になるかもしれない全てのファイルを“オーブン
′にするまで、ステップ４４は完了されるべきでない。

前述したように、正確に１回のセマンティクスインタフ
ェース（第１図の２２）は、２つの機能を行う。第１の
機能は、タスクによって要求されたトランザクションで
なされた更新が、１回の“アトミック”動作で行われる
ことを保証する通常の機能である。すなわち、部分的な
システム故障またはその他アプリケーションデータベー
ス及び演算プロセスの異常な終了の直後、アプリケーシ
ョンデータベース（第１図の１６）は最後まで完了され
たトランザクションの全ての更新を含み、部分的に完了
されたトランザクションはいずれも含まない。正確に１
回のセマンティクスインタフェース２２は、システムの
回復時に、アプリケーションデータベースがその前に完
了したトランザクションによって１回より多く更新され
ないことを保証する第２の機能も行う。このため、待機
タスク開始プログラム（第１図の２０）は正確に１回の
セマンティクスインタフェース２２と組み合わされて、
要求されたトランザクションの処理が部分的なシステム
故障またはアプリケーションの異常な終了によって中断
された場合でも、タスクキュー（第１図の１９）内のタ
スクによって要求された全てのトランザクションがトラ
ンザクション処理システム（第１図の１０）で１回且つ
その１回だけ実施されることを保証する。

正確に１回のセマンティクスインタフェース２２の第１
機能、すなわちアプリケーションデータベースに対する
アトミック更新を保証する機能は、前述したＲＭＳジャ
ーナル機構など、既存のメモリまたはデータベース管理
機構を用いて実施できる。このような機構を用いれば、
アプリケーションデータベースへのアクセスは、トラン
ザクションに関する全ての更新が同時に生じるように制
御される。

正確に１回のセマンティクスインタフェース２２の第２
機能は、アプリケーションデータベースにアクセスする
トランザクションのトランザクション識別番号を、その
前にアプリケーションデータベース内に記憶された１つ
以上のトランザクション識別番号と比較することによっ
て与えられる。合致すれば、アプリケーションデータベ
ースの二重更新が試みられていたことが検出され、二重
更新の発生が防止される。トランザクションについてア
プリケーションデータベースの更新がなされると、その
トランザクションを要求しているタスクの識別番号がア
プリケーションデータベースに書き込まれ、その後のト
ランザクションの実施時における比較で使えるようにす
る。

正確に１回のセマンティクスインタフェース２２は、各
アプリケーション毎の高水準言語コードに組み込まれた
高水準言語コードによって与えることができる。すなわ
ち、“ＡＰＰＭｆｌＭＢ”という名前のアプリケーショ
ンの場合、高水準言語コードは次のようになる： 上記のプログラムリスト中、プログラムステートメント
“５ＴＡＲＴ　ＴＲＡＮＳＡＣＴＩＯＮ　　”と′″Ｅ
ＮＤ　ＴＲＡＮＳＡＣＴＩＯＮ　”は“回復ユニット”
の範囲を区切るもので、メモリまたはデータベース管理
機構の回復機能によって認識される。この機構が例えば
ＲＭＳジャーナル機構であれば、ステートメント“５Ｔ
ＡＲＴ　ＴＲＡＮＳＡＣＴＩＯＮ　　”は”　　＄５Ｔ
ＡＲＴ　ＲＵ″という特有の形となり、またステー　）
　メ７　）　”　ＥＮＤ　ＴＲＡＮＳＡＣＴｒＯＮ”は
“＄ＣＯｆ旧Ｔ　ＲＵ　″という特有の形になる。

上記のプログラムリストにおいて、アプリケーションの
名前に対応したアプリケーションデータベース及び演算
プロセス用のコードは、正確に１回のセマンティクスイ
ンタフェース用のコード間に挾まれて現れているのが分
かる。しかし、システムのもっと深いレベルでは、正確
に１回のセマンティクスインタフェースがアプリケーシ
ョンデータベースの編成と、アプリケーションデータベ
ース及び演算プロセスとアプリケーションデータベース
間での読取及び書込に影響を及ぼす。このため、正確に
１回のセマンティクスインタフエース２２は、アプリケ
ーションデータベース及び演算プロセス用のコードと同
じレベルのコードとして実施される必要はない。その代
わりに、正確に１回のセマンティクスインタフェースは
、アプリケーションファイルをオーブンし、アプリケー
ションレコードを読取及び書込して、アプリケーション
ファイルをクローズするもっと深いレベルのサブルーチ
ンとして実施できる。このような編成が、第４図のフロ
ーチャート５０に示しである。

例示の目的上、各アプリケーションは、そのアプリケー
ションで実施されるトランザクシジンによって変更され
るオブジェクトの永久状態を定義するレコードを含む付
属のアプリケーションファイルを有するものと仮定する
。この場合、アプリケーションは第４図のフローチャー
ト５０に示した編成を持ち得る。最初のステップ５１で
、アプリケーションファイルがオーブンされる。アプリ
ケーションファイルがオーブンできなければ、アプリケ
ーションは成功せずに終了されねばならない。オーブン
されれば、ステップ５２で、アプリケーションはアプリ
ケーションファイル内のアプリケーションレコードを読
取及び書込できる。最後にステップ５３で、アプリケー
ションファイルはクローズされ、実行は成功してリター
ンする。

アプリケーションが第４図に示すように構成されている
場合、正確に１回のセマンティクスインタフェースは、
アプリケーションファイルをオーブンし、アプリケーシ
ョンレコードを読取及び書込して、アプリケーションフ
ァイルをクローズするルーチンとして実施可能である。

例えば、アプリケーションファイルをオーブンするステ
ップ５１は、そのアプリケーション用の回復ユニットの
開始を定めることができ、またアプリケーションファイ
ルをクローズするステップ５３は回復ユニットの終わり
を定めることができる。タスク識別番号の合致判定はア
プリケーションファイルをオーブンするステップ５１で
行われ、合致したら、実１テは直ちにアプリケーション
ファイルをクローズしてリターンし得る。合致しなけれ
ば、タスク識別番号がアプリケーションファイルをクロ
ーズするステップ５３中にアプリケーションファイルに
書き込まれる。

尚、タスク識別番号は、数多い任意の方法でアプリケー
ションデータベース内に記憶可能である。

待機タスク開始プログラム２０（第１図）とアプリケー
ションデータベース及び演算プロセス（第１図の１９）
が同一のコンピュータまたはプロセッサで実行されてい
れば、部分的なシステム故障または異常な終了後にアプ
リケーションデータベースを二重更新しようとする試み
は、すぐ前にアプリケーションデータベース内に記憶さ
れたのと同じタスク識別番号でアプリケーションデータ
ベースの２回目の更新を行おうとする。従って、アプリ
ケーションデータベース内に１つのタスク識別番号を記
憶するだけでよい。

待機タスク開始プログラム２０とアプリケーションデー
タベース及び演算プロセスが複数のコンピュータまたは
プロセッサで実施され、複数のアプリケーションが異な
るアプリケージ９ンデータベースフアイルへ同時にアク
セスできるような多重プロセッサシステムでは、各アプ
リケーションファイル内に１つのタスク識別番号を記憶
する必要が少なくともある。同時発生アプリケーション
間での衝突がいかに解消されるかに応じて、各アプリケ
ーションファイル内に多数のタスク識別番号を記憶する
必要もある。最悪の場合、データベースは、呼び出され
たキュー上の各タスクのタスク識別番号を残らず記憶し
なければならない。このような各タスクは、完了してい
ても、異常な終了の時点でキューからまだ取り出されて
いないことがあり得るからである。記憶されねばならな
いタスク識別番号は、タスクキューが同じアプリケーシ
ョンを用いた先行するタスクを有するとき、待機タスク
開始プログラムがアプリケーションを呼び出さないこと
を保証することによって、アプリケーションファイル毎
に１つに減らせる；言い換えれば、第３図のステップ４
１で、キューから読み取られた次のタスクデータがキュ
ーの先頭に近い位置にあるアプリケーション名と合致す
るアプリケーション名を有する場合に、両ステップ４２
と４３がスキップされ（“次タスク”ポインタが進めら
れない）。

第５図を参照すると、使用可能なアプリケーションファ
イルのための特定の編成が示しである。

この場合、各アプリケーション毎に、そのアプリケーシ
ョンで実施されるトランザクションによって変更される
全てのオブジェクトの状態を保持する一定数のレコード
を持つ対応したアプリケーションファイルが用意されて
いるものと仮定する。

すなわち、アプリケーションデータベース内の各アプリ
ケーションファイルは、唯一の各アプリケーションによ
ってのみ書込可能である。但し、各アプリケーションは
任意の数のアプリケーションファイルを読み取れる。

アプリケーションがアプリケーションファイル内の任意
の数のレコードを同時に更新可能とするため、アプリケ
ーションファイル６０は、マスタースイッチ６２を記憶
するヘッダレコード６１と二組のアプリケーションデー
タレコード６３とを含む。例えばアプリケーションファ
イル６０内の全てのアプリケーションデータを更新する
のが望ましい場合、この更新はマスタースイッチ６２を
１回のアトミック動作で変更することによって行える。

またアプリケーションファイル６０は、アプリケーショ
ンデータレコード６３のうち選ばれたものだけを同時に
更新可能とするようにも編成されている。この目的のた
め、アプリケーションファイル６０は、各データレコー
ド毎のそれぞれのスイッチの各コピーを含むスイッチレ
コードの２つのコピー６４と６５を含んでいる。

任意のある時点で、アプリケーションによって更新され
たオブジェクトの現状態を定義している所定レコードの
コピーは、ヘッダレコード６１を読んでマスタースイッ
チ６２の状態を得、マスタースイッチ６２の状態によっ
て指示されたスイッチレコードの２つのコピーのうち一
方を読み取った後、この読み取られたスイッチレコード
のコピー内の各スイッチによって指示されている所望な
アプリケーションデータレコードの特定コピーを読み取
ることによって見い出すことができる。逆に、データレ
コードのうち選ばれたものだけを同時に更新するために
は、まずアプリケーションによって更新されたオブジェ
クトの現状態を現在含んでいない各レコードのコピーを
更新し、次にマスタースイッチ６２によって現在指示さ
れていないスイッチレコード内の各スイッチを変更した
後、マスタースイッチ６２を入れるだけでよい。こうず
れば、マスタースイッチを入れるという１回のアトミッ
ク動作で、同時更新が得られる。

アプリケーションファイル６０内のいずれのデータレコ
ードを読取または更新するにもヘッダレコードと少なく
とも１つのスイッチレコードを必ず読み取る必要がある
ので、これら３つのレコードの少なくとも１つに最後の
更新のタスク識別番号を記憶するのが望ましい、しかし
さらに、データし・コードが同時に更新されるときはタ
スク識別番号も同時に更新する必要があるので、更新に
対応したタスク識別番号の各コピー６８．６９がスイッ
チレコードの各コピー６４．６５内に記憶されるべきで
ある。

ここで例えば、アプリケーションファイルが第５図に示
したようなフォーマントを有するものとすれば、アプリ
ケーションファイルをオーブンする第４図のステップ５
１は、第６図のフローチャート７０に対応した正確に１
回のセマンティクスインタフェース（第１図の２２）に
よって実施可能である。最初のステップ７１で、アプリ
ケーションデータベース内のアプリケーションファイル
がオーブンされる。すなわち、アプリケーションファイ
ルがクローズされるまで、それ以外のプロセスはそのア
プリケーションファイルへのアクセスから除外される。

次にステップ７２でアプリケーションファイルのヘッダ
レコードが読まれ、マスタースイッチの状態を得る。そ
の状態がステップ７３でテストされ、マスタースイッチ
が０の値であると、スイッチレコードのコピーＯがステ
ップ７４で読み取られ、そうでないとスイッチレコード
のコピー１がステップ７５で読み取られる。

アプリケーションファイルに対して二重更新を行おうと
する試みを検出するため、ステップ７６で現タスクのタ
スク識別番号（ＴＡＳＫ　１０）がスイッチレコードか
ら読み取ったタスク識別番号と比較される。合致すると
、ステップ７７でアプリケーションデータベース内のア
プリケーションファイルがクローズされ、ステップ７８
で待機キュータスクの二重呼び出しを指示するようにリ
ターンコードがセットされる。このため、実行はリター
ンコードでリターンし、アプリケーション自体がリター
ンコードを認識して終了するようになす。

現タスクのタスク識別番号がスイッチレコードから読み
取ったタスク識別番号と合致しないと、ステップ７９で
ＲＥＡＤ−ＯＮＬＹ　　（読取専用）″フラグが１にセ
ットされ、“ＡＬＲＥＡＤＹ　ＷＲＩＴＴＥＮ　　（書
込済み）″アレイがクリアされる。“ＲＥＡＤ　０ＮＬ
Ｙ　　”フラグは、現トランザクション中にアプリケー
ションファイルが読み取られるだけの場合に、ヘッダレ
コードとスイッチレコードを更新する必要を取り除くの
に使われる。”ＡＬＩ？ＥＡＤＹ　ＷＩ？ＩＴＴＥＮ　
”アレイは、変更の書込後回−レコードを読み取る場合
に、アプリケーションがアプリケーションファイルの編
成に対して透明になるようにし、また各データレコード
が書込動作のためアプリケーションによってまずアクセ
スされる場合に、各レコード用のスイッチがトランザク
ションの実施中に１回だけ入れられるようにするために
使われる。ステップ７９後、実行は平常通リリターンす
る。

次に第７図を参照すると、アプリケーションファイル中
の所定のレコードｎを読み取るためアプリケーションに
よってコールされるフローチャートが全体を９０で示し
である。選択されたレコードの２つのコピーの各１つが
、スイッチレコードから読み取られた所定レコード用ス
イッチの状態に応じて読み取られる。各スイッチがステ
ップ９１でテストされる。スイッチがゼロのとき所定レ
コードのコピー０がステップ９２で読み取られるが、あ
るいはスイッチが１のとき所定レコードのコピー１がス
テップ９３で読み取られる。

次に第８図を参照すると、アプリケーションが所定のレ
コードｎをそのアプリケーションファイルに書込可能と
するための、正確に１回のセブンティクスインタフェー
ス２２内のフローチャートが全体を１００で示しである
。最初のステップ１０１で、“ＡＬＲＥＡＤＹ智ＲＩＴ
ＴＥＮ　”アレイの各エントリがテストされる。最初こ
のエントリはゼロで、この場合には指定レコードのスイ
ッチがステップ１０２でテストされ、指定レコードがそ
のアプリケーションファイル内の指定レコードのコピー
１またはコピー０のどちらかに書き込まれるべきかを判
定する。指定スイッチがＯであれば、ステップ１０３で
レコードがコピーｌに書き込まれ；そうでなければステ
ップ１０４で、レコードがコピー０に古き込まれる。し
かし、次に同じタスク及び同じレコードに対して書込が
試みられると、各スイッチが変更されており、この場合
にはスイッチがステ・ンブ１０５でテストされ、同じレ
コードの同じコピーへの書込を行う。次いで、ステップ
１０６で“ＡＬＲＥＡＤＹ−ＷＲＩＴＴＥＮ　　”アレ
イの各エントリがテストされ、現タスクで指定レコード
が初めて書き込まれるのかどうかを判定する。レコード
が初めて書き込まれるのであれば、ステップ１０７で各
スイッチが変更され、’ＡＬＩ？ＥＡＤＹ　ＷＲ（ＴＴ
ＥＮアレイの各エレメントがセントされ、’ｔ？ＥＡ口
０ＮＬＹ’フラグがクリアされる。

次に第９図を参照すると、アプリケーションファイルを
クローズするためのフローチャートが全体を１１０で示
しである。最初のステップ１１１で、“ＲＥＡＤ　０Ｎ
ＬＹ　　”フラグがテストされ、現トランザクション中
にアプリケーションプログラムがそのアプリケーション
ファイルを読み取っただけかどうかを判定する。そうで
あれば、アプリケーションファイルはスイッチレコード
またはヘッダを可算更新することなく、ステップ１１２
で単に閉じられる。そうでなければ、ステップ１１４で
マスタースイッチがテストされ、現スイッチレコードが
ステップ１１５でスイッチレコードのコピー１に書き込
まれるべきか、ステップ１１６でコピー０に書き込まれ
るべきかを判定する。ステップ１１７でマスタースイッ
チが変更され、ステップ１１８でマスタースイッチの変
更された状態がアプリケーションファイルのヘッダに書
き込まれる。最後に、ステップ１１２でアプリケーショ
ンファイルがクローズされる。

（発明の効果） 以上において、正確に１回のセマンティクスインタフェ
ースと組み合わされて、部分的なシステムエラーまたは
めの他異常な終了からの自動的な回復を与えるように動
作するタスクキュー開始プログラムを有するトランザク
ション処理が記述された。アプリケーションプログラム
は、はとんどまたは全く修正なしでシステムに組み込め
る。正確に１回のセマンティクスインタフェースは、通
常のメモリまたはデータベース管理機構の“管理ユニッ
ト”を呼び出す高水準コードか、あるいはアプリケーシ
ョンファイルをオーブンし、読み取り、書き込み及びク
ローズする低水準サブルーチンとして実施可能である。

このシステムは、マルチプロセッサの構成に容易に適合
できる。

【図面の簡単な説明】

第１図は本発明によるタスクキューと正確に１回のセマ
ンティクスインタフェースを具備したトランザクション
処理システムのブロック図；第２図は第１図のシステム
で使われるタスクキュー内に記憶されるタスクデータ用
の好ましいフォーマントの図；第３図は第１図のタスク
キューを処理する待機タスク開始プログラムの動作を示
すフローチャート；第４図は第１図のタスクキューにキ
ュー入れされたタスクを実施するアプリケーションの一
般化フローチャート；第５図は各レコードを１回の“ア
トミック”ステップで同時に更新可能とする、アプリケ
ーションファイルにおけるレコードの１つの可能な構成
を示す図；第６図はアプリケーションファイルに関して
正確に１回のセマンティクスを可能とするアプリケーシ
ョンファイルをオーブンするサブルーチンのフローチャ
ート；第７図は正確に１回のセマンティクスを有するフ
ァイル内の選）尺されたレコードを読み取るサブルーチ
ンのフローチャート；第８図は正確に１回のセマンティ
クスを有するファイルに選択されたレコードを書き込む
サブルーチンのフローチャート；及び第９図は正確に１
回のセマンティクスをクローズするサブルーチンのフロ
ーチャートである。 ＩＯ−・・トランザクション処理システム、１６アプリ
ケーシヨンデータベース、１８−アプリケーションプロ
セッサ手段、１９−メモリキュー２０・−待機タスク開
始手段（プログラム）、２２正確に１回のセマンティク
スインタフェース手段。

Claims (1)

1. 【特許請求の範囲】 １、アプリケーションデータベースを記憶する非揮発性
   メモリ、 部分的なシステム故障の発生時に、各トランザクション
   が各データベースの更新を全体として行うかまたは全く
   行わないように、前記データベースを更新するトランザ
   クション処理用のアプリケーションプロセッサ手段、 各トランザクションを識別するタスクデータ、レコード
   を記憶する非揮発性メモリキュー、前記キュー内の特定
   タスクデータレコードを選択して前記アプリケーション
   プロセッサ手段を呼び出し、該選択されたタスクデータ
   レコードによって識別されたトランザクションを処理し
   、要求されたトランザクションの処理が完了したら、選
   択されたタスクデータレコードを前記キューから取り除
   く待機タスク開始手段、及び 前記部分的なシステム故障後に動作し、前記選択された
   タスクデータレコードによって識別されたトランザクシ
   ョンの処理が、要求されたトランザクションによって前
   記データベースに対しその前になされていた二重の更新
   を行うものであるかどうかを検出し、そうであれば二重
   の更新を防いで、前記選択されたタスクデータレコード
   を前記キューから取り除く正確に１回のセマンティクス
   インタフェース手段、 の組合せからなるトランザクション処理システム。 ２、前記検出する手段が、選択されたタスクデータレコ
   ードに対応するタスク識別子をアプリケーションデータ
   ベースから読み取られたタスク識別子番号と比較し、両
   タスク識別子が同一タスクを識別しているかどうかを検
   出する手段を含む請求項１記載のトランザクション処理
   システム。 ３、前記選択されたタスクデータレコードに対応したタ
   スク識別子が、前記キューに前記タスクデータレコード
   の一部として記憶されている請求項２記載のトランザク
   ション処理システム。 ４、前記タスク識別子が前記キューに記憶される各タス
   クデータレコード毎に固有である請求項３記載のトラン
   ザクション処理システム。 ５、前記正確に１回のセマンティクスインタフェース手
   段が、選択されたタスクデータレコードに対応するタス
   ク識別子によって前記データベースを更新し、該タスク
   識別子による前記データベースの更新が、前記選択され
   たタスクデータレコードによって識別されたトランザク
   ションの処理による前記データベースの更新と同時なさ
   れる請求項２記載のトランザクション処理システム。 ６、前記アプリケーションプロセッサ手段が、複数のト
   ランザクションを同時に処理して異なるアプリケーショ
   ンファイルを更新する手段を含み、前記正確に１回のセ
   マンティクスインタフェース手段が、各アプリケーショ
   ンファイル内にそれぞれ異なるタスク識別子を記憶する
   手段を含む請求項５記載のトランザクション処理システ
   ム。 ７、前記正確に１回のセマンティクスインタフェース手
   段が、前記データベース内の複数のデータレコードを同
   時に更新する手段を含む請求項１記載のトランザクショ
   ン処理システム。 ８、データベース、タスクキュー、及び該タスクキュー
   内にキュー入れされている選択タスクによって要求され
   たデータベースの更新を行うアプリケーションプロセッ
   サを有するデータ処理システムを作動する方法で、タス
   クによって要求されたデータベースの各更新が行われた
   後前記タスクが前記タスクキューから取り出され、デー
   タベース更新の実施後に発生した前記システムの部分的
   な故障が、各タスクの前記タスクキューからの通常の取
   り出しを防止可能であり、その後前記各タスクが前記デ
   ータベースの二重更新を行わないように防止する方法に
   おいて、前記タスクキュー内の各タスクにそれぞれのタ
   スク識別子を割り当てるステップ、及び選択タスクによ
   って要求されたデータベースの更新を行う前に： 前記データベースを読んで、予め記憶されたタスクを得
   るステップ： 予め記憶されたタスクの識別子を各タスクに割り当てら
   れたそれぞれのタスク識別子と比較し、両タスク識別子
   が同一タスクを識別しているかどうかを判定するステッ
   プ：及び 前記両タスク識別子が同一タスクを識別していることを
   前記比較テップが判定した場合、選択タスクによって要
   求されたデータベースの更新を禁止するが、要求された
   タスクのタスクキューからの取り出しは禁止せず、また
   そうでないと判定した場合には、選択タスクの各識別子
   をデータベース内に書き込むステップ： を含むデータ処理システムの作動方法。 ９、各タスク識別子のデータベース内への書込及び要求
   タスクによって要求されたとおりのデータベースの更新
   全てが同時に生じる請求項８記載のデータ処理システム
   の作動方法。 １０、多数のタスクが前記タスクキュー内に記憶され、
   キュー内の各タスクに割り当てられる前記タスク識別子
   が困難である請求項８記載のデータ処理システムの作動
   方法。