JPH09204341A - 採番機構、データ整合性確認機構、トランザクション再実行機構及び分散トランザクション処理システム - Google Patents

Abstract

(57)【要約】 【課題】 複数の計算機からなる分散システムでトラン
ザクション処理を行なう場合に、計算機間に渡る障害発
生時に、一方の計算機が相手計算機の状態確認できるま
でロックされることを回避しつつ、障害復旧後にデータ
の一貫性を回復することができる。 【解決手段】 トランザクションのロールバックでも戻
されず、また採番後コミットまでの間ロックされること
もない採番のプログラムインターフェース機構と、メモ
リの情報が失われるようなシステム障害の発生後はファ
イルに残った順序番号＋Ｎ以上の順序番号を復元するこ
とにより、仮に障害が発生しても、業務プログラムに最
後に返した順序番号より大きい順序番号から採番を再開
する採番回復機構とからなる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、採番機構、データ
整合性確認機構、トランザクション再実行機構及び分散
トランザクション処理システムに係り、詳しくは、複数
の計算機に渡る分散トランザクション処理を行なう情報
処理システムに適用することができ、特に、分散トラン
ザクション処理を行なう際、高い可用性と高いデータ整
合性を維持して構築することができる分散トランザクシ
ョン処理システムに関する。

【０００２】

【従来の技術】従来、分散トランザクション処理を行う
計算機システムでは、計算機間に渡る障害、例えば１台
以上の計算機のクラッシュや通信路障害が発生した場
合、その時点でインダウト状態のトランザクションに対
する処置を以下の（イ）、（ロ）の処置のうちの何れか
で行っている。インダウト状態は、２フェイズ・コミッ
トのプリペア要求に対してプリペア完了を通知して、コ
ミット／ロールバック指示を待っている状態のことを言
い、そのトランザクションだけでは、最終的にコミット
すべきか、あるいはロールバックすべきかを決定するこ
とができない。

【０００３】（イ）インダウト状態のトランザクション
に対する処置は、障害が復旧するまでコミット／ロール
バック指示を待ち続ける。特に、インダウト状態のトラ
ンザクションを含む計算機がクラッシュした場合は、計
算機の再ブート後、コミット／ロールバック指示待ち状
態を再現して待ち続ける。このような機構は、例えば米
国Ｏｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎのデータベー
ス管理システムであるＯｒａｃｌｅ７に設けられてい
る。例えば日本オラクル株式会社発行「Ｏｒａｃｌｅ７
Ｓｅｒｖｅｒ概要」部品番号６６９３−７０−１２９
２．ｊａ３の２２−１９「２フェイズ・コミットにおけ
る障害」によれば、Ｏｒａｃｌｅ７には自動回復の機能
があると記載されている。

【０００４】（ロ）インダウト状態のトランザクション
に対する処置は、コミット／ロールバック指示待ちを打
切り、ユーザの判断（ヒューリスティック決定）により
処理を継続する。ユーザがシステム状態を確認すること
ができないままヒューリスティック決定を行なった場合
は、データの整合性が失われることがある。そこで、障
害復旧後、システムがグローバル・トランザクションＩ
Ｄをキーにして、各分散トランザクション構成要素間の
コミット／ロールバックの整合性をチェックしてレポー
トするヒューリスティック・レポートシステムが挙げら
れる。例えば、前述した「Ｏｒａｃｌｅ７ Ｓｅｒｖｅ
ｒ概要」２２−２０によれば、Ｏｒａｃｌｅ７は、間違
った決定を自動的に検出する。但し、この場合、ヒュー
リスティック・レポートは、システムの振るグローバル
・トランザクションＩＤ（ＧＴＩＤ）で問題トランザク
ションを通知するので、ユーザは、グローバル・トラン
ザクションＧＴＩＤから実際の対応を決めなければなら
ない。

【０００５】従来、（ロ）の処置で、ヒューリスティッ
ク・レポートを利用せずに処置する場合として、業務ア
プリケーションでの通番管理で整合性を確認する分散ト
ランザクション処理システムが挙げられる。以下に、こ
の従来の分散トランザクション処理システムについて、
図面を用いて説明する。図３２は従来の分散トランザク
ション処理システムの構成を示すブロック図であり、図
３３は図３２に示す分散トランザクション処理システム
上のサイトＡのトランザクションＴＡ１の処理フローを
示すフローチャートである。図３２では、ＲＰＣを用い
て２つのサイトＡ、Ｂでデータベースを同期的に更新す
るシステムの例を示している。図３３では、同期の状態
を従来のユーザ通番で管理する場合、ＲＰＣを用いて２
つのサイトＡ、Ｂでデータベースを同期的に更新するト
ランザクションの処理内容を示している。図３２のＤＢ
Ａは、サイトＡの注文データベース（マスタ）であり、
ＤＢＢはサイトＢの注文データベース（レプリカ）であ
る。各データベースの注文レコードＲＥＣＡ、ＲＥＣＢ
は、注文番号Ｋｅｙをキーとして注文情報Ｄａｔａをカ
ラムとして持つ。図３３のトランザクションＴＡ１は、
端末から入力された注文情報に対して注文レコードを作
り、各データベースに挿入処理を行なう。

【０００６】図３４は図３２に示す分散トランザクショ
ンシステムによりサイトＡとサイトＢのデータの不整合
が検出される様子を示す図である。ここでは、親トラン
ザクションがコミットしたのに子トランザクションがロ
ールバックした場合、従来の方法で、ユーザの通番でデ
ータの整合性が崩れていることが検出される例を示して
いる。サイトＡの注文データベース（マスタ）ＤＢＡと
サイトＢの注文データベース（レプリカ）ＤＢＢの構造
は、図３２に示した通りである。サイトＡのトランザク
ションＴＡ１は、端末から入力される注文情報’ＡＡ
Ａ’を受信すると（ステップＳ１００１）、データベー
ス上に注文番号’１０１’を採番し（ステップＳ１００
２）、ここで一旦ローカルにコミットする（ステップＳ
１００３）。次に、サイトＡのトランザクションは、注
文番号をキーとして端末から入力される注文情報’ＡＡ
Ａ’を内容とする注文レコードＲＥＣＡを作成して、サ
イトＡの注文データベース（マスタ）ＤＢＡに書き出す
（ステップＳ１００４）。

【０００７】続いて、サイトＡのトランザクションは、
サイトＢに対して、注文番号（Ｋｅｙ）、注文情報（Ｄ
ａｔａ）を引数として手続きｐ１をＲＰＣ（Ｒｅｍｏｔ
ｅＰｒｅｃｅｄｕｒｅ Ｃａｌｌ）する（ステップＳ１
００５）。この時、サイトＡのトランザクションは、サ
イトＢのトランザクションへ注文番号と注文情報を送信
する。この時のパラメータは、注文番号（Ｋｅｙ）の’
１０１’と、注文情報（Ｄａｔａ）の’ＡＡＡ’であ
る。サイトＢのトランザクションは、サイトＡのトラン
ザクションから送信されるパラメータに従って注文レコ
ードＲＥＣＢを作成し、注文データベース（レプリカ）
ＤＢＢに書き出し（ステップＳ１００６）、制御をサイ
トＡのトランザクションに戻す（ステップＳ１００
７）。

【０００８】サイトＡのトランザクションは、コミット
処理を行なうためにサイトＢの手続きｐ１にプリペア要
求を送る（ステップＳ１００８）。サイトＢの手続きｐ
１は、プリペア要求を受けると、そのプリペア要求に対
してログ採取機構ＬＡによりプリペア・ログを採取して
プリペアを実施し、その後、レディー通知（プリペア完
了通知）をサイトＡのトランザクションに返す（ステッ
プＳ１００９）。サイトＡのトランザクションは、サイ
トＢからレディー通知を受けると、ローカルなコミット
を実行し、サイトＢにコミット指示を送信する（ステッ
プＳ１００８）。この直後、サイトＡのトランザクショ
ンは、サイトＢがコミット指示を受け取る前にシステム
・クラッシュしたとし、その結果を端末へ送信する（ス
テップＳ１０１０）。

【０００９】サイトＢの手続きでは、障害原因解決後、
システムの再起動が行われる。この例では、障害発生時
にプリペア状態だったトランザクションは、ヒューリス
ティック決定によりロールバックされ、どのトランザク
ションがロールバックされたかについては、ロールバッ
クされたレコードの内容とともに通知するものとする。
ユーザは、通知された情報中のレコード・キーを参照し
てサイトＡの同レコードを確認する。これにより、ユー
ザは、該当レコードがあるので、データの不整合が発生
していることが判る。

【００１０】

【発明が解決しようとする課題】上記した従来の分散ト
ランザクション処理システムでは、（イ）のトランザク
ション処置を採用した場合、データの整合性を完全に維
持することができるが、データベース等のリソースが障
害復旧するまでロックされてしまうため、システムの可
用性が低下するという問題があった。一例として挙げた
Ｏｒａｃｌｅ７の場合でも、障害回復までに時間がかか
りそうな場合等は、手動でヒューリスティック決定を行
なうことを勧めている。これについては、「Ｏｒａｃｌ
ｅ７ Ｓｅｒｖｅｒ 管理者ガイド」部品番号６６４４
−７０−１２９２．ｊａ４の１５−１５「分散トランザ
クションの問題を解決する」中、「インダウト・トラン
ザクションを手動で置き換える」の項で言及している。
また、この方式は、実装も運用も複雑であり、サポート
していないデータベース管理システムがある。

【００１１】これとは逆に、（ロ）を採用した場合は、
リソースが直ちに解放され、可用性の点では問題はない
が、ユーザが他の計算機のトランザクションの状態を確
認することができないとデータの整合性が失われる恐れ
がある。これについては、同じく、「Ｏｒａｃｌｅ７
Ｓｅｒｖｅｒ 管理者ガイド」の同項で、間違った決定
がデータベースの矛盾を引き起こし得ることに言及して
いる。従来の方式では、たとえヒューリスティック・レ
ポートでデータの不整合が判るとしても、その情報は、
業務とは直接関係なく、また、具体的な復旧処置は、ユ
ーザに任されているので、システム設計、アプリケーシ
ョン設計上の負担が大きい。

【００１２】更に、前述したユーザの通番で管理する方
法は、採番した時点で業務とは関係なしにコミットが必
要である。仮に、コミットを行なわないと、採番もロー
ルバックもされることになり、図３５に示すように、後
から別のトランザクションが同一通番を再度採番する
と、整合性の検出に使えない。図３５は、従来の方法
で、ユーザの通番自体がロールバックされると整合性が
検出することができなくなる例を示している。

【００１３】そこで、本発明は、２フェイズ・コミット
中の障害に対する複雑な運用と、同障害に際してデータ
がロックされ続けることによるシステム可用性の低下を
回避することができるととに、データベース管理システ
ム自体が障害状態の再現による完全なデータ整合性維持
をサポートしていない場合でも、システム全体としてデ
ータの整合性を維持することができ、しかもデータベー
ス管理システムがヒューリスティック・レポートをサポ
ートしていない場合でも、システム全体としてデータの
整合性の状態を容易に確認することができる採番機構、
データ整合性確認機構、トランザクション再実行機構及
び分散トランザクション処理システムを提供することを
目的とする。

【００１４】

【課題を解決するための手段】ヒューリスティック決定
を行なってデータの不整合が発生しても、現実的には後
から適切な回復トランザクションを投入することで整合
性を回復することができる場合がほとんどである。そこ
で、可用性の低下を回避するために、ヒューリスティッ
ク決定を行なうものとし、必要に応じて後で、元の分散
トランザクションの一部であったプログラムまたは回復
用トランザクションを分散処理と関係しないローカル・
トランザクションとして再実行するものとする。この場
合、ローカル・トランザクションとして実行するのであ
るから、元のプログラムで通信処理をする部分は、受信
処理を除いてＮＯＰとする。受信データは、各トランザ
クションにとってユニークな情報を含んでいるので、通
常の分散トランザクション実行中にログとして採取する
ものとする。ローカル・トランザクションとしての再実
行時には、受信処理はこのログからの読み込みで再現す
る。また、採番に関する部分も、ログから読み込んで再
現する。

【００１５】具体的なシステム障害からの回復処理とし
ては、先ずログから整合性を失わせた可能性のあるトラ
ンザクション、即ち、ヒューリスティック決定の対象と
なったトランザクションを抽出する。ヒューリスティッ
ク・レポートが用意されている分散処理システムでは、
これを利用してデータ整合性を崩したトランザクション
を特定して、対応するトランザクションＩＤ付きで対応
する回復用トランザクションを投入する。ヒューリステ
ィック・レポートがない分散処理システムでは、ロール
バックやシステム障害で後戻りしないことが保証される
採番機構による通番を元にしたＤＢのレコードの突き合
わせにより、両系のデータ整合性が維持されているかを
判断する。以下、請求項毎に本発明の解決手段を示す。

【００１６】本発明に係る採番機構は、順序番号をメモ
リとファイルに保持し、業務プログラムからの採番命令
呼び出しによりメモリ上の順序番号をカウント・アップ
して業務プログラムに返し、計算機全体で既定値または
定義により与えられた回数Ｎ回に一度は最新の順序番号
をファイルに書き出し、トランザクションのロールバッ
クで戻されず、かつ採番後コミットまでの間ロックされ
ることがない採番のプログラムインタフェース機構と、
メモリの情報が失われるシステム障害の発生後はファイ
ルに残った順序番号＋Ｎ以上の順序番号を復元すること
により、仮に障害が発生しても、業務プログラムに最後
に返した順序番号より大きい順序番号から採番を再開さ
せる採番回復機構とを有することを特徴とするものであ
る。

【００１７】本発明に係るデータ整合性確認機構は、分
散トランザクション処理において、コーディネータとな
るトランザクションの分散ノードに設けた請求項１の採
番機構による通番をキーとするレコードを書き込むデー
タベースと、サブオーディネートとなる分散ノードに設
けた同通番を遅くともプリペア・ログと同時にログに書
き込むログ採取機構と、データ整合性確認の際に突き合
わせるべきデータの所在、判断方法を指定した整合性判
断定義と、障害時のヒューリスティック決定によるデー
タ不整合を、インダウトのプリペア・ログはあるがコー
ディネータの指示によるコミット／ロールバックがされ
ていないトランザクションに対して、ログ中の通番に対
応したレコードがあるかを整合性判断定義情報に従って
突き合わせることにより検出するデータ不整合検出機構
とを有することを特徴とするものである。

【００１８】本発明に係るトランザクション再実行機構
は、分散トランザクション処理の１分散ノードであるプ
ログラムを、通常実行時には、受信処理及び請求項１に
よる採番処理は回復用ログに採取しつつ実行し、再実行
時には、そのプログラムまたはそれに対応する回復用プ
ログラムを、元のトランザクションＩＤ付きでローカル
なトランザクションとして再投入して、プログラムの受
信処理以外の通信処理をＮＯＰ化し、受信処理及び請求
項１による採番処理は、通常実行時にはログに書き出
し、トランザクションＩＤに基づいてはログからの読み
出しにより再現し、トランザクションとしてはローカル
トランザクションとして処理するプログラムインタフェ
ース機構を有することを特徴とするものである。

【００１９】本発明に係る分散トランザクション処理シ
ステムは、以下のａ）〜ｆ）に示す構成要素からなり、
子トランザクションを起動する側の親トランザクション
が２フェイズ・コミット上でコーディネータになり、
ｂ）でのヒューリスティック決定としてロールバックを
行なうもので、ｅ）のデータ整合性確認機構としてヒュ
ーリスティック・レポートを備えており、ｆ）のトラン
ザクション再実行機構による再実行トランザクションと
して、元の子トランザクションそのものを投入すること
により、計算機間に渡る障害の発生後一時的にプリペア
状態のトランザクションをロールバックし、後で子トラ
ンザクションを必要に応じてローカル・トランザクショ
ンとして再投入して計算機間の整合性を回復することを
特徴とするものである。 ａ）ログ採取機構、 ｂ）障害発生時に相手トランザクションからのコミット
／ロールバック決定待ちのトランザクションを、ローカ
ルなヒューリスティック決定でコミット／ロールバック
するヒューリスティック決定機構、 ｃ）プリペア・ログのみあって、コミット・ログ及びロ
ールバック・ログがないトランザクションを回復候補と
して抽出する回復候補トランザクション抽出機構、 ｄ）あるトランザクションが回復候補になった場合に、
どのトランザクションを投入すればいいかを示す投入指
示情報、 ｅ）ヒューリスティック決定によってコミット／ロール
バックされたトランザクションと、相手トランザクショ
ンとの間のデータ整合性が崩れていないかどうかを、障
害の復旧後に確認するデータ整合性確認機構、 ｆ）請求項３のトランザクション再実行機構。

【００２０】本発明に係る分散トランザクション処理シ
ステムは、請求項４のａ）〜ｆ）に示す構成要素からな
り、子トランザクションが２フェイズ・コミット上でコ
ーディネータになり、ｂ）でのヒューリスティック決定
としてロールバックを行なうもので、ｅ）のデータ整合
性確認機構としてヒューリスティック・レポートを備え
ており、ｆ）のトランザクション再実行機構による再実
行トランザクションとして、元の親トランザクションそ
のものを投入することにより、計算機間に渡る障害の発
生後一時的にプリペア状態のトランザクションをロール
バックし、後で親トランザクションを必要に応じてロー
カル・トランザクションとして再投入して計算機間の整
合性を回復することを特徴とするものである。

【００２１】本発明に係る分散トランザクション処理シ
ステムは、請求項４のａ）〜ｆ）に示す構成要素からな
り、子トランザクションを起動する側の親トランザクシ
ョンが２フェイズ・コミット上でコーディネータにな
り、ｂ）でのヒューリスティック決定としてコミットを
行なうもので、ｅ）のデータ整合性確認機構としてヒュ
ーリスティック・レポートを備えており、ｆ）のトラン
ザクション再実行機構として請求項３を備え、元の子ト
ランザクションに対応した回復用トランザクションを投
入することにより、計算機間に渡る障害の発生後一時的
にプリペア状態のトランザクションをコミットし、後で
回復用トランザクションを必要に応じてローカル・トラ
ンザクションとして再投入して計算機間の整合性を回復
することを特徴とするものである。

【００２２】本発明に係る分散トランザクション処理シ
ステムは、請求項４のａ）〜ｆ）に示すの構成要素から
なり、子トランザクションが２フェイズ・コミット上で
コーディネータになり、ｂ）でのヒューリスティック決
定としてコミットを行なうもので、ｅ）のデータ整合性
確認機構としてヒューリスティック・レポートを備えて
おり、ｆ）のトランザクション再実行機構として請求項
３を備え、元の親トランザクションに対応した回復用ト
ランザクションを投入することにより、計算機間に渡る
障害の発生後一時的にプリペア状態のトランザクション
をコミットし、後で回復用トランザクションを必要に応
じてローカル・トランザクションとして再投入して計算
機間の整合性を回復することを特徴とするものである。

【００２３】本発明に係る分散トランザクション処理シ
ステムは、請求項４の分散トランザクション処理システ
ムにおいて、データ整合性確認機構は、請求項４のｅ）
のデータ整合性確認機構を請求項２のデータ整合性確認
機構に変更したものであることを特徴とするものであ
る。

【００２４】本発明に係る分散トランザクション処理シ
ステムは、請求項５の分散トランザクション処理システ
ムにおいて、データ整合性確認機構は、請求項５のｅ）
のデータ整合性確認機構を請求項２のデータ整合性確認
機構に変更したものであることを特徴とする分散トラン
ザクション処理システム。

【００２５】本発明に係る分散トランザクション処理シ
ステムは、請求項６の分散トランザクション処理システ
ムにおいて、データ整合性確認機構は、請求項６のｅ）
のデータ整合性確認機構を請求項２のデータ整合性確認
機構に変更したものであることを特徴とするものであ
る。

【００２６】本発明に係る分散トランザクション処理シ
ステムは、請求項７の分散トランザクション処理システ
ムにおいて、データ整合性確認機構は、請求項７のｅ）
のデータ整合性確認機構を請求項２のデータ整合性確認
機構に変更したものであることを特徴とする分散トラン
ザクション処理システム。

【００２７】

【発明の実施の形態】以下、本発明の実施の形態を図面
を参照して説明する。 実施の形態１．本実施の形態は、ロールバックやシステ
ム障害が生じても後戻りしない採番機構による通番を、
アプリケーションの正常／異常終了通知に使用した例で
ある。以下、図面を参照しながら本実施の形態を説明す
る。図１は本発明に係る実施の形態１の採番機構を用い
たトランザクションの処理フローを示すフローチャート
である。採番機構は、まず、端末から入力される注文情
報を受信すると（ステップＳ１）、その注文毎に採番を
行い（ステップＳ２）、この採番を行った結果、即ち処
理確認情報を端末へ送信する（ステップＳ３）。端末オ
ペレータは、採番機構から送信される処理確認情報を端
末の画面に出力し、以降自分の投入した業務を記録し
て、この通番をキーとして参照することができる。これ
により、端末オペレーターは、このトランザクション処
理が例えば２０番であると判る。

【００２８】採番機構は、実際に業務処理を行い（ステ
ップＳ４）、エラーがあるかどうかを判断し、エラーが
なく正常終了であると判断すると（ステップＳ５）、こ
の通番を含んだ正常終了メッセージを出力し（ステップ
Ｓ６）、コミットする。一方、採番機構は、エラーがあ
り異常終了であると判断すると（ステップＳ５）、通番
を含んだ異常終了メッセージを出力し（ステップＳ
８）、ロールバックする（ステップＳ９）。端末オペレ
ータは、出力される正常終了／異常終了メッセージを参
照することにより、自分の投入した業務の２０番が異常
なく終わったかどうかを判断することができる。ここ
で、仮に通番もロールバックされると、次の業務投入に
よって同じ通番が再使用されるため、業務の識別に使え
ない。

【００２９】次に、図２は本発明に係る実施の形態１の
採番機構の処理フローを示すフローチャートである。こ
こでは、採番機構が採番してアプリケーションに結果を
返す処理内容を示している。採番機構は、アプリケーシ
ョンから転送される採番要求情報を受信すると（ステッ
プＳ１１）、メモリ上の現在の採番のエリアをロックし
（ステップＳ１２）、メモリ上の現在の採番に＋１を加
えて、採番を書き換える（ステップＳ１３）。採番機構
は、例えばメモリ上の１９番のエリアをロックし、その
１９番の採番を２０番に書き換える。その後、採番機構
は、採番がＮの倍数であるかどうかを判断し、採番がＮ
の倍数であると判断すると（ステップＳ１４）、メモリ
上の採番を不揮発性媒体にストアし（ステップＳ１
５）、メモリ上の現在の採番をアンロックした後（ステ
ップＳ１６）、その採番結果をアプリケーションに戻す
（ステップＳ１７）。

【００３０】一方、採番機構は、採番がＮの倍数でない
と判断すると（ステップＳ１４）、メモリ上の採番を不
揮発性媒体にストアしないでメモリ上の現在の採番をア
ンロックし（ステップＳ１６）、その採番結果をアプリ
ケーションに戻す（ステップＳ１７）。採番機構は、例
えば１０回に１回メモリ上に書き出すとし、今採番が２
０番になると、メモリ上に２０番の採番を書き出す。こ
れにより、カウンタが２０まで進んでいることがディス
ク上で保証される。採番機構は、例えば採番が２１にな
った時、採番をメモリ上で進めアンロックしてアプリケ
ーションに戻す。

【００３１】次に、図３は本発明に係る実施の形態１の
採番機構の採番の回復処理フローを示すフローチャート
である。ここでは、システム・クラッシュ等のメモリ内
容を失わせる障害発生後の採番機構による現在の採番の
回復処理内容を示している。採番機構は、不揮発性媒体
から現在の採番を回復し（ステップＳ２１）、現在の採
番に＋Ｎを加える。採番機構は、例えば採番が１５番に
なったところでシステム・クラッシュ等が生じると、採
番をメモリ上に持っているため、メモリ上の情報が全て
失われてしまうので、不揮発性媒体にしか頼るものがな
い。不揮発性媒体には、例えば今、採番１５よりも小さ
い採番１０が入っているとし、採番１０から使い始める
と、既に１９まで進んでいる可能性があるので、同じも
のを使用してしまうことがある。これを避けるため、例
えば現在の採番に＋１０を加えてやると、先に進んでい
たとしても１０回に１回は書き出している。このため、
採番が今の＋１０回で２０回になり、採番２０回から使
用すればよいので、採番が後戻りしないことを保証する
ことができる。従って、このような処理を行なうことに
より、この採番機構による通番は飛び出ることはあって
も、重複をなくすことができる。

【００３２】このように、本実施の形態では、順序番号
をメモリと不揮発性媒体上のファイルに保持し、業務プ
ログラムからの採番命令呼び出しによりメモリ上の順序
番号をカウント・アップして業務プログラムに返し、計
算機全体で既定値または定義により与えられた回数Ｎ回
に一度は最新の順序番号をファイルに書き出し、トラン
ザクションのロールバックでも戻されず、かつ採番後コ
ミットまでの間ロックされることもない採番のプログラ
ムインターフェース機構を設けたため、要求があってア
プリケーションに返るまではロックされているが、この
後コミットまではこの採番を自由に使用することができ
る。このため、他のトランザクションが来てもカウント
アップして使用することができる。

【００３３】本実施の形態は、メモリの情報が失われる
システム障害の発生後にファイルに残った順序番号＋Ｎ
以上の順序番号を復元することにより、仮に障害が発生
しても、業務プログラムに最後に返した順序番号より大
きい順序番号から採番を再開させる採番回復機構を設け
たため、ファイルに残った方から回復することによっ
て、例えば採番１９を返した時にクラッシュが起こって
も、採番２０番以上から返すので、重複なく採番を得る
ことができる。

【００３４】本実施の形態によれば、ユーザが各トラン
ザクションの識別情報を得たい場合に、データベースや
ファイルを用いることなく、また、重複なく採番を得る
ことができる。また、図２のフローチャートから明らか
なように、このような採番が処理のシリアライズのため
に行なうロックは採番する間だけであり、データベース
を使った場合のように、ロックがコミットまで保持され
ることがないようにできる。しかも、Ｉ／Ｏはトランザ
クションＮ件に１度であるため、システムの可用性を向
上させることができる。

【００３５】実施の形態２．本実施の形態は、２つの計
算機間に渡る分散トランザクション処理システムでのデ
ータ整合性確認機構であり、一方のサイトで端末から受
けた注文情報に対して注文番号を採番し、この採番した
注文番号をキーとして注文データをサイトＡの注文デー
タベース（マスタ）に書き込むとともに、ＲＰＣ（Ｒｅ
ｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）ｐ１により
サイトＢの注文データベース（レプリカ）に書き込むト
ランザクションへの適用例である。サイトＢのシステム
のクラッシュ後、データの整合性がどのように確認され
るかについて、以下、図面を参照しながら本実施の形態
を説明する。

【００３６】図４は本発明に係る実施の形態２の分散ト
ランザクション処理システムの構成を示すブロック図で
ある。ここでは、ＲＰＣを用いて２つのサイトＡ、Ｂで
データベースを同期的に更新するシステムの例を示して
いる。図４において、１、２は計算機であり、３、４は
注文データベースであり、５、６はログ採取機構であ
り、７は採番機構である。８はアプリケーションであ
り、９は端末であり、１０、１１は注文レコードであ
る。各注文データベース３、４の注文レコード１０、１
１は、注文番号（Ｋｅｙ）をキーとし、注文情報（Ｄａ
ｔａ）をカラムとして持つ。サイトＡ側の計算機１に
は、注文データベース（マスタ）３、ログ採取機構５、
採番機構７、アプリケーション８等が設けられている。
サイトＢ側の計算機２には、採番機構が設けられておら
ず、注文データベース（レプリカ）４、ログ採取機構６
等が設けられている。本実施の形態では、サイトＡ側の
計算機１のアプリケーション８で更新する時、サイトＡ
側の注文データベース３とサイトＢ側の注文データベー
ス４を同期的に更新させる。サイトＡ側の更新を確定す
る時は、サイトＢ側の更新を確定させ、サイトＡ側の更
新を取り止める時は、サイトＢ側の更新を取り止めると
いう具合に、処理を同期的にコミット乃至ロールバック
に設定する。

【００３７】次に、図５は図４に示す分散トランザクシ
ョン処理システムのトランザクション処理フローを示す
フローチャートである。ここでは、ＲＰＣを用いて２つ
のサイトＡ、Ｂで各々のデータベース３、４を同期的に
更新するトランザクションの処理内容を示している。サ
イトＡ側の計算機１は、端末９から入力される注文情報
を受信すると（ステップＳ３１）、実施の形態１と同じ
採番を行ってその採番で注文番号を採取し（ステップＳ
３２）、この採取した注文番号をキーとしてサイトＡ側
の注文データベース３に注文情報を挿入する（ステップ
Ｓ３３）。サイトＡ側の計算機１は、サイトＡの注文デ
ータベース３に挿入した注文番号（Ｋｅｙ）と注文情報
（Ｄａｔａ）を引数としてサイトＢの計算機２へＲＰＣ
を行う（ステップＳ３４）。

【００３８】サイトＢ側の計算機２は、サイトＡ側の計
算機１から転送されるサイトＡ側と同じ注文番号をキー
としてサイトＢ側の注文データベース４に注文情報を挿
入し（ステップＳ３５）、呼び出し元のサイトＡ側の計
算機１へ制御を戻す（ステップＳ３６）。このように、
サイトＡ側の計算機１は、採番を行った注文番号と注文
情報で更新を行い、この更新を行った注文番号と注文情
報をサイトＢ側の計算機２へ送信する。サイトＢ側の計
算機２は、計算機１から送信される注文番号と注文情報
で更新を行う。

【００３９】サイトＡ側の計算機１は、ＲＰＣ終了後、
サイトＢ側の計算機２へプリペア要求情報を送信し（ス
テップＳ３７）、サイトＢ側の計算機２は、計算機１か
ら送信されるプリペア要求情報を受信すると、プリペア
を行い、サイトＡ側の計算機１へプリペア完了情報を送
信する（ステップＳ３８）。サイトＡ側の計算機１は、
計算機２から送信されるプリペア完了情報を受信する
と、コミットを行い、サイトＢ側の計算機２へコミット
要求情報を送信するとともに（ステップＳ３７）、端末
９へコミットを行った結果を送信する（ステップＳ３
９）。サイトＢ側の計算機２は、計算機１から送信され
るコミット要求情報を受信すると、コミットを行う（ス
テップＳ３８）。

【００４０】次に、図６、７は図４に示す分散トランザ
クション処理システムのサイトＡとサイトＢのデータの
整合性が確認される様子を示すシーケンス図である。図
６では、不整合のない場合のサイトＡ、Ｂの両サイトの
データの整合性が確認される様子を示しており、図７で
は、不整合のある場合のサイトＡ、Ｂの両サイトのデー
タの整合性が確認される様子を示している。図６に示す
ように、サイトＡ、Ｂのトランザクションは、端末９か
ら入力される注文情報に対して注文レコード１０、１１
を作成し、作成した注文レコード１０、１１を各注文デ
ータベース３、４に挿入処理する。

【００４１】各注文データベース３、４の構造は、図４
に示した通りである。まず、サイトＡのコーディネータ
側がロールバックされて不整合が起こらない場合を図６
を用いて説明し、次に、サイトＡのコーディネータ側が
コミットされて不整合が起こる場合を図７を用いて説明
する。

【００４２】サイトＡ側の計算機１は、端末９から送信
される入力情報’ＡＡＡ’に対して、実施の形態１の採
番機構を用いて注文番号’１０１’を採番する。この採
番を行った注文番号’１０１’をキーとし、端末９から
送信される入力情報’ＡＡＡ’を内容とする注文レコー
ド１０を作成して注文データベース３に書き出す。

【００４３】次に、サイトＡ側の計算機１は、サイトＢ
側の計算機２に対して、手続きｐ９をＲＰＣする。この
時、サイトＢの計算機２には、サイトＡ側の計算機１か
ら手続きｐ９を行うためのパラメータ、即ちサイトＡ側
で採番を行った注文番号（Ｋｅｙ）の’１０１’と、注
文情報（Ｄａｔａ）の’ＡＡＡ’が送信される。

【００４４】サイトＢ側の計算機２は、サイトＡ側の計
算機１から送信される注文番号と注文情報のパラメータ
を受信すると、この注文番号と注文情報のパラメータに
従って注文レコード１１を作成し、注文データベース４
に書き出し、制御をサイトＡ側の計算機１に戻す。サイ
トＡ側の計算機１は、コミット処理を行なうためにサイ
トＢ側の計算機２へプリペア要求情報を送信する。

【００４５】サイトＢ側の計算機２は、サイトＡ側の計
算機１から送信されるプリペア要求情報を受信すると、
サイトＢのログ採取機構６により注文番号を含めてプリ
ペア・ログを採取する。プリペア・ログの内容には、図
８に示すように、トランザクションＩＤを示すＴＩＤ
と、プリペア・ログを示すフラグを示すＰと、ＲＰＣ手
続き名と、ＲＰＣパラメータのＫｅｙ（注文番号；注文
データベースのキー）とＤａｔａ（注文情報）とが含ま
れる。

【００４６】サイトＢ側の計算機２は、このプリペア・
ログ採取後、レディー（準備完了）情報をサイトＡの計
算機１へ送信しないうちにシステム・クラッシュしたと
する。サイトＢ側の計算機２は、プリペア・ログ採取
後、サイトＡ側の計算機１からコミットまたはロールバ
ックの指示が来るのを待つ状態になっており、コミット
していいのか、あるいはロールバックしていいのかを自
分で決めることができない。サイトＢ側の計算機２は、
コミット／ロールバックの指示が来るのを待っている時
にシステム・クラッシュしたとする。

【００４７】サイトＡ側の計算機１は、サイトＢ側の計
算機２からレディー情報が送信されないため、タイムア
ウトを起こし、ロールバックされる。即ち、注文データ
ベース３への注文レコード１０のレコード書き出しは、
取り消さ、注文データベース３は、元に戻る。

【００４８】一方、サイトＢでは、障害原因解決後、シ
ステムの再起動が行われる。この例では、障害発生時に
プリペア状態だったトランザクションは、ヒューリステ
ィック決定によりロールバックされるものとする。

【００４９】次に、サイトＡとの通信路が復旧した後、
ヒューリスティック決定をしたトランザクションについ
て、整合性確認機構が以下に説明する図１０に示すフロ
ーチャートに従って処理を行なう。ここでは、ヒューリ
スティック決定を行ったトランザクションに対して整合
性確認をどのように行っているかを示している。整合性
確認機構は、該当するトランザクションの判断定義情報
を読み（ステップＳ４１）、読んだ判断定義情報に示さ
れたログ中の通番情報を読んだ後（ステップＳ４２）、
判断定義情報に示された相手データベースのログ中の通
番情報をキーに持つレコードを探す（ステップＳ４
３）。

【００５０】整合性確認機構は、図８、９に示すよう
に、まず、プリペア・ログ内の通番情報のキーを読み、
このキーに突き合わせた相手のデータベースを読みに行
く。図８は、確認機構としてプリペア・ログの内容を示
しており、当然ＲＰＣパラメータのキーの所に情報が入
っていないと、確認することができない。図９は、どれ
とどれを突き合わせればよいかの情報を示している。図
９に示すＲＰＣ１は、プリペア・ログ内のキーの情報を
相手のサイトＡの注文データベースの注文番号と突き合
わせる処理である。ヒューリスティック決定としては、
自分の側がロールバックされると示している。

【００５１】整合性確認機構は、相手のレコードを探し
てあった場合（ステップＳ４４）、こちらのヒューリス
ティック決定がコミットであるかを判断し、こちらのヒ
ューリスティック決定がコミットであると判断すると
（ステップＳ４５）、不整合はないと判定する。整合性
確認機構は、相手のレコードがあってこちらのヒューリ
スティック決定がロールバックであると判断すると（ス
テップＳ４４、４５）、不整合であると判定する。整合
性確認機構は、相手のレコードを探してなかった場合
（ステップＳ４４）、こちらのヒューリスティック決定
がコミットであるかを判断し、こちらのヒューリスティ
ック決定がコミットであると判断すると（ステップＳ４
６）、不整合であると判定する。整合性確認機構は、相
手のレコードがなくてこちらのヒューリスティック決定
がロールバックであると判断すると（ステップＳ４４、
４６）、不整合はないと判定する。

【００５２】この整合性確認機構は、まず、ログを確認
し、注文番号’１０１’を得る。これに対応するサイト
Ａの注文データベース３の同キーのレコードを探すが、
これは、ロールバックされていてないので、不整合は発
生していないことが検出される。ログ中のどのフィール
ドと、どのサイトのどのデータベースのレコードを比較
すべきかは、予め図９に示すようなトランザクション毎
の判断定義として、整合性確認機構に与えておく。

【００５３】サイトＡは、サイトＢがクラッシュする
と、サイトＢからレディーが通知されないので、ロール
バックされる。サイトＡのデータベース３は、ロールバ
ックするので、元に戻る。次のトランザクションは、ロ
ールバックしたからといって採番機構は後戻りはしない
ので、’１０２’から探す。’１０１’は、探してもな
い状態である。サイトＢは、その続きで立ち上がった時
に、ヒューリスティック決定により整合性が取れるかど
うか判らないが、とにかくロールバックと決めておき、
その後ログを見に行って’１０１’がインダウトである
ことが判る。要は、どっちに設定していい情報かが判ら
ない。それで、サイトＢは、どっちに設定すべきかを知
るために、サイトＡに問い合わせる。サイトＢの整合性
確認機構は、’１０１’を探してもないので、ロールバ
ックされていることが判る。

【００５４】同じ例で、今度は図７に示す通り、サイト
Ｂ側の計算機２は、システム・クラッシュがレディー通
知を送った直後に起こったとする。サイトＡ側の計算機
１では、計算機２からレディー通知が来るため、コミッ
トを実行し、’１０１’のレコード１０ができる。その
後、サイトＡ側の計算機１は、サイトＢ側の計算機２へ
コミット要求情報を送信するが、サイトＢ側の計算機２
は、クラッシュしているので、このコミット要求は無視
される。一方、サイトＢ側の計算機２では、障害原因解
決後、システムの再起動が行われる。図６の場合と同
様、プリペア状態のトランザクションは、ヒューリステ
ィック決定によりロールバックされる。

【００５５】次に、サイトＡ側の計算機１との通信路が
復旧した後、ヒューリスティック決定したトランザクシ
ョンについて説明する。整合性確認機構は、ログを確認
し、図６と同様、注文番号’１０１’を得る。これに対
応するサイトＡ側の計算機１の注文データベース３の同
キーのレコードを探すが、今度はコミットされているの
で、不整合が発生していることが判る。以上の手順によ
り、システム・クラッシュ後、どのような場合も両サイ
トの整合性を確認することができる。

【００５６】このように、本実施の形態では、 分散ト
ランザクション処理において、コーディネータとなるト
ランザクションの分散ノードのサイトＡに設けた、実施
の形態１と同じ採番機構７による通番をキーとする注文
レコード１０を書き込む注文データベース３と、サブオ
ーディネートとなる分散ノードのサイトＢに設けた、同
通番を遅くともプリペア・ログの前にログに書き込むロ
グ採取機構６と、データ整合性確認の際に突き合わせる
べきデータの所在、判断方法を指定した整合性判断定義
と、障害時のヒューリスティック決定によるデータ不整
合を、インダウトのプリペア・ログはあるがコーディネ
ータの指示によるコミット／ロールバックがされていな
いトランザクションに対して、ログ中の通番に対応した
レコードがあるかを整合性判断定義情報に従って突き合
わせることにより、検出できて、ユーザがグローバル・
トランザクションＩＤを意識する必要のないデータ不整
合検出機構とを有するように構成している。このため、
２つの計算機１、２からなる分散システムでトランザク
ション処理を行う場合のシステム障害時のデータ整合性
確認において、ヒューリスティック・レポートやグロー
バルＩＤに頼ることなく整合性を確認することができ
る。また、従来、ヒューリスティック決定がされた後
に、ヒューリスティック・レポートを行うシステムで
は、ＩＤは判るが、業務と関係のないトランザクション
毎に振れられたＩＤであるので、業務的に確認すること
ができなかったが、このような問題も解消することがで
きる。

【００５７】実施の形態３．本実施の形態は、２つの計
算機間に渡る分散トランザクション処理システムでのト
ランザクション再実行機構であり、サイトＡで端末から
受けた注文情報に対して注文データを作成して、分散ト
ランザクション起動によりサイトＢの注文データベース
に書き込み、分散トランザクションの結果として支払い
情報をサイトＡで貰って伝票をプリントする処理への適
用例である。この分散トランザクション処理システムで
は、注文データベースは、サイトＢだけにあり、コミッ
トは、サイトＢだけで行われるものとする。以下、図面
を参照しながら本実施の形態を説明する。

【００５８】図１１は本発明に係る実施の形態３の分散
トランザクション処理システムの通常実行時の構成を示
すブロック図であり、図１２は本発明に係る実施の形態
３の分散トランザクション処理システムの再実行時の構
成を示すブロック図である。図１２に示す点線の部分
は、通常実行時には関与し、再実行時には関与しない部
分である。図１１、１２において、図４と同一符号は同
一又は相当部分を示し、２１、２２はトランザクション
であり、２３は再実行機構であり、２４、２５は管理端
末であり、２６はプリンタである。本実施の形態は、分
散トランザクション自体は同じであるが、サイトＡのト
ランザクション２１とサイトＢのトランザクション２２
で会話を行い、サイトＢの注文データベース４を更新し
て結果を貰ってプリンタ２６でプリントアウトする処理
を行う。この処理を行うのに、あるタイミングでサイト
Ｂがシステムクラッシュした時、即ち注文データベース
４の更新を終了した後にシステムクラッシュした時に、
サイトＡだけで処理を行う。

【００５９】次に、図１３は図１１に示す分散トランザ
クション処理システムのサイトＡのトランザクション２
１とサイトＢのトランザクション２２の通常実行での処
理フローを示すフローチャートである。ここでは、分散
トランザクションを用いてリモート・データベースを更
新するとともに、ローカルに帳票を出力するトランザク
ションの処理内容（通常実行時）を示している。サイト
Ａのトランザクション２１は、端末９から起動される
と、端末９から送信される注文情報を受信して端末受信
ログを採取した後（ステップＳ５１）、注文番号を採番
して採番ログを採取する（ステップＳ５２）。

【００６０】サイトＡのトランザクション２１は、採番
を行った注文番号（Ｋｅｙ）と注文情報（Ｄａｔａ）を
引数として起動してサイトＢのトランザクション２２へ
送信する（ステップＳ５３）。サイトＢのトランザクシ
ョン２２は、トランザクション２１から送信される注文
番号と注文情報を受信すると、受信した注文番号をキー
として注文データベース４に受信した注文情報を挿入し
て更新する（ステップＳ５４）。サイトＢのトランザク
ション２２は、注文データベースを更新すると、支払情
報を結果としてサイトＡのトランザクション２１へ送信
した後（ステップＳ５５）、ローカルにコミットする
（ステップＳ５６）。

【００６１】サイトＡのトランザクション２１は、トラ
ンザクション２２から送信される支払情報を受信すると
（ステップＳ５７）、終了通知をサイトＢのトランザク
ション２２へ送信する（ステップＳ５８）。サイトＢの
トランザクション２２は、トランザクション２１から送
信される終了通知を受信すると（ステップＳ５９）、正
常受信であるかを判定し、正常受信である場合（ステッ
プＳ６０）、終了し、正常受信でない場合（ステップＳ
６０）、管理端末２５にトランザクションＩＤを表示す
る（ステップＳ６１）。サイトＡのトランザクション２
１は、終了通知をサイトＡへ送信後、注文番号と支払情
報を含む帳票をプリンタ２６で出力した後（ステップＳ
６２）、端末９へ結果を送信する（ステップＳ６３）。

【００６２】次に、図１４は図１２に示す分散トランザ
クション処理システムのサイトＡでのローカル再実行処
理フローを示すフローチャートである。ここでは、分散
トランザクションを用いてリモート・データベースを更
新するとともに、ローカルに帳票を出力するトランザク
ションの処理内容（再実行時）を示している。ここで
は、サイトＡのシステムクラッシュで出力されないまま
になっていた帳票が、サイトＡでのトランザクション再
実行によって、サイトＢに影響を与えることなく出力さ
れる様子を、図１２も参照しながら説明する。図１１の
通常実行時には、前述したように、サイトＡのトランザ
クション２１は、業務端末９から起動され、サイトＢの
トランザクション２２を起動して処理結果をプリンタに
出力する。サイトＢのトランザクション２２を起動直後
にサイトＡでシステム・クラッシュが発生したとする。

【００６３】このように、サイトＢのトランザクション
２２を起動直後、サイトＡでシステム・クラッシュが発
生したとすると、サイトＢの終了通知受信は、異常終了
するため、サイトＢの管理端末２５に問題の発生したト
ランザクションＩＤが表示される。再実行時には、図１
２に示すように、管理端末２５からトランザクションＩ
Ｄによって再実行機構２３に対して起動が指示され、こ
れによって後述する図１４のフローに従ってサイトＡだ
けで処理が行われる。この場合、同トランザクション２
１、２２をそのまま再実行したのでは、サイトＢのデー
タベース４が二重に更新されてしまい、また、採番も取
り直される。

【００６４】そこで、図１３に示すように、通常実行時
に受信情報と採番情報をログに記録しておき、図１４に
示すように、再実行時にはこれらはログから読むものと
し、他の送信処理は、ＮＯＰとすれば、必要な帳票が正
しく出力され、サイトＢや端末９には影響を及ぼさな
い。サイトＡのトランザクション２１は、再実行時、端
末９からの起動を行うことなく、管理端末２５から再起
動要求があると、端末９からログに書いてある注文番号
を採取し（ステップＳ７１、Ｓ７２）、その採番を用い
てサイトＢ側に要求しなくてもよいので、ＮＯＰにして
（ステップＳ７３）、受信処理をログする（ステップＳ
７４）。その後、サイトＡのトランザクション２１は、
終了通知をＮＯＰにし（ステップＳ７５）、注文番号と
支払情報を含む帳票出力を実行した後（ステップＳ７
６）、結果送信をＮＯＰにして（ステップＳ７７）、終
了する。

【００６５】このように、本実施の形態では、分散トラ
ンザクション処理の１分散ノードであるプログラムを、
通常実行時には、受信処理及び実施の形態１による採番
処理は回復用ログに採取しつつ実行し、再実行時には、
そのプログラムまたはそれに対応する回復用プログラム
を、元のトランザクションＩＤ付きでローカルなトラン
ザクションとして再投入して、プログラムの受信処理以
外の通信処理をＮＯＰ化し、受信処理及び実施の形態１
による採番処理は、通常実行時にはログに書き出し、ト
ランザクションＩＤに基づいてはログからの読み出しに
より再現し、トランザクションとしてはローカルトラン
ザクションとして処理するプログラムインタフェース機
構を有するように構成している。このため、再実行時に
はこれらはログから読むものとし、他の送信処理はＮＯ
Ｐとすることにより、必要な帳票を正しく出力すること
ができるので、サイトＢや端末には影響を及ぼさないよ
うにすることができる。従って、複数の計算機１、２か
らなる分散システムで、複数のトランザクション２１、
２２で連携して処理を行う場合に、障害等で特定のトラ
ンザクション２１だけで再実行したい場合に、容易に再
実行することができる。

【００６６】実施の形態４．本実施の形態は、２つの計
算機間に渡る分散トランザクション処理システムであ
り、サイトＡで端末から受けた注文情報をサイトＡの注
文データベース（マスタ）に書き込むとともに、ＲＰＣ
ｐ１によりサイトＢの注文データベース（レプリカ）に
書き込むトランザクションへの適用例である。サイトＢ
のシステムクラッシュ後、データの整合性がどのように
回復されるかについて、以下、図面を参照しながら本実
施の形態を説明する。

【００６７】図１５は本発明に係る実施の形態４の分散
トランザクション処理システムの構成を示すブロック図
である。図１４において、図４、１１と同一符号は同一
又は相当部分を示し、３１は障害発生時に相手のサイト
Ａのトランザクション２１からのコミット／ロールバッ
ク決定待ちだったサイトＢのトランザクション２２を、
ひとまずローカルなヒューリスティック決定でコミット
／ロールバックするヒューリスティック決定機構であ
り、３２はプリペア・ログだけあって、コミット・ログ
もロールバック・ログもないトランザクションを回復候
補として抽出する回復候補トランザクション抽出機構で
ある。３３、３４はヒューリスティック決定によってコ
ミット／ロールバックされたサイトＢのトランザクショ
ン２２と、相手のサイトＡのトランザクション２１との
間のデータ整合性が崩れていないかどうかを、障害の復
旧後に確認するデータ整合性確認機構である。本実施の
形態の分散トランザクション処理システムは、ログ採取
機構５と、ヒューリスティック決定機構３１と、回復候
補トランザクション抽出機構３２と、あるトランザクシ
ョンが回復候補になった場合に、どのトランザクション
を投入すればいいかを示す投入指示情報と、データ整合
性確認機構３３、３４と、実施の形態３と同様のトラン
ザクション再実行機構２３とを有する。

【００６８】本実施の形態の分散トランザクション処理
システムは、以上のような構成要素からなり、特にサイ
トＢのトランザクション２２を起動する側のサイトＡの
トランザクション２１が２フェイズ・コミットの上でも
コーディネータになり、ヒューリスティック決定機構３
１でのヒューリスティック決定としてロールバックを行
なうもので、データ整合性確認機構３３としてヒューリ
スティック・レポートを備えており、トランザクション
再実行機構２３による再実行トランザクションとして、
サイトＢのトランザクション２２そのものを投入するこ
とにより、計算機１、２間に渡る障害の発生後、一時的
にプリペア状態のトランザクションをロールバックし、
後でサイトＢのトランザクション２２を必要に応じてロ
ーカル・トランザクションとして再投入して計算機１、
２間の整合性を回復するシステムである。実施の形態２
では、整合性確認までを行う場合を説明したが、本実施
の形態の分散トランザクション処理システムでは、整合
性確認を行った後、更に整合性を回復する処理を行うよ
うに構成している。

【００６９】次に、図１６は図１５に示す分散トランザ
クション処理システム上のトランザクション処理フロー
を示すフローチャートである。ここでは、ＲＰＣを用い
て２つのサイトＡ、Ｂで各々のデータベース３、４を同
期的に更新するトランザクションの処理内容を示してい
る。サイトＡ側のトランザクション２１は、端末９から
入力される注文情報を受信すると（ステップＳ８１）、
実施の形態１と同じ採番を行ってその採番で注文番号を
採取し（ステップＳ８２）、この採取した注文番号をキ
ーとしてサイトＡ側の注文データベース３に注文情報を
挿入する（ステップＳ８３）。

【００７０】サイトＡ側のトランザクション２１は、サ
イトＡの注文データベース３に挿入した注文番号（Ｋｅ
ｙ）と注文情報（Ｄａｔａ）を引数としてサイトＢのト
ランザクション２２へＲＰＣを行う（ステップＳ８
４）。サイトＢ側のトランザクション２２は、サイトＡ
側のトランザクション２１から転送されるサイトＡ側と
同じ注文番号をキーとしてサイトＢ側の注文データベー
ス４に注文情報を挿入し（ステップＳ８５）、呼び出し
元のサイトＡ側のトランザクション２１へ制御を戻す
（ステップＳ８６）。

【００７１】このように、サイトＡ側のトランザクショ
ン２１は、採番を行った注文番号と注文情報で更新を行
い、この更新を行った注文番号と注文情報をサイトＢ側
のトランザクション２２へ送信する。サイトＢ側のトラ
ンザクション２２は、トランザクション２１から送信さ
れる注文番号と注文情報で更新を行う。サイトＡ側のト
ランザクション２１は、ＲＰＣ終了後、サイトＢ側のト
ランザクション２２へプリペア要求情報を送信し（ステ
ップＳ８７）、サイトＢ側のトランザクション２２は、
トランザクション２１から送信されるプリペア要求情報
を受信すると、プリペアを行い、サイトＡ側のトランザ
クション２１へプリペア完了情報を送信する（ステップ
Ｓ８８）。

【００７２】サイトＡ側のトランザクション２１は、ト
ランザクション２２から送信されるプリペア完了情報を
受信すると、コミットを行い、サイトＢ側のトランザク
ション２２へコミット要求情報を送信するとともに（ス
テップＳ８７）、端末９へコミットを行った結果を送信
する（ステップＳ８９）。サイトＢ側のトランザクショ
ン２２は、トランザクション２１から送信されるコミッ
ト要求情報を受信すると、コミットを行う（ステップＳ
８８）。

【００７３】次に、図１７、１８は図１５に示す分散ト
ランザクション処理システムにより引き起こされる通信
とデータベースの変更の様子を示すシーケンス図であ
る。図１７、１８では、両サイトのデータの整合性が維
持される様子を示しており、図１７では、親のサイトＡ
がロールバックした場合に両サイト共ロールバックする
様子を示しており、図１８では、親のサイトＡがコミッ
トした場合に両サイト共コミットする様子を示してい
る。図１７に示すように、サイトＡ、Ｂのトランザクシ
ョン２１、２２は、端末９から入力される注文情報に対
して注文レコード１０、１１を作成し、作成した注文レ
コード１０、１１を各注文データベース３、４に挿入処
理する。

【００７４】各注文データベース３、４の構造は、図１
５に示した通りである。まず、サイトＡのコーディネー
タ側がロールバックされ両サイトＡ、Ｂがロールバック
されて整合性が維持される場合を図１７を用いて説明
し、次に、サイトＡのコーディネータ側がコミットされ
両サイトＡ、Ｂがコミットされて整合性が維持される場
合を図１８を用いて説明する。

【００７５】サイトＡ側の計算機１は、端末９から送信
される入力情報’ＡＡＡ’に対して、実施の形態１の採
番機構を用いて注文番号’１０１’を採番する。この採
番を行った注文番号’１０１’をキーとし、端末９から
送信される入力情報’ＡＡＡ’を内容とする注文レコー
ド１０を作成して注文データベース３に書き出す。

【００７６】次に、サイトＡ側の計算機１は、サイトＢ
側の計算機２に対して、手続きｐ１８をＲＰＣする。こ
の時、サイトＢの計算機２には、サイトＡ側の計算機１
から手続きを行うためのパラメータ、即ちサイトＡ側で
採番を行った注文番号（Ｋｅｙ）の’１０１’と、注文
情報（Ｄａｔａ）の’ＡＡＡ’が送信される。

【００７７】サイトＢ側の計算機２は、サイトＡ側の計
算機１から送信される注文番号と注文情報のパラメータ
を受信すると、この注文番号と注文情報のパラメータに
従って注文レコード１１を作成し、注文データベース４
に書き出し、制御をサイトＡ側の計算機１に戻す。サイ
トＡ側の計算機１は、コミット処理を行なうためにサイ
トＢ側の計算機２へプリペア要求情報を送信する。

【００７８】サイトＢ側の計算機２は、サイトＡ側の計
算機１から送信されるプリペア要求情報を受信すると、
サイトＢのログ採取機構６によりグローバル・トランザ
クションＩＤ（ＧＴＩＤ）と、受信情報としてＲＰＣの
パラメータを含めてプリペア・ログを採取する。プリペ
ア・ログの内容には、図１９に示すように、グローバル
・トランザクションＩＤを示すＧＴＩＤと、プリペア・
ログを示すフラグを示すＰと、ＲＰＣ手続き名と、ＲＰ
ＣパラメータのＫｅｙ（注文番号；注文データベースの
キー）と、Ｄａｔａ（注文情報）とが含まれる。

【００７９】サイトＢ側の計算機２は、このプリペア・
ログ採取後、図１７に示すように、レディー（準備完
了）情報をサイトＡの計算機１へ送信しないうちにシス
テム・クラッシュしたとする。サイトＢ側の計算機２
は、プリペア・ログ採取後、サイトＡ側の計算機１から
コミットまたはロールバックの指示が来るのを待つ状態
になっており、コミットしていいのか、あるいはロール
バックしていいのかを自分で決めることができない。サ
イトＢ側の計算機２は、コミット／ロールバックの指示
が来るのを待っている時にシステム・クラッシュしたと
する。

【００８０】サイトＡ側の計算機１は、サイトＢ側の計
算機２からレディー情報が送信されないため、タイムア
ウトを起こし、トランザクション２１がロールバックさ
れる。即ち、注文データベース３への注文レコード１０
のレコード書き出しは、取り消さ、注文データベース３
は、元に戻る。一方、サイトＢでは、障害原因解決後、
システムの再起動が行われる。この例では、障害発生時
にプリペア状態だったトランザクションは、ヒューリス
ティック決定機構３１によりロールバックされるものと
する。

【００８１】まず、回復候補トランザクション抽出機構
３２は、プリペア・ログだけあって、コミットもロール
バックもされていないトランザクションのプリペア・ロ
グを回復候補として抽出する。この時、グローバル・ト
ランザクションＧＴＩＤ＝ｉの手続きｐ１８のプリペア
・ログが該当するので抽出される。

【００８２】次に、サイトＡとの通信路が復旧した後、
ヒューリスティック・レポートによるサイトＡのデータ
整合性確認機構３３とサイトＢのデータ整合性確認機構
３４が交信して、グローバル・トランザクションＧＴＩ
Ｄ＝ｉの親トランザクション２１の状態を確認する。こ
の場合、上述した通り親もロールバックされているの
で、再投入は行われず、サイトＡ、サイトＢ共ロールバ
ックされた状態なので、データの整合性が維持される。

【００８３】同じ例で、今度は図１８に示す通り、サイ
トＢ側の計算機２は、システム・クラッシュがレディー
通知を送った直後に起こったとする。サイトＡ側の計算
機１では、計算機２からレディー通知が来るため、コミ
ットを実行し、’１０１’のレコード１０ができる。そ
の後、サイトＡ側の計算機１は、サイトＢ側の計算機２
へコミット要求情報を送信するが、サイトＢ側の計算機
２は、クラッシュしているので、このコミット要求は無
視される。

【００８４】一方、サイトＢ側の計算機２では、障害原
因解決後、システムの再起動が行われる。図１７の場合
と同様、プリペア状態のトランザクションは、ヒューリ
スティック決定機構３１によりロールバックされ、回復
候補トランザクション抽出機構３２により、手続きｐ１
８のプリペア・ログが抽出される。

【００８５】次に、サイトＡとの通信路が復旧した後、
サイトＢ側の計算機２は、ヒューリスティック・レポー
トによりサイトＡのデータ整合性確認機構３３とサイト
Ｂのデータ整合性確認機構３４が更新して、グローバル
・トランザクションＧＴＩＤ＝ｉの親トランザクション
２１の状態を確認する。今度は、上述した通り親のトラ
ンザクション２１は、コミットされているので、手続き
ｐ１８がトランザクション再実行機構２３によりローカ
ルトランザクションとして再投入される。手続きｐ１８
は、パラメータに従ってレコードを書き出すので、キ
ー’０１０１’、データ’ＡＡＡ’のレコードができ
る。これで両サイト共同じレコードができて整合性が維
持される。このように、本実施の形態では、プリペア状
態のデータがロールバックされ、回復候補トランザクシ
ョン抽出機構３２によりトランザクションをログから洗
い出し、再度投入するための情報を洗い出す。ヒューリ
スティック・レポートによる整合性確認機構３３、３４
により整合性確認を行い、整合性が一致している場合、
再起動を行わず、一方、整合性が一致していない場合、
再起動を行う。このため、整合性は、整合性が崩れてい
れば再投入するので、維持することができる。

【００８６】次に、図２０は図１７、１８に示す整合性
の確認と再投入の処理フローを示すフローチャートであ
る。回復候補トランザクション抽出機構３２は、再投入
候補トランザクションの中で未処置のものがあるかを判
定し、未処置のものがある場合（ステップＳ９１）、そ
の処置対象のトランザクションをＴとし（ステップＳ９
２）、一方、未処置のものがない場合（ステップＳ９
１）、ループを抜けて処理を終了する。データ整合性確
認機構３３、３４は、トランザクションＴに対してグロ
ーバル・トランザクションＧＴＩＤとヒューリスティッ
ク・レポートにより整合性が維持されているかを検査し
（ステップＳ９３）、整合性が崩れている場合（ステッ
プＳ９４）、トランザクションＴのＲＰＣ名とパラメー
タを設定する（ステップＳ９５）。

【００８７】データ整合性確認機構３３、３４は、整合
性が崩れていない場合（ステップＳ９４）、トランザク
ションＴを処地済みとして次のトランザクションのステ
ップＳ９１へ戻る（ステップＳ９６）。サイトＡ側のト
ランザクション２１は、ＲＰＣ名とパラメータ設定後、
サイトＢのトランザクション２２のＲＰＣを呼び出し
（ステップＳ９７）、サイトＢ側のトランザクション２
２は、サイトＡからＲＰＣの要求があると、各ＲＰＣの
処理を行い（ステップＳ９８）、呼び出し元のサイトＡ
のトランザクション２１へ制御を戻す（ステップＳ９
９）。サイトＡのトランザクション２１は、前述したサ
イトＢのトランザクション２２のＲＰＣの呼び出しを行
うとともに、サイトＢのトランザクション２２へコミッ
ト要求を行う（ステップＳ１００）。サイトＢのトラン
ザクション２２は、サイトＡからコミット要求を受ける
と、ローカルなコミット処理を行う（ステップＳ１０
１）。

【００８８】このように、本実施の形態では、サイトＢ
のトランザクション２２を起動する側の親のサイトＡの
トランザクション２１が２フェイズ・コミット上でコー
ディネータになり、ヒューリスティック決定機構３１で
のヒューリスティック決定としてロールバックを行なう
もので、データ整合性確認機構３３、３４としてヒュー
リスティック・レポートを備えており、トランザクショ
ン再実行機構２３による再実行トランザクションとし
て、元の子トランザクションそのものを投入することに
より、計算機１、２間に渡る障害の発生後、一時的にプ
リペア状態のトランザクションをロールバックし、後で
子トランザクションを必要に応じてローカル・トランザ
クションとして再投入して計算機１、２間の整合性を回
復するように構成している。このため、システム・クラ
ッシュ後どのような場合も両サイトの整合性を維持する
ことができる。

【００８９】本実施の形態では、複数の計算機１、２か
らなる分散システムでトランザクション処理を行なう場
合のうち、特に以下の（１）、（２）、（３）に該当す
る場合に、計算機１、２間に渡る障害発生時にシステム
が排他制御によってロックされることを回避しつつ、障
害復旧後にデータの整合性を回復する手段を提供するこ
とで、システムの可用性を高め運用を単純化しつつ、シ
ステムの信頼性を高めることができる。 （１）子トランザクション２１（起動される側）が２フ
ェイズ・コミットの上でコーディネータになる、（２）
結果が不明（ｉｎ−ｄｏｕｂｔ）のトランザクション
は、ヒューリスティック決定としてコミットを行なう方
が好ましい、（３）データ整合性確認機構３３、３４と
してヒューリスティック・レポートを備えている。

【００９０】なお、上記実施の形態４の分散トランザク
ション処理システムにおいて、実施の形態４で用いたデ
ータ整合性確認機構を実施の形態２で用いたデータ整合
性確認機構に変更して構成してもよい。その他の構成
は、実施の形態４と同じにする。この構成の場合も、ヒ
ューリスティック・レポートを備えていないシステムで
実施の形態４と同様の効果を得ることができる。

【００９１】実施の形態５．本実施の形態は、業務内容
とデータベース構成、ヒューリスティック決定がロール
バックであることは上記実施例４と同じであるが、コー
ディネータが起動する側の親トランザクション２１では
なく、起動される側の子トランザクション２２である例
である。

【００９２】図２１は本発明に係る実施の形態４の分散
トランザクション処理システムの構成を示すブロック図
である。図２１において、図１５と同一符号は同一又は
相当部分を示す。実施の形態４では、トランザクション
再実行機構２３と、ヒューリスティック決定機構３１
と、回復候補トランザクション抽出機構３２をサイトＢ
側の計算機２に設けた場合を説明したが、本実施の形態
では、トランザクション再実行機構２３と、ヒューリス
ティック決定機構３１と、回復候補トランザクション抽
出機構３２をサイトＡ側の計算機１に設けて構成してい
る。

【００９３】本実施の形態の分散トランザクション処理
システムは、特にサイトＡのトランザクション２１によ
って起動される側のサイトＢのトランザクション２２が
２フェイズ・コミットの上でコーディネータになり、ヒ
ューリスティック決定機構３１でのヒューリスティック
決定としてロールバックを行なうもので、データ整合性
確認機構３３としてヒューリスティック・レポートを備
えており、トランザクション再実行機構２３による再実
行トランザクションとして、サイトＡのトランザクショ
ン２１そのものを投入することにより、計算機１、２間
に渡る障害の発生後、一時的にプリペア状態のトランザ
クションをロールバックし、後でサイトＡのトランザク
ション２１を必要に応じてローカル・トランザクション
として再投入して計算機１、２間の整合性を回復するシ
ステムである。

【００９４】次に、図２２は図２１に示す分散トランザ
クション処理システム上のトランザクション処理フロー
を示すフローチャートである。実施の形態４の図１６と
異なり、コーディネータは、起動されたＲＰＣ側であ
る。ここでは、ＲＰＣを用いて２つのサイトＡ、Ｂで各
々のデータベース３、４を同期的に更新するトランザク
ションの処理内容を示している。サイトＡ側のトランザ
クション２１は、端末９から入力される注文情報を受信
すると（ステップＳ１１１）、実施の形態１と同じ採番
を行ってその採番で注文番号を採取し（ステップＳ１１
２）、この採取した注文番号をキーとしてサイトＡ側の
注文データベース３に注文情報を挿入する（ステップＳ
１１３）。

【００９５】サイトＡ側のトランザクション２１は、サ
イトＡの注文データベース３に挿入した注文番号（Ｋｅ
ｙ）と注文情報（Ｄａｔａ）を引数としてサイトＢのト
ランザクション２２へＲＰＣを行う（ステップＳ１１
４）。サイトＢ側のトランザクション２２は、サイトＡ
側のトランザクション２１から転送されるサイトＡ側と
同じ注文番号をキーとしてサイトＢ側の注文データベー
ス４に注文情報を挿入し（ステップＳ１１５）、呼び出
し元のサイトＡ側のトランザクション２１へ制御を戻す
（ステップＳ１１６）。

【００９６】このように、サイトＡ側のトランザクショ
ン２１は、採番を行った注文番号と注文情報で更新を行
い、この更新を行った注文番号と注文情報をサイトＢ側
のトランザクション２２へ送信する。サイトＢ側のトラ
ンザクション２２は、トランザクション２１から送信さ
れる注文番号と注文情報で更新を行う。サイトＡ側のト
ランザクション２１は、ＲＰＣ終了後、トランザクショ
ン終了情報をサイトＢ側のトランザクション２２へ送信
する（ステップＳ１１７）。

【００９７】コーディネータとなるサイトＢ側のトラン
ザクション２２は、トランザクション２１から送信され
るトランザクション終了情報を受信すると（ステップＳ
１１８）、サイトＡ側のトランザクション２１へプリペ
ア要求情報を送信し（ステップＳ１１９）、サイトＡ側
のトランザクション２１は、トランザクション２２から
送信されるプリペア要求情報を受信すると、プリペアを
行い、サイトＢ側のトランザクション２２へプリペア完
了情報を送信する（ステップＳ１２０）。

【００９８】サイトＢ側のトランザクション２２は、ト
ランザクション２１から送信されるプリペア完了情報を
受信すると、コミットを行い、サイトＡ側のトランザク
ション２１へコミット要求情報を送信する（ステップＳ
１１９）。サイトＡ側のトランザクション２１は、トラ
ンザクション２２から送信されるコミット要求情報を受
信すると、コミットを行い（ステップＳ１２０）、その
結果を端末９へ送信する（ステップＳ１２１）。

【００９９】次に、図２３は図２１に示す分散トランザ
クション処理システムのサイトＡとサイトＢのデータの
整合性が両サイトＡ、Ｂ共コミットされて維持されるて
いる様子を示すシーケンス図である。サイトＡのトラン
ザクション２１がサイトＢの手続きｐ２３をＲＰＣする
ところまでは、実施の形態４と同様とする。この後、サ
イトＢ側のトランザクション２２は、ＲＰＣ処理の終了
に伴って制御を呼び出し元のサイトＡのトランザクショ
ン２１へ戻し、その後、サイトＡのトランザクション２
１から送信されるトランザクション終了情報を受信する
と、プリペア要求情報をサイトＡのトランザクション２
１へ送信する。

【０１００】サイトＡのトランザクション２１は、レデ
ィー通知をサイトＢのトランザクション２２へ返し、サ
イトＢのトランザクション２２は、ローカル・コミット
を実行した直後、コミット指示をサイトＡのトランザク
ション２１へ返す前にサイトＢの計算機２がシステム・
クラッシュしたとする。

【０１０１】サイトＡ側のトランザクション２１は、サ
イトＢ側のトランザクション２２からコミット指示が来
ないため、サイトＢのコミット指示待ちがタイムアウト
した後、ヒューリスティック決定機構３１によりロール
バックされる。サイトＡのトランザクション２１は、回
復候補トランザクション抽出機構３２により回復候補と
して保持される。

【０１０２】一方、サイトＢでは、障害原因解決後、シ
ステムの再起動が行われる。この後、サイトＡとサイト
Ｂとの通信路が復旧した後、ヒューリスティック・レポ
ートによるサイトＡ、Ｂの整合性確認機構３３、３４に
よりサイトＡのトランザクション２１の状態を確認す
る。この場合、上述の通り、サイトＢのトランザクショ
ン２２は、コミットされているのにサイトＡではロール
バックされているので、不整合が発生しており、トラン
ザクション再実行機構２３によりトランザクション２１
が実行される。この際、後述する図２４のフローに示す
ように、サイトＡのトランザクション２１は、ローカル
なトランザクションとして実行される。以上の手順によ
り、本実施の形態では、システム・クラッシュ後も両サ
イトＡ、Ｂの整合性を維持することができる。

【０１０３】図２４は図２１に示す分散トランザクショ
ン処理システムのサイトＡのトランザクションの再実行
処理フローを示すフローチャートである。サイトＡのト
ランザクション２１は、端末９から送信される注文情報
を受信すると（ステップＳ１３１）、その注文情報を基
に採番を行い（ステップＳ１３２）、採番を行った注文
情報をキーとしてサイトＡの注文データベースに注文情
報を挿入する（ステップＳ１３３）。

【０１０４】サイトＡのトランザクション２１は、採番
を行った注文番号と注文情報を引数としてサイトＢのト
ランザクション２２へＲＰＣする。この時、サイトＡの
サイトＢへの呼び出しは、ＮＯＰとし、ＲＰＣの結果
は、ログから入力する。その後、サイトＡのトランザク
ション２１は、トランザクション終了情報をサイトＡの
トランザクション２１へ送信し（ステップＳ１３
５）、、ローカル・トランザクションとしてコミットし
た後（ステップＳ１３６）、端末９への結果送信をＮＯ
Ｐにする（ステップＳ１３７）。

【０１０５】このように、本実施の形態では、複数の計
算機１、２からなる分散システムでトランザクション処
理を行なう場合のうち、特に以下の（１）、（２）、
（３）に該当する場合に、計算機１、２間に渡る障害発
生時にシステムが排他制御によってロックされることを
回避しつつ、障害復旧後にデータの整合性を回復する手
段を提供することで、システムの可用性を高め運用を単
純化しつつ、システムの信頼性を高めることができる。 （１）サイトＡの親トランザクション２１により起動さ
れるサイトＢの子トランザクション２２が２フェイズ・
コミットの上でコーディネータになる、（２）結果が不
明（ｉｎ−ｄｏｕｂｔ）のトランザクションは、ヒュー
リスティック決定としてロールバックを行なう方が好ま
しい、（３）データ整合性確認機構３３、３４としてヒ
ューリスティック・レポートを備えている。

【０１０６】なお、上記実施の形態５の分散トランザク
ション処理システムにおいて、実施の形態５で用いたデ
ータ整合性確認機構を実施の形態２で用いたデータ整合
性確認機構に変更して構成してもよい。その他の構成
は、実施の形態５と同じにする。この構成の場合も、ヒ
ューリスティック・レポートを備えていないシステムで
実施の形態５と同様の効果を得ることができる。

【０１０７】実施の形態６．本実施の形態は、業務内容
とデータベース構成は、上記実施の形態４と同じである
が、障害発生時にプリペア状態だったトランザクション
は、実施の形態４とは逆に、ヒューリスティック決定に
よりひとまずコミットされる例である。図２５は本発明
に係る実施の形態６の分散トランザクション処理システ
ムの構成を示すブロック図である。図２５において、図
１５、２１と同一符号は同一又は相当部分を示す。本実
施の形態では、実施の形態４の構成に更にサイトＢ側に
投入指示情報が追加されている。

【０１０８】本実施の形態の分散トランザクション処理
システムは、特にサイトＢのトランザクション２２を起
動する側のサイトＡのトランザクション２１が２フェイ
ズ・コミットの上でコーディネータになり、ヒューリス
ティック決定機構３１でのヒューリスティック決定とし
てコミットを行なうもので、データ整合性確認機構３
３、３４としてヒューリスティック・レポートを備えて
おり、トランザクション再実行機構２３として実施の形
態３と同じものを備え、元のサイトＢのトランザクショ
ン２２に対応した回復用トランザクションを投入するこ
とにより、計算機１、２間に渡る障害の発生後、一時的
にプリペア状態のトランザクションをコミットし、後で
回復用トランザクションを必要に応じてローカル・トラ
ンザクションとして再投入して計算機１、２間の整合性
を回復するシステムである。本実施の形態の分散トラン
ザクション処理システム上のトランザクション処理フロ
ーは、実施の形態４の図１６と同様である。本実施の形
態では、更に図２７に示すキャンセル・トランザクショ
ンｑ２７を設ける。また、実施の形態４の構成に加え
て、図２７に示す投入指示情報を用いる。

【０１０９】図２６は図２５に示す分散トランザクショ
ン処理システムの取り消し手続きフローを示すフローチ
ャートである。サイトＢのトランザクション２２は、Ｋ
ｅｙをキーとして注文データベース４のレコードを削除
した後（ステップＳ１４１）、コミットする（ステップ
Ｓ１４２）。投入指示情報には、図２７に示すように、
元のトランザクション名（ＲＰＣ名）と、投入トランザ
クション名／ＲＰＣ名（パラメータ）と、パラメータの
対応の情報が書かれている。

【０１１０】次に、図２８は図２５に示す分散トランザ
クション処理システムのサイトＡとサイトＢのデータの
整合性が維持される様子を示すシーケンス図である。こ
こでは、両サイトＡ、Ｂがロールバックされる場合を説
明する。サイトＡのトランザクション２１がサイトＢの
手続きｐ１８をＲＰＣし、その後サイトＢでプリペア・
ログが採られるところまでは、実施の形態４と同様とす
る。この直後、図２８に示すように、サイトＢのトラン
ザクション２２がレディー（準備完了）通知をサイトＡ
のトランザクション２１へ送信しないうちにサイトＢの
計算機２がシステム・クラッシュしたとする。サイトＡ
のトランザクション２１がロールバックされるのは、実
施の形態４と同様である。

【０１１１】一方、サイトＢでは障害原因解決後、シス
テムの再起動が行われる。この例では、実施の形態４と
は逆に、障害発生時にプリペア状態だったトランザクシ
ョンは、ヒューリスティック決定機構３１によりコミッ
トされるものとする。まず、実施の形態４と同様、回復
候補トランザクション抽出機構３２により手続きｐ１の
プリペア・ログが抽出される。

【０１１２】次に、サイトＡとの通信路が復旧した後、
ヒューリスティック・レポートを得て、トランザクショ
ン再実行機構２３が、ＧＴＩＤ＝ｉの親トランザクショ
ンの状態を確認する。この場合、上述の通りサイトＡの
親トランザクション２１は、ロールバックされているの
に、サイトＢでは、コミットしてしまったので、不整合
である。ＪＢの投入指示情報には、図２７に示すよう
に、ｐ１８のＲＰＣ名に対するキャンセル・トランザク
ションｑ２７及びキャンセル・トランザクションｑ２７
のパラメータとＲＰＣ名のｐ１８のパラメータの関係が
定義してある。トランザクション再実行機構２３は、こ
れにより、キャンセル・トランザクションｑ２７の投入
を行う。キャンセル・トランザクションｑ２７は、ＲＰ
Ｃ名ｐ１８のパラメータを流用して、ｐ１８が行った処
理をキャンセルする。この場合、キー’０１０１’のレ
コードを削除する。これで両サイトＡ、Ｂ共キー’０１
０１’のレコードはない状態なので、データの整合性が
維持される。

【０１１３】コーディネータとなるサイトＡのトランザ
クション２２がコミット後にシステム・クラッシュが起
こった場合は、整合性確認の結果、両サイトＡ、Ｂの整
合性は、崩れていないことが判るので、キャンセル・ト
ランザクションｑ２７の投入は行われない。以上の手順
により、本実施の形態では、システム・クラッシュ後も
両サイトの整合性を維持することができる。

【０１１４】このように、本実施の形態では、複数の計
算機１、２からなる分散システムでトランザクション処
理を行なう場合のうち、特に以下の（１）、（２）、
（３）に該当する場合に、計算機１、２間に渡る障害発
生時にシステムが排他制御によってロックされることを
回避しつつ、障害復旧後にデータの整合性を回復する手
段を提供することで、システムの可用性を高め運用を単
純化しつつ、システムの信頼性を高めることができる。 （１）サイトＢのトランザクション２２を起動する側の
サイトＡのトランザクション２１が２フェイズ・コミッ
トの上でもコーディネータになる、（２）結果が不明
（ｉｎ−ｄｏｕｂｔ）のトランザクションは、ヒューリ
スティック決定としてコミットを行なう方が好ましい、
（３）データ整合性確認機構３３、３４としてヒューリ
スティック・レポートを備えている。

【０１１５】なお、上記実施の形態６の分散トランザク
ション処理システムにおいて、実施の形態６で用いたデ
ータ整合性確認機構を実施の形態２で用いたデータ整合
性確認機構に変更して構成してもよい。その他の構成
は、実施の形態６と同じにする。この例では、整合性確
認のための判断定義と、回復用トランザクションの定義
を、図２９に示すように、統合することができる。この
構成の場合も、ヒューリスティック・レポートを備えて
いないシステムで実施の形態６と同様の効果を得ること
ができる。

【０１１６】実施の形態７．本実施の形態は、業務内容
とデータベース構成は、上記実施の形態５と同じであ
り、ヒューリスティック決定での処置がコミットで、コ
ーディネータがサイトＡのトランザクション２１により
起動されるサイトＢのトランザクション２２である例で
ある。本実施の形態の分散トランザクション処理システ
ムの構成は、実施の形態５の図２５に示す構成と同様で
ある。

【０１１７】本実施の形態の分散トランザクション処理
システムは、特にサイトＡのトランザクション２１によ
り起動される側のサイトＢのトランザクション２２が２
フェイズ・コミットの上でコーディネータになり、ヒュ
ーリスティック決定機構３１でのヒューリスティック決
定としてコミットを行なうもので、データ整合性確認機
構３３、３４としてヒューリスティック・レポートを備
えており、トランザクション再実行機構２３として実施
の形態３と同じものを備え、元のサイトＡのトランザク
ション２１に対応した回復用トランザクションを投入す
ることにより、計算機１、２間に渡る障害の発生後、一
時的にプリペア状態のトランザクションをコミットし、
後で回復用トランザクションを必要に応じてローカル・
トランザクションとして再投入して、計算機１、２間の
整合性を回復するシステムである。本実施の形態の分散
トランザクション処理システム上のトランザクション処
理フローは、実施の形態５の図２２と同様である。本実
施の形態では、更に図３０に示すサイトＡのトランザク
ション２１に対して用いる回復用トランザクションＵＡ
３０を設ける。また、実施の形態４の構成に加えて、図
３１に示す投入指示情報を用いる。

【０１１８】図３０は本実施の形態の分散トランザクシ
ョン処理システムのサイトＡのトランザクションに対し
て用いる回復用トランザクションＵＡ３０の処理フロー
を示すフローチャートである。サイトＡのトランザクシ
ョン２１は、端末９から送信される注文情報を受信する
と（ステップＳ１５１）、注文番号のＫｅｙをキーとし
て注文データベース３のレコードを削除した後（ステッ
プＳ１５２）、ローカル・コミットする（ステップＳ１
５３）。投入指示情報には、図３１に示すように、元の
トランザクション名（ＲＰＣ名）と、投入トランザクシ
ョン名／ＲＰＣ名（パラメータ）と、起動情報の対応の
情報が書かれている。

【０１１９】本実施の形態では、実施の形態６と同様、
サイトＡのトランザクション２１により整合性が崩れて
いると判断すると、トランザクション再実行機構２３
は、図３１の投入指示情報を参照してトランザクション
２１に対応する回復用トランザクションＵＡ３０を投入
する。回復用トランザクションＵＡ３０は、図３０に示
すように、ローカル・トランザクションとして動作して
サイトＡのトランザクション２１の行った処理を打ち消
す。これにより、本実施の形態では、両サイトＡ、Ｂで
のデータ整合性を維持することができる。

【０１２０】このように、本実施の形態では、複数の計
算機１、２からなる分散システムでトランザクション処
理を行なう場合のうち、特に以下の（１）、（２）、
（３）に該当する場合に、計算機１、２間に渡る障害発
生時にシステムが排他制御によってロックされることを
回避しつつ障害復旧後にデータの整合性を回復する手段
を提供することで、システムの可用性を高め運用を単純
化しつつ、システムの信頼性を高めることができる。 （１）サイトＡのトランザクション２２により起動され
るサイトＢのトランザクション２２が２フェイズ・コミ
ットの上でコーディネータになる、（２）結果が不明
（ｉｎ−ｄｏｕｂｔ）のトランザクションは、ヒューリ
スティック決定としてコミットを行なう方が好ましい、
（３）データ整合性確認機構３３、３４としてヒューリ
スティック・レポートを備えいる。なお、上記実施の形
態７の分散トランザクション処理システムにおいて、実
施の形態７で用いたデータ整合性確認機構を実施の形態
２で用いたデータ整合性確認機構に変更して構成しても
よい。その他の構成は、実施の形態７と同じにする。こ
の構成の場合も、ヒューリスティック・レポートを備え
ていないシステムで実施の形態７と同様の効果を得るこ
とができる。

【０１２１】

【図面の簡単な説明】

【図１】 本発明に係る実施の形態１の採番機構のトラ
ンザクション処理フローを示すフローチャートである。

【図２】 本発明に係る実施の形態１の採番機構の処理
フローを示すフローチャートである。

【図３】 本発明に係る実施の形態１の採番機構の採番
の回復処理フローを示すフローチャートである。

【図４】 本発明に係る実施の形態２の分散トランザク
ション処理システムの構成を示すブロック図である。

【図５】 図４に示す分散トランザクション処理システ
ムのトランザクション処理フロー示すフローチャートで
ある。

【図６】 図４に示す分散トランザクション処理システ
ムのサイトＡとサイトＢのデータの整合性が確認される
様子を示すシーケンス図である。

【図７】 図４に示す分散トランザクション処理システ
ムのサイトＡとサイトＢのデータの整合性が確認される
様子を示すシーケンス図である。

【図８】 図４に示す分散トランザクション処理システ
ムで採取されるログの内容を示す図である。

【図９】 図４に示す分散トランザクション処理システ
ムの整合性確認機構が突き合わせるべき情報の所在を識
別するのに用いる整合性判断定義情報を示す図である。

【図１０】 図４に示す分散トランザクション処理シス
テムの整合性確認機構の処理フローを示すフローチャー
トである。

【図１１】 本発明に係る実施の形態３の分散トランザ
クション処理システムの通常実行時の構成を示すブロッ
ク図である。

【図１２】 本発明に係る実施の形態３の分散トランザ
クション処理システムの再実行時の構成を示すブロック
図である。

【図１３】 図１１に示す分散トランザクション処理シ
ステムのサイトＡ、Ｂのトランザクションの通常実行時
での処理フローを示すフローチャートである。

【図１４】 図１２に示す分散トランザクション処理シ
ステムのサイトＡでのローカル再実行処理フローを示す
フローチャートである。

【図１５】 本発明に係る実施の形態４の分散トランザ
クション処理システムの構成を示すブロック図である。

【図１６】 図１５に示す分散トランザクション処理シ
ステム上のトランザクション処理フローを示すフローチ
ャートである。

【図１７】 図１５に示す分散トランザクション処理シ
ステムにより引き起こされる通信とデータベースの変更
の様子を示すシーケンス図である。

【図１８】 図１５に示す分散トランザクション処理シ
ステムにより引き起こされる通信とデータベースの変更
の様子を示すシーケンス図である。

【図１９】 図１５に示す分散トランザクション処理シ
ステムにより採取されるプリペア・ログの内容を示す図
である。

【図２０】 図１７、１８に示す整合性の確認と再投入
の処理フローを示すフローチャートである。

【図２１】 本発明に係る実施の形態４の分散トランザ
クション処理システムの構成を示すブロック図である。

【図２２】 図２１に示す分散トランザクション処理シ
ステム上のトランザクション処理フローを示すフローチ
ャートである。

【図２３】 図２１に示す分散トランザクション処理シ
ステムのサイトＡ、Ｂのデータ整合性が両サイト共コミ
ットされて維持されている様子を示すシーケンス図であ
る。

【図２４】 図２１に示す分散トランザクション処理シ
ステムのサイトＡのトランザクションの再実行処理フロ
ーを示すフローチャートである。

【図２５】 本発明に係る実施の形態６の分散トランザ
クション処理システムの構成を示すブロック図である。

【図２６】 図２５に示す分散トランザクション処理シ
ステムの取り消し手続きフローを示すフローチャートで
ある。

【図２７】 図２５に示す分散トランザクション処理シ
ステムに使用される投入指示情報を示す図である。

【図２８】 図２５に示す分散トランザクション処理シ
ステムの両サイトＡ、Ｂのデータ整合性が維持される様
子を示すシーケンス図である。

【図２９】 整合性判断定義とマージされた投入指示情
報の内容を示す図である。

【図３０】 本発明に係る実施の形態７の分散トランザ
クション処理システムのサイトＡのトランザクションに
対して用いる回復用トランザクションの処理フローを示
すフローチャートである。

【図３１】 本発明に係る実施の形態７の分散トランザ
クション処理システムに用いられる投入指示情報の内容
を示す図である。

【図３２】 従来の分散トランザクション処理システム
の構成を示すブロック図である。

【図３３】 図３２に示す分散トランザクション処理シ
ステム上のサイトＡのトランザクション処理フローを示
すフローチャートである。

【図３４】 図３２に示す分散トランザクション処理シ
ステムによりサイトＡとサイトＢのデータ不整合が検出
される様子を示す図である。

【図３５】 従来の方法でユーザの通番自体がロールバ
ックされると整合性の検出ができなくなる様子を示す図
である。

【符号の説明】

１、２ 計算機、３、４ 注文データベース、５、６
ログ採取機構、７ 採番機構、８ アプリケーション、
９ 端末、１０、１１ 注文レコード、２１、２２ ト
ランザクション、２３ トランザクション再実行機構、
２４、２５ 管理端末、２６ プリンタ、３１ ヒュー
リスティック決定機構、３２ 回復候補トランザクショ
ン抽出機構、３３、３４ データ整合性確認機構。

Claims (11)

【特許請求の範囲】
1. 【請求項１】 順序番号をメモリとファイルに保持し、
   業務プログラムからの採番命令呼び出しによりメモリ上
   の順序番号をカウント・アップして業務プログラムに返
   し、計算機全体で既定値または定義により与えられた回
   数Ｎ回に一度は最新の順序番号を不揮発性媒体上のファ
   イルに書き出し、トランザクションのロールバックで戻
   されず、かつ採番後コミットまでの間ロックされること
   がない採番のプログラムインタフェース機構と、メモリ
   の情報が失われるシステム障害の発生後はファイルに残
   った順序番号＋Ｎ以上の順序番号を復元することによ
   り、仮に障害が発生しても、業務プログラムに最後に返
   した順序番号より大きい順序番号から採番を再開させる
   採番回復機構とを有することを特徴とする採番機構。
2. 【請求項２】 分散トランザクション処理において、コ
   ーディネータとなるトランザクションの分散ノードに設
   けた請求項１の採番機構による通番をキーとするレコー
   ドを書き込むデータベースと、サブオーディネートとな
   る分散ノードに設けた同通番を遅くともプリペア・ログ
   と同時にログに書き込むログ採取機構と、データ整合性
   確認の際に突き合わせるべきデータの所在、判断方法を
   指定した整合性判断定義と、障害時のヒューリスティッ
   ク決定によるデータ不整合を、インダウトのプリペア・
   ログはあるがコーディネータの指示によるコミット／ロ
   ールバックがされていないトランザクションに対して、
   ログ中の通番に対応したレコードがあるかを整合性判断
   定義情報に従って突き合わせることにより検出するデー
   タ不整合検出機構とを有することを特徴とするデータ整
   合性確認機構。
3. 【請求項３】 分散トランザクション処理の１分散ノー
   ドであるプログラムを、通常実行時には、受信処理及び
   請求項１による採番処理は回復用ログに採取しつつ実行
   し、再実行時には、そのプログラムまたはそれに対応す
   る回復用プログラムを、元のトランザクションＩＤ付き
   でローカルなトランザクションとして再投入して、プロ
   グラムの受信処理以外の通信処理をＮＯＰ化し、受信処
   理及び請求項１による採番処理は、通常実行時にはログ
   に書き出し、トランザクションＩＤに基づいてはログか
   らの読み出しにより再現し、トランザクションとしては
   ローカルトランザクションとして処理するプログラムイ
   ンタフェース機構を有することを特徴とするトランザク
   ション再実行機構。
4. 【請求項４】 以下のａ）〜ｆ）に示す構成要素からな
   り、子トランザクションを起動する側の親トランザクシ
   ョンが２フェイズ・コミット上でコーディネータにな
   り、ｂ）でのヒューリスティック決定としてロールバッ
   クを行なうもので、ｅ）のデータ整合性確認機構として
   ヒューリスティック・レポートを備えており、ｆ）のト
   ランザクション再実行機構による再実行トランザクショ
   ンとして、元の子トランザクションそのものを投入する
   ことにより、計算機間に渡る障害の発生後一時的にプリ
   ペア状態のトランザクションをロールバックし、後で子
   トランザクションを必要に応じてローカル・トランザク
   ションとして再投入して計算機間の整合性を回復するこ
   とを特徴とする分散トランザクション処理システム。 ａ）ログ採取機構、 ｂ）障害発生時に相手トランザクションからのコミット
   ／ロールバック決定待ちのトランザクションを、ローカ
   ルなヒューリスティック決定でコミット／ロールバック
   するヒューリスティック決定機構、 ｃ）プリペア・ログのみあって、コミット・ログ及びロ
   ールバック・ログがないトランザクションを回復候補と
   して抽出する回復候補トランザクション抽出機構、 ｄ）あるトランザクションが回復候補になった場合に、
   どのトランザクションを投入すればいいかを示す投入指
   示情報、 ｅ）ヒューリスティック決定によってコミット／ロール
   バックされたトランザクションと、相手トランザクショ
   ンとの間のデータ整合性が崩れていないかどうかを、障
   害の復旧後に確認するデータ整合性確認機構、 ｆ）請求項３のトランザクション再実行機構。
5. 【請求項５】 請求項４のａ）〜ｆ）に示す構成要素か
   らなり、子トランザクションが２フェイズ・コミット上
   でコーディネータになり、ｂ）でのヒューリスティック
   決定としてロールバックを行なうもので、ｅ）のデータ
   整合性確認機構としてヒューリスティック・レポートを
   備えており、ｆ）のトランザクション再実行機構による
   再実行トランザクションとして、元の親トランザクショ
   ンそのものを投入することにより、計算機間に渡る障害
   の発生後一時的にプリペア状態のトランザクションをロ
   ールバックし、後で親トランザクションを必要に応じて
   ローカル・トランザクションとして再投入して計算機間
   の整合性を回復することを特徴とする分散トランザクシ
   ョン処理システム。
6. 【請求項６】 請求項４のａ）〜ｆ）に示す構成要素か
   らなり、子トランザクションを起動する側の親トランザ
   クションが２フェイズ・コミット上でコーディネータに
   なり、ｂ）でのヒューリスティック決定としてコミット
   を行なうもので、ｅ）のデータ整合性確認機構としてヒ
   ューリスティック・レポートを備えており、ｆ）のトラ
   ンザクション再実行機構として請求項３を備え、元の子
   トランザクションに対応した回復用トランザクションを
   投入することにより、計算機間に渡る障害の発生後一時
   的にプリペア状態のトランザクションをコミットし、後
   で回復用トランザクションを必要に応じてローカル・ト
   ランザクションとして再投入して計算機間の整合性を回
   復することを特徴とする分散トランザクション処理シス
   テム。
7. 【請求項７】 請求項４のａ）〜ｆ）に示す構成要素か
   らなり、子トランザクションが２フェイズ・コミット上
   でコーディネータになり、ｂ）でのヒューリスティック
   決定としてコミットを行なうもので、ｅ）のデータ整合
   性確認機構としてヒューリスティック・レポートを備え
   ており、ｆ）のトランザクション再実行機構として請求
   項３を備え、元の親トランザクションに対応した回復用
   トランザクションを投入することにより、計算機間に渡
   る障害の発生後一時的にプリペア状態のトランザクショ
   ンをコミットし、後で回復用トランザクションを必要に
   応じてローカル・トランザクションとして再投入して計
   算機間の整合性を回復することを特徴とする分散トラン
   ザクション処理システム。
8. 【請求項８】 請求項４の分散トランザクション処理シ
   ステムにおいて、データ整合性確認機構は、請求項４の
   ｅ）のデータ整合性確認機構を請求項２のデータ整合性
   確認機構に変更したものであることを特徴とする分散ト
   ランザクション処理システム。
9. 【請求項９】 請求項５の分散トランザクション処理シ
   ステムにおいて、データ整合性確認機構は、請求項５の
   ｅ）のデータ整合性確認機構を請求項２のデータ整合性
   確認機構に変更したものであることを特徴とする分散ト
   ランザクション処理システム。
10. 【請求項１０】 請求項６の分散トランザクション処理
    システムにおいて、データ整合性確認機構は、請求項６
    のｅ）のデータ整合性確認機構を請求項２のデータ整合
    性確認機構に変更したものであることを特徴とする分散
    トランザクション処理システム。
11. 【請求項１１】 請求項７の分散トランザクション処理
    システムにおいて、データ整合性確認機構は、請求項７
    のｅ）のデータ整合性確認機構を請求項２のデータ整合
    性確認機構に変更したものであることを特徴とする分散
    トランザクション処理システム。