JP5223457B2 - 分散トランザクションの２相コミットプロトコルにおけるインダウト状態の解決方法 - Google Patents

分散トランザクションの２相コミットプロトコルにおけるインダウト状態の解決方法 Download PDF

Info

Publication number
JP5223457B2
JP5223457B2 JP2008134840A JP2008134840A JP5223457B2 JP 5223457 B2 JP5223457 B2 JP 5223457B2 JP 2008134840 A JP2008134840 A JP 2008134840A JP 2008134840 A JP2008134840 A JP 2008134840A JP 5223457 B2 JP5223457 B2 JP 5223457B2
Authority
JP
Japan
Prior art keywords
log
commit
group
log group
participant
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2008134840A
Other languages
English (en)
Other versions
JP2009282790A (ja
Inventor
量 松村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2008134840A priority Critical patent/JP5223457B2/ja
Priority to US12/389,979 priority patent/US8185493B2/en
Publication of JP2009282790A publication Critical patent/JP2009282790A/ja
Priority to US13/466,558 priority patent/US8433676B2/en
Application granted granted Critical
Publication of JP5223457B2 publication Critical patent/JP5223457B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Description

本発明は、データベースの分散トランザクションに係り、特に、該分散トランザクションの２相コミットプロトコルにおけるインダウト状態の解決方法に関する。
コンピュータシステムにおいて、トランザクションは、複数の処理から構成される一連の処理手続と定義される。トランザクションの一形態として分散トランザクションがある。分散トランザクションでは、分散コンピュータシステムの各ノード上でトランザクションが実行される。例えば、複数のデータベースの更新も分散トランザクションの一形態がある。この場合、各データベースは、分散コンピュータシステムの各ノード（例えば、データベース管理システムを備えたデータベースサーバなど）に存在し、トランザクション処理において、各ノードが管理しているデータベースの更新が行われる。
分散トランザクションにおいても、単一のコンピュータシステムで実行されるトランザクションと同様に、原子性(atomicity)を保証する必要がある。原子性は、トランザクションは、完全に実行されるか、または、全く実行されないかのいずれかでなくてはならないという性質である。トランザクションの正常完了はコミットと呼ばれ、失敗はアボートと呼ばれる。
分散トランザクションにおいては、各コンピュータシステムは独立に障害を起こすため、原子性を保証することは、単一のコンピュータシステムで実行されるトランザクションに比べはるかに難しい。この困難性を解決するために、分散トランザクションでは、トランザクションのコミットに２相コミットプロトコル(two-phase commit protocol)を使用する。
分散トランザクションにおいては、トランザクションに関与するコンピュータシステムは、トランザクションがどこかでコミットされる前に、トランザクションにおける更新を不揮発性の記憶媒体に永続的に格納しなければならない。このような処理を事前に行うことで、トランザクションがコミットする前にシステムがダウンした場合でも、その障害復旧後に、トランザクションをコミットすることが可能になる。
２相コミットプロトコルでは、このように、分散トランザクションに関与する各コンピュータシステムが、その更新に関する情報やデータを、トランザクションがコミットする前に不揮発性記憶媒体に格納することで、原子性を保証するようにしている。
ここで、２相コミットプロトコルについて説明する。尚、以下では、２相コミットプロトコルを、単に、２相コミットと記載する場合もある。
２相コミットプロトコルにおいては、分散トランザクションに関与する複数のコンポーネント（例えば、データベース管理装置）を、１つの調整者(coordinator)とその他の参加者(participants)に分ける。２相コミットプロトコルは、以下のようにして行われる。
［第１相］
１）調整者は、各参加者に「準備要求」を送る。
２）調整者は、準備要求を送った全ての参加者からの応答を待つ。
３）調整者から準備要求を受け取った参加者は、「準備完了ログ」を記憶装置に書き込む。そして、「準備完了」または「拒否」を調整者に回答する。この回答は、一般に、「投票」と呼ばれる。
［第２相］
１）調整者は、全ての参加者からの投票結果を基に、「コミット」か「アボート」を決定し、「コミットログ」を記憶装置に書き込む。この場合、調整者は、全ての参加者から「準備完了」の投票を受け取った場合にのみ、「コミット」を決定する。
２）調整者は、上記決定結果（コミットまたはアボート）を全ての参加者に送る。
３）参加者は、上記決定結果を受け取ると、調整者に「完了」を返し、「トランザクション完了ログ」を記憶装置に書き込む。
ここで、上記第１相と第２相の間は、“インダウト(in doubt)状態”または“不明(uncertain)状態”の期間と呼ばれる。参加者は、投票を行う前ならいつでもアボートできるが、「準備完了」を送った後は、調整者から決定結果を受け取るまで、コミットもアボートもできない。これを守らなければ、原子性が破綻する可能性があるからである。このように、インダウト状態の間は、参加者は、コミットしてよいのかアボートしてよいのか不明な期間である。参加者がインダウト状態である期間に、調整者がダウンすると、参加者はブロックされる。つまり、参加者は、コミットもアボートもできない状況におかれる。このように、２相コミットプロトコルは、参加者がインダウト状態のときにブロックされる可能性があるという問題を有している。
ところで、本出願人は、以前、データを記憶するデータ記憶装置毎に、そのデータのログ情報を記憶するログ記憶装置を持つような装置に関する発明を出願している（特許文献１参照）。なお、本明細書では、上記のデータ記憶装置とログ記憶装置をパッケージしたグループを“ロググループ”と呼ぶことにする。
このようなデータベース管理装置を複数備えた分散コンピュータシステムにおいて、分散トランザクションが実行された場合の２相コミットプロトコルにおけるインダウト状態期間の前後の処理を説明する。参加者は、調整者から準備要求のメッセージを受け取ると、「準備完了ログ」をログ記憶装置に書き込み、その後、調整者に「準備完了」のメッセージを送る。調整者は、全ての参加者から準備完了のメッセージを受け取ると、コミットもしくはアボートを決定し、「トランザクション完了ログ」をログ記憶装置に書き込む。その後、全ての参加者に上記決定結果を送る。
上記トランザクション完了ログと上記準備完了ログは、インダウト状態を解決するために、それぞれ、下記（１）、（２）の情報を格納している。
（１）トランザクションの最終結果の通知先（トランザクション完了ログ）
（２）トランザクションの最終結果の問い合せ先（準備完了ログ）
インダウト状態の期間中に参加者がダウンした場合、参加者がその障害から復旧したとき、ログ記憶装置には準備完了ログは書き込まれているがトランザクション完了ログ（コミットまたはアボートのログ）は書き込まれていない状態となっている。このため、参加者はブロックされる。このため、参加者は、ブロックされたトランザクションを解決すするために「終了プロトコル」を実行する。
終了プロトコルは、参加者が障害からの回復を行うときに、ブロックされたトランザクションの解決を試みるために参加者が実行する処理である。
終了プロトコルの一例においては、参加者は、調整者に再び投票を送る。参加者は、この投票を調整者に送るために、準備完了ログから「トランザクションの最終結果の通知先」を取得する。トランザクションの最終結果の通知先は、調整者の通信アドレス（例えば、ＩＰアドレス）となっているからである。
調整者は、参加者から上記投票を受け取ると、既にその参加者から投票を受け取っている場合には、参加者が投票結果を受け取っていないと判断して、参加者に再び投票結果を送る。調整者は、この投票結果を参加者に送るために、上記トランザクション完了ログから「トランザクションの最終結果の通知先」を取得する。このトランザクションの最終結果の通知先は、参加者の通信アドレスとなっているからである。
このように、従来は、上記トランザクション結果の通知先及びトランザクション結果の問い合せ先は、それぞれ、参加者と調整者の通信アドレスとなっていた。
ところで、分散トランザクションに関連する技術としては、２相コミット機能を持たないデータベース管理システムにおいて、擬似的な２相コミットを応用プログラムレベルで実現する発明が知られている（特許文献２参照）。
また、クラスタ構成の分散データベースには、Shared Nothing型とShared Disk型の２種類がある。Shared Nothing型の分散データベースは、データベース管理装置（データベースサーバ）がリソースを共有しない形態のシステムである。Shared Disk型の分散データベースは、複数のデータベース管理装置がリソースを共有する形態のシステムである。Shared Nothing型のクラスタシステムで分散トランザクションをサポートしているデータベースとしては、日立製作所株式会社のHiRDB、Microsoft CorporationのSQL Serverなどがある。また、米国のオラクル社は、Shared Disk型の分散データベースの分散トランザクションにおいて、２相コミット中にデータベース管理装置がダウンした場合の解決手法を提示している（非特許文献１参照）。
特開平６−３３７８１０号公報 特開昭６３−００８８４５号公報 オラクル社の上記解決手順が公開されているホームページのＵＲＬ(http://otndn.oracle.co.jp/document/products/oracle10e/102/doc cd/server.102/B19224-02/ds concepts.htm#685610）
上記従来のロググループを管理するデータベース管理装置を複数備える分散コンピュータシステムは、分散トランザクションを実行すると以下に述べるような問題が発生するという欠点があった。
（１）複数のロググループを更新するような分散トランザクションの実行中に、その分散トランザクションに参加している、あるデータベース管理装置がダウンし、そのデータベース管理装置が管理していたロググループの管理権が別のデータベース管理装置に移動した場合、分散トランザクションの復旧処理を行うことができなかった。ここで、管理権とは、ロググループの記憶装置に対するデータの参照／更新の権利のことである。
例えば、上記ダウンしたデータベース管理装置が調整者であり、かつ、そのダウンが
参加者がインダウト状態となっている期間中に発生した場合、参加者のログ記憶装置に記録されている準備完了ログに格納されている「トランザクションの最終結果の問い合せ先」は無効となる。何故ならば、そのトランザクションの最終結果の問い合せ先は、上記ダウンした調整者の通信アドレスなので、参加者が、その通信アドレスを用いて、トランザクションの最終結果を問い合せても、トランザクションの最終結果を受け取ることはできないからである。このため、参加者はインダウト状態を解決することが不可能となり、分散トランザクションの復旧が行えなかった。
また、上記ダウンしたデータベース管理装置が参加者であり、かつ、その参加者が調整者となっているデータベース管理装置に対して準備完了のメッセージを通知した後に、上記参加者がダウンしたとする。この場合、調整者のログ記憶装置に記録されているトラン
ザクション完了ログに格納されている「トランザクションの最終結果の通知先」は、そのダウンした参加者の通信アドレスとなっている。しかし、この通信アドレスは無効である。何故ならば、上記ダウンした参加者が管理していたロググループの管理権の移動先のデータベース管理装置の通信アドレスは、上記トランザクションの最終結果の通知先に格納されている通信アドレスではないからである。したがって、上記ロググループの管理権を引き継いだデータベース管理装置は、トランザクションの最終結果を知ることが不可能となり、インダウト状態を解決することができなくなる。
このように、従来は、ロググループを管理する、複数のデータベース管理装置から構成される分散データベースシステムにおいて、複数のロググループを更新するような分散トランザクションが実行された場合、２相コミットのインダウト状態期間中に、該分散トランザクションに参加しているデータベース管理装置がダウンすると、その分散トランザクションの復旧処理を行うことができないという問題があった。
（２）上記（１）の問題を解決したとしても、次のような問題が残る。
ロググループの管理権が移動する場合、いかなるログ記憶装置も持たないデータベース管理装置が生じる。例えば、記憶媒体障害などの理由により、自装置が管理していたロググループの管理権が別のデータベース管理装置に移動したデータベース管理装置は、ログ記憶装置を持たない状態となる。このようなロググループを持たないデータベース管理装置に対して、分散トランザクションを実行する更新アプリケーション（データを更新するアプリケーション）が接続し、該更新アプリケーションがコミットを行うと、該ロググループを持たないデータベース管理装置（調整者）は、分散トランザクションの最終結果（コミットまたはアボート）をログ記憶装置に記録できないため、２相コミットの実行中に、分散トランザクションに参加しているデータベース管理装置がダウンすると、分散トランザクションを復旧できない。例えば、調整者ダウンの場合に、参加者は該分散トランザクションの最終結果を問い合わせる先が存在しなくなるからである。このため、参加者はインダウト状態を解決できなくなり、分散トランザクションの復旧が不可能となる。
本発明の目的は、複数のロググループを更新するような分散トランザクションの２相コミットのインダウト状態期間中に、該複数のロググループに属するロググループの管理権が別のデータベース管理装置に移動しても、分散トランザクションを復旧できるようにすることである。
本発明は、データを記憶するデータ記憶装置と該データのログを記憶するログ記憶装置のパッケージであるロググループを備え、該ロググループの管理権がシステム内のデータベース管理装置間で移動可能な分散トランザクションシステムの２相コミットプロトコルにおけるインダウト状態の解決方法を前提とする。
本発明の方法は、
各ロググループに一意の識別子を付与し、各ロググループの管理権を持つデータベース管理装置に関する情報を第１のテーブルに登録するステップと、
複数のロググループが参加する分散トランザクションの２相コミットにおいて調整者となるデータベース管理装置が管理するロググループの中で代表となるロググループ（グローバル代表ロググループ）のログ記憶装置に出力される準備完了ログ（第１の準備完了ログ）に、該分散トランザクションの参加者となっているデータベース管理装置が管理するロググループの識別子のリスト（参加ロググループリスト）を記憶するステップと、
前記２相コミットにおいて参加者となるデータベース管理装置が管理するロググループのログ記憶装置に出力する準備完了ログ（第２の準備完了ログ）に、前記グローバル代表ロググループの識別子を記憶するするステップと、
２相コミットのインダウト状態期間中に、前記グローバル代表ロググループの管理権が別のデータベース管理装置に移動した場合に、該グローバル代表ロググループの管理権を該別のデータベース管理装置が持つように、前記第１のテーブルを書き換えるステップと、
２相コミットのインダウト状態期間中に、前記グローバル代表ロググループ以外のロググループの管理権が別のデータベース管理装置に移動した場合に、該ロググループの管理権を該別のデータベース管理装置が持つように前記第1のテーブルを書き換えるステップと、
インダウト状態となっている参加者は、前記第２の準備完了ログに記憶されているグローバル代表ロググループの識別子と前記第１のテーブルを参照して、該グローバル代表ロググループの管理権を持つデータベース管理装置に、トランザクション結果の問合せを送信するステップと、
前記調整者は、インダウト状態となっている参加者からトランザクション結果の問合せを受信した場合に、前記第１の準備完了ログに記憶されているロググループの識別子のリストと前記第１のテーブルを参照して、前記参加者に該トランザクション結果を返信するステップとを備える。
本発明によれば、複数のロググループが参加する分散トランザクションの２相コミットにおいて調整者となるデータベース管理装置が管理するロググループの中で代表となるロググループ（グローバル代表ロググループ）のログ記憶装置に出力される準備完了ログ（第１の準備完了ログ）に、該分散トランザクションの参加者となっているデータベース管理装置が管理するロググループの識別子のリスト（参加ロググループリスト）を記憶し、
前記２相コミットにおいて参加者となるデータベース管理装置が管理するロググループのログ記憶装置に出力する準備完了ログ（第２の準備完了ログ）に、前記グローバル代表ロググループの識別子を記憶するようにしたので、２相コミットのインダウト状態期間中にロググループの管理権が別のデータベース管理装置に移動する事態が発生しても、調整者と参加者は互いに通信可能となる。したがって、参加者はトランザクション結果の問合せを調整者に送信し、調整者は該参加者からのトランザクション結果の問合せに対して、トランザクション結果を返信することが可能となる。このため、２相コミットのインダウト期間中に、ロググループの管理権が別のデータベース管理装置に移動しても、インダウト状態となっているロググループを、インダウト状態から解決することができる。
開示の方法は、複数のロググループを更新するような分散トランザクションの２相コミットプロトコルの実行中に、あるデータベース管理装置が管理していたロググループの管理が別のデータベース管理装置に移動した場合でも、分散トランザクションを復旧することができるという効果を奏する。
以下、図面を参照しながら、本発明の実施形態を説明する。
［構成］
｛システム構成｝
図１と図２は、本発明を適用した実施形態の構成を示す図である。
｛分散トランザクションシステムの第１の形態｝
図１は、本発明を適用した分散トランザクションシステムの一形態を示す図である。
図１に示す分散トランザクションシステム１は、クラスタ管理装置１０、複数のデータベース管理装置１００（１００−１〜１００−ｎ）を備えている。クラスタ管理装置１０は、各データベース管理装置１００を管理する装置であり、各データベース管理装置１００と通信回線により接続されている。クラスタ管理装置１０は、各データベース管理装置１００に起動や停止を指示する機能や、各データベース管理装置１００の稼動状況を監視する機能を備えている。クラスタ管理装置１０は、ダウンしたデータベース管理装置１００を検知すると、そのダウンしたデータベース管理装置１００を他のデータベース管理装置１００に通知する。クラスタ管理装置１０は、上記各データベース管理装置１００に対する指示や通知を、例えば、メッセージにより行う。
複数のデータベース管理装置１００はネットワーク（不図示）を介して相互接続されており、クラスタシステムを構成している。データベース管理装置１００は、例えば、データベース管理システムが実装されたデータベースサーバである。分散トランザクションシステム１においては、全てのデータベース管理装置１００は、１または複数のロググループ２００を備えている。また、各データベース管理装置１００は、管理権の優先順位定義ファイル３００を備える。
ロググループ２００は、ログ記憶装置２０１とデータ記憶装置２０２をパッケージングしたものである。データ記憶装置２０２は、分散トランザクションによりデータの更新が行われるデータベースを格納する記憶装置である。ログ記憶装置２０１は、データ記憶装置２０２に格納されているデータベースの更新ログを記録する記憶装置である。ロググループ２００内のデータ記憶装置２０２内のデータベースの復旧は、同一ロググループ内のログ記憶装置２０１に記録されているログを基にして行われる。このように、ロググループ２００内のログ記憶装置２０１とデータ記憶装置２０２は対になっている。データ記憶装置２０２とログ記憶装置２０１は、例えば、同一の外部記憶装置であってもかまわない。
データベース管理装置１００は、主記憶装置内に、ロググループ偏在表１１０を格納している。ロググループ偏在表１１０は、各ロググループ２００を現在管理しているデータベース管理装置１００を示す表である。データベース管理装置１００は、このロググループ偏在表１１０を参照することによって、システム内のロググループ２００が、現在、どのデータベース管理装置１００によって管理されているのかを知ることができる。このロググループ偏在表１１０は、システム内の全てのデータベース管理装置１００において共通である。このロググループ偏在表１１０は、管理権の優先順位定義ファイル３００の内容に基づき決定される。ロググループ偏在表１１０は、ロググループの管理権が別のデータ記憶装置２０２に移動する度に更新される。この更新は、管理権の優先順位定義ファイル３００の内容に基づいて行われる。
管理権の優先順位定義ファイル３００は、各ロググループ２００について、その管理権を持つデータ記憶装置２０２の優先順位を定義したファイルである。各ロググループ２００はいずれかのデータベース管理装置１００によって管理されるので、上記管理権は、いずれかのデータベース管理装置１００に帰属する。したがって、ロググループ２００の管理権の優先順位は、ロググループ２００が帰属するデータベース管理装置１００の優先順位と同義である。管理権の優先順位定義ファイル３００は、ロググループ２００とは別の不揮発性の記憶装置（不図示）に格納される。この管理権の優先順位定義ファイル３００は、システム内の全てのデータベース管理装置１００において共通である。
ロググループ偏在表１１０は、管理権の優先順位定義ファイル３００を、各データベース管理装置１００の外部記憶装置に同一の複製を配置し、それらを、各データベース管理装置１００のＤＢＭＳ(Database Management Syatem)プロセスが主記憶装置上に読み込むことで設定される。
各データベース管理装置１００は、クラスタ管理装置１０からダウンしたデータベース管理装置１００を通知されると、まず、ロググループ偏在表１１０を参照して、そのダウンしたデータベース管理装置１００が管理していたロググループ２００を調べる。そして
、そのダウンしたデータベース管理装置１００が管理していたロググループ２００を知ると、次に、管理権の優先順位定義ファイル３００を参照し、ダウンしたデータベース管理装置１００が管理していたロググループ２００を自分が管理する必要があるか調べる。この場合、自分が管理する必要があれば、ダウンしたデータベース管理装置１００が管理していたロググループ２００の管理を引き受ける。
以後の説明では、便宜上、データベース管理装置１００−１、１００−２、・・・、１００−ｎを、それぞれ、データベース管理装置１、２、・・・、ｎと表記する場合もある。各データベース管理装置１、２、・・・、ｎには、それぞれ、ＤＢＭＳ１、２、・・・、ｎという名称（装置名）が割り当てられている。こられの名称は、データベース管理装置ｉの通信アドレスを取得するために利用される。図示してはいないが、装置名ＤＢＭＳｉをデータベース管理装置ｉの通信アドレスに変換するためのテーブルがシステム内に設けられており、この変換テーブルを参照することで、装置名ＤＢＭＳｉを有するデータベース管理装置ｉの通信アドレスを取得することが可能になっている。また、以後の説明では、データベース管理装置をＤＢＭＳと呼ぶ場合もある。
また、システム立ち上げ時においてデータベース管理装置ｉ（ｉ＝１〜ｎ）により管理されるロググループ２００を、ロググループｉｋ（ｋ＝１〜ｍ）と表記することにする。本実施形態においては、各ロググループｉｋに一意の識別子Ｇｉｋを割り当てる。固有の識別子Ｇｉｋが割り当てられたロググループｉｋ内のログ記憶装置２０１とデータ記憶装置２０２は、それぞれ、ログ記憶装置ｉｋ、データ記憶装置ｉｋと表記される。また、以後の説明では、ロググループｉｋをＧｉｋと表記する場合もある。これは、例えば、アプリケーションが分散トランザクションにおけるデータ更新要求において、データを更新するロググループｉｋを識別子Ｇｉｋにより指定するからである。また、データベース管理装置間同士でのパケット通信においても、ロググループｉｋを識別子Ｇｉｋにより指定するからである。
図１に示すロググループ偏在表１１０のデータ構造を説明する。ロググループ偏在表１１０は、システム内の各ロググループｉｋ（ｉ＝１〜ｎ、ｋ＝１〜ｍ）を管理するＤＢＭＳｉに関する情報を、ロググループｉｋに割り当てられた識別子ＧｉｋとＤＢＭＳｉとの対応関係により記憶している表である。ロググループ偏在表１１０は、この対応関係を、例えば、リスト構造により記憶する。
次に、図１に示す管理権の優先順位定義ファイル３００のデータ構造について説明する。
管理権の優先順位定義ファイル３００は、各ロググループＧｉｋに対するＤＢＭＳの管理権の優先順位を定義している表である。ここで、管理権とは、ロググループｉｋを管理する権利である。管理権の優先順位定義ファイル３００は、各ロググループｉｋに割り当てられた識別子Ｇｉｋと各データベース管理装置ｉに割り当てられた装置名ＤＢＭＳｉを利用して、各ロググループｉｋに対するデータベース管理装置ｉの管理権の優先順位を定義している。図１に示す管理権の優先順位定義ファイル３００は、ロググループ１１に対するデータベース管理装置ｉの管理権の優先順位を、ロググループ１１に割り当てられた識別子Ｇ１１を用いて、ＤＢＭＳ１、ＤＢＭＳ２、・・・の順であると定義している。また、ロググループ２１に対するデータベース管理装置ｉの管理権の優先順位を、ロググループ２１に割り当てられた識別子Ｇ２１を用いて、ＤＢＭＳ２、ＤＢＭＳ３、・・・の順であると定義している。管理権の優先順位定義ファイル３００は、他のロググループｉｋに対するデータベース管理装置ｉの管理権の優先順位についても、同様な手法により定義している。
尚、図１に示す分散トランザクションシステム１においては、各ロググループＧｉｋが
備えるロググループ２００の個数は皆同一となっているが、個々のデータベース管理装置１００毎に、管理するロググループ２００の個数が異なっていてもよい。これは、図２に示す分散トランザクションシステムについても同様である。
｛分散トランザクションシステムの第２の形態｝
図２は、本発明を適用した分散トランザクションシステムの別の形態を示す図である。図２において、図１に示す構成要素と同一の構成要素には同じ符号を付与しており、これらの構成要素についての詳しい説明は省略する。
図２に示す分散トランザクションシステム２が分散トランザクションシステム１と異なるのは、データベース管理装置１００´（１００´−２）がロググループ２００を備えていないことである。このように、本発明は、ロググループが割り当てられていないデータベース管理装置を備える分散トランザクションシステムにも適用可能である。
データベース管理装置１００´（データベース管理装置２）は、主記憶装置にロググループ偏在表１１０を記憶している。これは、他のデータベース管理装置１００がダウンした場合、そのデータベース管理装置１００が管理していたロググループ２００の管理権がデータベース管理装置１００´（ＤＢＭＳ２）に移動する可能性があるからである。また、データベース管理装置１００´は、管理権の優先順位定義ファイル３００´も備える。
管理権の優先順位定義ファイル３００´は、図１に示す管理権の優先順位定義ファイル３００とは若干内容が異なる。これは、図１のデータベース管理装置２に相当するデータベース管理装置１００´が管理すべきロググループ２００を有していないからである。したがって、管理権の優先順位定義ファイル３００´は、ロググループ２１、２２に対するデータベース管理装置ｉの管理権の優先順位を定義していない。
｛データベース管理装置がダウンした場合のロググループの管理権の移動｝
図３は、データベース管理装置がダウンした場合のロググループの管理権の移動によるシステム構成の変化を示す図である。尚、図３において、図１に示す構成要素と同じ構成要素には同じ符号を付与している。また、ロググループを簡略化して示している。
図３に示す分散トランザクションシステム３は、図１に示す分散トランザクションシステム１が、３つのデータベース管理装置１、２、３を備えている場合に該当する。
分散トランザクションシステム３の初期状態においては、データベース管理装置１はロググループ１１（識別子Ｇ１１）、１２（識別子Ｇ１２）を管理し、データベース管理装置２はロググループ２１（識別子Ｇ２１）、２２（識別子Ｇ２２）を管理している。また、データベース管理装置３は、ロググループ３１（識別子Ｇ３１）、３２（識別子Ｇ３２）を管理している。このロググループ１１、１２、２１、２２、３１、３２に対するデータベース管理装置１、２、３の管理情報は、不図示の管理権の優先順位定義ファイル３００に定義されている。すなわち、分散トランザクションシステム３の初期状態においては、ロググループ１１、１２、２１、２２、３１、３２は、管理権の優先順位が最も高いデータベース管理装置ｉよって管理される。この管理状態は、データベース管理装置１〜３のいずれかがダウンするまで継続される。
データベース管理装置１が障害発生によりダウンすると、クラスタ管理装置１０は、その障害を検知し、データベース管理装置１のダウンを、データベース管理装置１の装置名ＤＢＭＳ１を用いて、データベース管理装置１以外の全てのデータベース管理装置１００に通知する。この場合、データベース管理装置２（装置名ＤＢＭＳ２）は、クラスタ管理装置１０からの上記通知を受け取ると、管理権の優先順位定義ファイル（不図示）を参照して、データベース管理装置１が管理していたロググループ１１（識別子Ｇ１１）の管理権を引き継ぐ。また、データベース管理装置３は、同様にして、データベース管理装置１が管理していたロググループ１２（識別子Ｇ１２）の管理権を引き継ぐ。データベース管理装置２は、ロググループ１１の管理権の引継ぎ処理が終了すると、そのロググループ１１の識別子Ｇ１１を用いて、「Ｇ１１の管理権の引継ぎ完了通知」をデータベース管理装置３に送信する。一方、データベース管理装置３は、ロググループ１２の管理権の引継ぎ処理が終了すると、そのロググループ１２の識別子Ｇ１２を用いて、「Ｇ１２の引継ぎ完了通知」をデータベース管理装置２に送信する。
データベース管理装置２とデータベース管理装置３は、上記通知を受け取ると、図２に示すように、ロググループ偏在表１１０´をロググループ偏在表１１０Ａに変更する。ロググループ偏在表１１０Ａには、ロググループ１１の管理権をデータベース管理装置２が保有し、ロググループ１２の管理権をデータベース管理装置３が保有する旨が、ロググループ１１の識別子Ｇ１１とロググループ１２の識別子Ｇ１２を用いて記述されている。
｛トランザクション完了ログ出力先の優先順位定義表｝
本実施形態の分散トランザクションシステム１または２において、各データベース管理装置ｉ（ｉ=１〜ｎ）は、図４に示すように、主記憶装置内に、トランザクション完了ログ出力先の優先順位定義表１２０を記憶している。このトランザクション完了ログ出力先の優先順位定義表１２０は、システム内の各ロググループｉｋ（ｉ＝１〜ｎ、ｋ＝１〜ｍ）の重要度を定義している表である。図４に示すトランザクション完了ログ出力先の優先順位定義表１２０においては、重要度の高いロググループｉｋから順に、その識別子Ｇｉｋが記述されている。このトランザクション完了ログ出力先の優先順位定義表１２０は、後述するように、調整者や参加者となったデータベース管理装置ｉが「ローカル代表ロググループ」などを決定するために用いられる。
トランザクション完了ログ出力先の優先順位定義ファイル３１０は、トランザクション完了ログ出力先の優先順位定義表１２０と全く同じものであり、外部記憶装置（不図示）に格納されているファイルである。データベース管理装置ｉは、外部記憶装置からトランザクション完了ログ出力先の優先順位定義ファイル３１０を読み出し、それを、トランザクション完了ログ出力先の優先順位定義表１２０として主記憶装置に記憶する。主記憶装置にトランザクション完了ログ出力先の優先順位定義表１２０を記憶するのは、処理を高速化するためである。
［動作］
次に、上記構成の分散トランザクションシステムの動作を説明する。
公知のように、分散トランザクションにおける２相コミット（２相コミットプロトコル）においては、データベース管理装置は１つの「調整者」とその他の「参加者」に分かれる。ソフトウェア処理の観点では、アプリケーションの接続先のプロセスを「調整者」と呼び、間接的な接続先のプロセスを「参加者」と呼ぶ。換言すると、分散トランザクションを開始するデータベース管理装置（のプロセス）が「調整者」であり、調整者からの要求を受けて該分散トランザクションに関与するデータベース管理装置（のプロセス）が「参加者」である。
図５は、分散トランザクションにおける調整者のデータ更新処理を示すフローチャートである。
調整者は、アプリケーションから要求待ちとなっているときに、アプリケーションから要求を受けると（ステップＳ１１）、その要求がセッションの終了指示であるかどうかを判別する（ステップＳ１２）。ステップＳ１２において、セッションの終了指示でない（データ更新指示である）と判別すると（ステップＳ１２、ＮＯ）ステップＳ１３に進み、セッションの終了指示であると判別するとステップＳ２４に進む。
ステップＳ１３においては、ロググループ偏在表１１０を参照して、データ更新のためには他のデータベース管理装置（ＤＢＭＳ）へのアクセスが必要であるか判断する。そして、他のＤＢＭＳへのアクセスが不必要であると判断すれば（ステップＳ１３、ＮＯ）、調整者の該当ロググループのデータ記憶装置２０２内のデータを更新する（ステップＳ１４）。そして、データを更新したロググループ（更新ロググループ）を後述する「更新ロググループリスト」に登録し（ステップＳ１５）、その更新ログを該当ロググループのログ記憶装置２０１に出力する（ステップＳ１６）。続いて、前記トランザクション完了ログ出力先の優先順位定義表１２０を参照して、前記更新ロググループリストに登録されているロググループ(更新ロググループ)の中から１個のロググループを選択する。そして、そのロググループを、後述する「ローカル代表ロググループ記憶表」に設定する（ステップＳ１７）。
ステップＳ１７において、ローカル代表ロググループ記憶表に設定される「ローカル代表ロググループ」として選択されるのは、更新ロググループリストに登録されているロググループの中で最も重要度が高いロググループである。また、ローカル代表ロググループ記憶表は、データベース管理装置ｉの主記憶装置内に設けられる。
一方、ステップＳ１３において、他のＤＢＭＳへのアクセスが必要であると判断すると（ステップＳ１３、ＹＥＳ）、後述する「参加者リスト」に、前記の他のＤＢＭＳを登録する（ステップＳ１８）。そして、前記の他の他のＤＢＭＳへデータ更新の依頼を送信する（ステップＳ１９）。その後、上記データ更新を依頼したＤＢＭＳから送信されてくるパケットを待ち、該パケットを上記ＤＢＭＳから受信する（ステップＳ２０）。このパケットには、「データ更新の処理結果（正常終了または異常終了）」や「ロググループの識別子Ｇｉｋ」が格納されている。
次に、上記受信パケットからロググループの識別子Ｇｉｋを取得し（ステップＳ２１）、その取得したロググループの識別子Ｇｉｋを前記参加者リストに関連付け（ステップＳ２２）、その後、ステップＳ２３に処理を進める。
ステップＳ２３においては、前記アプリケーションに処理結果（正常終了または異常終了）を通知する。
ステップＳ２３の処理が終了すると、ステップＳ１２に戻る。
このようにして、ステップＳ１２で、前記アプリケーションからセッションの終了指示があったと判断するまで、ステップＳ１３〜Ｓ２３の処理を繰り返し実行する。この繰り返し処理により、分散トランザクションにおけるデータ更新処理が実行され、各ロググループＧｉｋにおけるデータ更新の処理結果がアプリケーションに通知される。
ステップＳ１３において、前記アプリケーションからセッションの終了が指示されたと判断すると（ステップＳ１３、ＹＥＳ）、全ての参加者に対して「接続解除依頼」を送信する（ステップＳ２４）。そして、前記参加者リストを破棄し（ステップＳ２５）、その後、セッションの終了処理を行い（ステップＳ２６）、本フローチャートの処理を終了する。
図６は、分散トランザクションにおける参加者のデータ更新処理を示すフローチャートである。
参加者は、調整者からの要求を受信する（ステップＳ３１）。次に、その要求が「調整者との接続解除」であるか判断する（ステップＳ３２）。そして、調整者との接続解除でない（データ更新である）と判断すると（ステップＳ３２、ＮＯ）ステップＳ３３に進み、調整者との接続解除であると判断すると（ステップＳ３２、ＹＥＳ）ステップＳ３９に進む。
ステップＳ３３においては、要求されたロググループのデータ記憶装置２０２のデータを更新する。そして、該ロググループのログ記憶装置２０１に更新ログを出力する（ステップＳ３４）。続いて、上述した、図５のフローチャートのステップＳ１７の処理と同様にして、トランザクション完了ログ出力先の優先順位定義表１２０を参照して更新ロググループリストからロググループを１個選択し、そのロググループの識別子Ｇｉｋを通信パケットに設定する（ステップ３７）。続いて、上記選択したロググループの識別子Ｇｉｋをローカル代表ロググループ記憶表に設定する（ステップＳ３７）。そして、調整者へ処理結果（正常または異常）を通知し（ステップＳ３８）、ステップＳ３２に戻る。
このようにして、参加者は、調整者からデータ更新の要求を受信する毎に、ステップＳ３３〜Ｓ３８の処理を繰り返し実行し、ロググループのデータ更新とそのデータ更新のログの記録を行う。データ更新はロググループのデータ記憶装置２０２において行われ、更新ログはロググループのログ記憶装置２０１に記録される。また、調整者宛の通信パケットに後述する「ローカル代表ロググループ」となるロググループを設定し、その通信パケットを調整者に送信する。
ステップＳ３２において調整者から接続解除の要求があったと判断すると（ステップＳ３２、ＹＥＳ）、調整者との接続を解除し（ステップＳ３９）、本フローチャートの処理を終了する。
図７は、上述した図５及び図６のフローチャートに示す処理による、分散トランザクションシステムにおけるデータ更新処理の一例を示すシステム構成図である。
図７に示す分散トランザクションシステム４は、図１に示す分散トランザクションシステム１において、データベース管理装置のクラスタが３台のデータベース管理装置１、２、３から構成される場合に該等している。データベース管理装置１は２つのロググループ１１（識別子Ｇ１１）、１２（識別子Ｇ１２）を備え、データベース管理装置２は１つのロググループ２１（識別子Ｇ２１）を備えている。データベース管理装置３は、２つのロググループ３１（識別子Ｇ３１）、３２（識別子Ｇ３２）を備えている。
データベース管理装置１は、主記憶装置内に、ロググループ偏在表１１０、トランザクション完了ログ出力先の優先順位定義表１２０、更新ロググループリスト１３０（１３０−１）、ローカル代表ロググループ記憶表１４０（１４０−１）及び参加者リスト１５０を備えている。
更新ロググループリスト１３０は、分散トランザクションにおいて、データベース管理装置ｉ（ＤＢＭＳｉ）がデータを更新したロググループの一覧が登録されるリストである。更新ロググループリスト１３０は、分散トランザクションに関与（参加）する全てのデータベース管理装置ｉの主記憶装置内に作成される。
ローカル代表ロググループ記憶表１４０は、更新ロググループリスト１３０に登録されているロググループの中からトランザクション完了ログ出力先の優先順位定義表１２０に基づいて選択されるロググループ（ローカル代表ロググループ）を記憶する表である。ローカル代表ロググループ記憶表１４０も、分散トランザクションに関与する全てのデータベース管理装置ｉの主記憶装置内に作成される。
参加者リスト１５０は、分散トランザクションに関与した全てのデータベース管理装置ｉ（ＤＢＭＳｉ）の一覧が登録されるリストである。参加者リスト１５０は、調整者とな
るデータベース管理装置ｉの主記憶装置内に作成される。参加者リスト１５０に登録された各データベース管理装置ｉ（ＤＢＭＳｉ）には、各ＤＢＭＳｉで決定されたローカル代表ロググループが関連付けられる。
図７に示す分散トランザクションにおいて、アプリケーション４１０は、データベース管理装置１に対してＧ１１（ロググループ１１）、Ｇ１２（ロググループ１２）、Ｇ２１（ロググループ２１）、Ｇ３１（ロググループ３１）、Ｇ３２（ロググループ３２）のデータ更新を依頼する。したがって、この分散トランザクションにおいては、データベース管理装置１（ＤＢＭＳ１）が調整者となり、データベース管理装置２（ＤＢＭＳ２）、３（ＤＢＭＳ３）が参加者となる。
図７の分散トランザクションシステム４の状況を、図５、６のフローチャートを参照しながら説明する。
データベース管理装置１は、アプリケーション４１０からの要求を受け付けると、ロググループ１１、１２のデータを更新する（ステップＳ１２〜Ｓ１４）。そして、更新ロググループリスト１３０（１３０−１）に上記ロググループ１１、１２の識別子Ｇ１１、Ｇ１２を登録する（ステップＳ１５）。そして、更新ログを、ロググループ１１、１２のログ記憶装置２０１（不図示）に出力する（ステップＳ１６）。次に、トランザクション完了ログ出力先の優先順位定義表１２０を参照して、ロググループ１１（Ｇ１１）をローカル代表ロググループとして選択し、ロググループ１１の識別子Ｇ１１をローカル代表ロググループ記憶表１４０（１４０−１）に設定する（ステップＳ１７）。また、参加者リスト１５０にデータベース管理装置２、３の装置名ＤＢＭＳ２、ＤＢＭＳ３を登録する（ステップＳ１８）。そして、データベース管理装置２に対して、ロググループ２１（Ｇ２１）のデータ（更新対象のデータ）を指定した更新依頼パケット５０１を送信する（ステップＳ１９）。また、データベース管理装置３に対して、更新依頼パケット５０２、５０３を送信する（ステップＳ１９）。更新依頼パケット５０２にはロググループ３１（Ｇ３１）のデータが指定されており、更新依頼パケット５０３にはロググループ３２（Ｇ３２）のデータが指定されている。
データベース管理装置２は、データベース管理装置１から更新依頼パケット５０１を受信すると（ステップＳ３１）、ロググループ２１の指定データを更新する（ステップＳ３３）。そして、更新ロググループリスト１３０（１３０−２）にロググループ２１の識別子Ｇ２１を登録し（ステップＳ３４）、上記データの更新ログをロググループ２１のログ記憶装置２０１（不図示）に書き込む（ステップＳ３５）。次に、トランザクション完了ログ出力先の優先順位定義表１２０を参照して、ロググループ２１をローカル代表ロググループとして選択し、ロググループ２１の識別子Ｇ２１を、データベース管理装置１宛の更新応答パケット５５１に設定し、その更新応答パケット５５１をデータベース管理装置１に送信する（ステップＳ３６）。続いて、上記ローカル代表ロググループとして選択したロググループ２１の識別子Ｇ２１をローカル代表ロググループ記憶表１４０（１４０−２）に設定する（ステップＳ３７）。
データベース管理装置３は、データベース管理装置１から更新依頼パケット５０２、５０３を受信すると、各更新依頼パケット５０２、５０３について、上述したデータベース管理装置２と同様の処理を行う。これにより、更新ロググループリスト１３０（１３０−３）には、ロググループ３１、３２の識別子Ｇ３１、Ｇ３２が登録される（ステップＳ３４）。また、ローカル代表ロググループ記憶表１４０（１４０−３）には、トランザクション完了ログ出力先の優先順位定義表１２０に基づき、ロググループ３１の識別子Ｇ３１が設定される（ステップＳ３７）。また、データベース管理装置３は、更新応答パケット５５２、５５３をデータベース管理装置１に送信する（ステップＳ３６）。更新応答パケット５５２，５５３には、ローカル代表ロググループであるロググループ３１の識別子Ｇ３１が設定される。
データベース管理装置１は、データベース管理装置２から更新応答パケット５５１を受信すると（ステップＳ２０）、その更新応答パケット５５１からローカル代表ロググループの識別子Ｇ２１を取得し（ステップＳ２１）、その識別子Ｇ２１を、参加者リスト１５０のＤＢＭＳ２に関連付ける（ステップＳ２２）。データベース管理装置は、データベース管理装置３から更新応答パケット５５２、５５３を受信した場合にも、上述した更新応答パケット５５１を受信した場合と同様の処理を行う。これにより、参加者リスト１５０のＤＢＭＳ２にはローカル代表ロググループであるロググループ３１の識別子Ｇ３１が関連付けられる。
図８は、調整者となるデータベース管理装置がロググループを備えていない場合の分散トランザクションにおける処理を示すシステム構成図である。図８において、図７に示す構成要素と同じ構成要素には同じ符号を付与し、それらの構成要素の説明は省略する。
図８に示す分散トランザクションシステム５の場合には、データベース管理装置１がロググループを備えていないので、データベース管理装置１が受け付けるアプリケーションは、データベース管理装置２、３が備えるロググループに対してのみデータの更新を依頼する。図８に示すアプリケーション４１１は、データベース管理装置２が備えるロググループ２１（Ｇ２１）とデータベース管理装置３が備えるロググループ３１（Ｇ３１）、３２（Ｇ３２）に対するデータの更新を依頼している。この場合、調整者であるデータベース管理装置１（ＤＢＭＳ１）は、図５のフローチャートのステップＳ１３において、他のＤＢＭＳへのアクセスが必要であると判断し、ステップＳ１８〜Ｓ２２の処理のみを行い、ステップＳ１４〜Ｓ１７の処理は実行しない。このため、図８に示すように、データベース管理装置１の主記憶装置内に設けられた更新ロググループリスト１３０−１とローカル代表ロググループ記憶表１４０−１は空となる。換言すれば、データベース管理装置１はロググループを備えていないので、データを更新するロググループは存在しない。したがって、分散トランザクションが実行されても、更新ロググループリスト１３０−１に登録すべきロググループを持たない。このため、ローカル代表ロググループも持たない。換言すれば、更新ロググループリスト１３０−１とローカル代表ロググループ記憶表１４０−１は、後に行われる２相コミット処理において不要ということである。データベース管理装置２、３については、図７に示す分散トランザクションシステム４と同様の処理が行われる。したがって、データベース管理装置２、３の主記憶装置内には、図７に示す分散トランザクションシステム４と同様のリストや表が作成される。
｛２相コミット処理の全体フロー｝
図９は、本実施形態における２相コミット処理の全体の流れを示すフローチャートである。この２相コミット処理の全体の流れを説明する。
調整者は、アプリケーションからコミットの指示を受信すると（ステップＳ５１）、調整者の主記憶装置内の更新ロググループリストは空であるか判別する（ステップＳ５２）。そして、更新ロググループリストが空であれば「調整者でロググループの更新（データ更新）が有る場合の準備処理」をおこなう（ステップＳ５３）。このステップＳ５３の処理の詳細は後述する。
調整者は、ステップＳ５３の準備処理が終了すると、該準備処理が成功したか判断する（ステップＳ５４）。ここで、成功とは、全ての参加者が準備処理に成功し、「準備処理完了」のメッセージを調整者に回答することを意味する。
調整者は、上記準備処理が成功したと判断すると（ステップＳ５４、ＹEＳ）、「調整
者でロググループの更新がある場合のコミット処理」を行い（ステップＳ５５）、アプリケーションへ「コミット成功」を応答し（ステップＳ６１）、本フローチャートの処理を終了する。ステップＳ５５の処理の詳細は後述する。
一方、ステップＳ５４において、上記コミット処理が不成功であったと判断すると（ステップＳ５４、ＮＯ）、「調整者でロググループの更新が有る場合のロールバック処理を行い（ステップＳ５６）、アプリケーションに「コミット失敗」を応答し（ステップＳ５７）、本フローチャートの処理を終了する。ステップＳ５６の処理の詳細は後述する。
ステップＳ５１において、調整者の更新ロググループリストが空であると判断すると（ステップＳ５２、ＹＥＳ）、「調整者でロググループの更新が無い場合の準備処理」を行う（ステップＳ５８）。ステップＳ５８の処理の詳細は後述する。
調整者は、ステップＳ５８の準備処理が終了すると、該準備処理が成功したか判断し（ステップＳ５９）、その準備処理が成功したと判断すると（ステップＳ５９、ＹＥＳ）、「調整者でロググループの更新が無い場合のコミット処理」を行い（ステップＳ６０）、ステップＳ６１に移行する。このステップＳ６０のコミット処理の詳細は後述する。
一方、調整者は、ステップＳ５９で準備処理が失敗したと判断すると（ステップＳ５９、ＮＯ）、「調整者でロググループの更新が無い場合のロールバック処理」を行い（ステップＳ６２）、アプリケーションへ「コミット失敗」を応答し（ステップＳ６３）、本フローチャートの処理を終了する。ステップＳ６２のロールバック処理の詳細は後述する。
＜調整者で更新が有る場合の処理＞
｛調整者で更新が有る場合の調整者の準備処理｝
図１０は、調整者で更新が有る場合の調整者の準備処理を示すフローチャートである。このフローチャートに示す処理は、図９のステップＳ５３における調整者の処理に該等する。
調整者は、ローカル代表ロググループ記憶表に設定されているローカル代表ロググループ（ローカル代表ロググループの識別子Ｇｉｋ）を、グローバル代表ロググループ記憶表（後述）に設定する（ステップＳ７１）。次に、参加者リストの現在のエントリを参照し、参加者リストの終端であるか判断する（ステップＳ７２）。そして、参加者リストの終端でないと判断すると（ステップＳ７２、ＮＯ）、参加者リストの現在のエントリから「ＤＢＭＳｉ」を取り出し、それを主記憶装置に保存し、前記グローバル代表ロググループ定義表に設定されているグローバル代表ロググループの識別子Ｇｉｋを通信パケットに設定し（ステップＳ７３）、その通信パケットを、ステップＳ７３で参加者リストから取り出した「ＤＢＭＳｉ」という名称のデータベース管理装置ｉに送信することで、参加者であるデータベース管理装置ｉに「準備依頼」メッセージを送信する（ステップＳ７４）。
次に、調整者は、上記準備依頼メッセージの送信に失敗したか判断する（ステップＳ７５）。この送信失敗は、例えば、通信障害などが原因で発生する。調整者は、例えば、上記準備依頼メッセージを送信後、所定時間経過しても参加者から応答が無かった場合に送信失敗と判断する。
調整者は、ステップＳ７５において、送信失敗でないと判断すると（ステップＳ７５、ＮＯ）、参加者から応答の通信パケットを受信する（ステップＳ７６）。そして、その応答内容を基に、参加者の準備処理が失敗したか判断する（ステップＳ７７）。
調整者は、ステップＳ７５において「送信失敗」と判断するか（ステップＳ７５、ＹＥ
Ｓ）、または、ステップＳ７７において「準備処理失敗」と判断すると（ステップＳ７７、ＹＥＳ）、本フローチャートの処理を異常終了する。この異常終了は、図９のフローチャートのステップＳ５４において、「準備処理が不成功した」と判断される。
一方、調整者は、ステップＳ７７において、準備処理が成功したと判断すると（ステップＳ７７、ＮＯ）、ステップＳ７６で受信した通信パケットから、参加者が更新した全てのロググループの識別子を取得する（ステップＳ７８）。そして、該取得したロググループの識別子を参加者リストのＤＢＭＳｉに関連付ける（ステップＳ７９）。続いて、参加者リストのエントリを次のエントリに位置づけ（ステップＳ８０）、ステップＳ７２に戻る。
このようにして、ステップＳ７２において参加者リストの現在のエントリが参加者リストの終端であると判断するまで（ステップＳ７２、ＹＥＳ）、換言すれば、参加者リストに登録された全てのＤＢＭＳｉについて処理が終了するまで、ステップＳ７３〜ステップＳ８０の処理を繰り返す。以上の処理により、調整者は、分散トランザクションに参加（関与）している全ての参加者に「準備依頼」のメッセージを送り、それに対する参加者からの応答に対処する。
調整者は、ステップＳ７２において参加者リストの終端であると判断すると（ステップＳ７２、ＹＥＳ）、ステップＳ８１に移行する。すなわち、全ての参加者から「準備処理成功」の応答メッセージを受け取れば、ステップＳ８１に処理を進める。
調整者は、ステップＳ８１以降では、更新ロググループリストを基に、上述したステップＳ７２〜Ｓ８０と同様の処理を行う。
調整者は、まず、更新ロググループリストの現在のエントリが終端であるか判断し（ステップＳ８１）、終端でないと判断すれば（ステップＳ８１、ＮＯ）ステップＳ８２に進み、終端であると判断すれば（ステップＳ８１、ＹＥＳ）ステップＳ８７に進む。
調整者は、ステップＳ８２において、現在のエントリからロググループの識別子を取り出し、その識別子がグローバル代表ロググループの識別子であるか判断する。そして、グローバル代表ロググループの識別子でなければ（ステップＳ８２、ＮＯ）ステップＳ８３に進み、グローバル代表ロググループの識別子であれば（ステップＳ８２、ＹＥＳ）、ステップＳ８６に進む。
調整者は、ステップＳ８３においては、ステップＳ８２で取り出した識別子を有するロググループの「トランザクション準備処理」を行う。そして、該トランザクション準備処理が失敗したか判断し（ステップ８３ａ）、成功したと判断すれば（ステップＳ８３ａ、ＮＯ）ステップＳ８４に進み、失敗したと判断すれば（ステップＳ８３ａ、ＹＥＳ）本フローチャートの処理を異常終了する。この異常終了は、図９のステップＳ５４において「準備処理失敗」と判断される。
調整者は、ステップＳ８４において、前記グローバル代表ロググループ表から「グローバル代表ロググループ」を読み出し、それを設定した「準備完了ログ」を前記ロググループのログ記憶装置に出力する。
調整者は、次に、該準備完了ログの出力処理に失敗したか判断し（ステップＳ８５）。該出力処理に失敗したと判断すれば（ステップＳ８５、ＹＥＳ）、本フローチャートの処理を異常終了する。この異常終了は、図９のステップＳ５４において「準備処理失敗」と判断される。
一方、調整者は、ステップＳ８５において、前記ロググループの準備処理に成功したと判断すると（ステップＳ８５、ＮＯ）、更新ロググループリストの現在のエントリを次のエントリに位置づけ（ステップＳ８６）、ステップＳ８１に戻る。
以上のようにして、調整者は、ステップＳ８１において、更新ロググループリストの現在のエントリが更新ロググループリストの終端であると判断するまで（ステップＳ８１、ＹＥＳ）、すなわち、更新ロググループリストに登録されたグローバル代表ロググループ以外のロググループについてトランザクション準備処理が終了するまで、ステップＳ８１〜Ｓ８６の処理を繰り返す。このようにして、更新ロググループリストに登録されたグローバル代表ロググループ以外のロググループについてトランザクション準備処理が行われる。
調整者は、ステップＳ８７において、グローバル代表ロググループの「トランザクション準備処理」を行う。そして、該トランザクション準備処理が失敗したか判断し（ステップＳ８７ａ）、成功したと判断すれば（ステップＳ８７ａ、ＮＯ）ステップＳ８８に進み、失敗したと判断すれば（ステップＳ８７ａ、ＹＥＳ）本フローチャートの処理を異常終了する。
調整者は、ステップＳ８８において、分散トランザクションの２相コミットにおいて準備処理が行われた、グローバル代表ロググループ以外のロググループの識別子のリスト（参加ロググループリスト）が設定された準備完了ログを、グローバル代表ロググループのログ記憶装置に出力する。
次に、調整者は、該準備完了ログの出力処理が失敗したか判断し（ステップＳ８９）、該準備完了ログの出力処理が成功したと判断すると（ステップＳ８９、ＮＯ）、本フローチャートの処理を正常終了し、失敗したと判断すると（ステップＳ８９、ＹＥＳ）、本フローチャートの処理を異常終了する。該正常終了と該異常終了は、図９のステップＳ５４において、それぞれ、「準備処理成功」、「準備処理失敗」と判断される。
｛調整者で更新が有る場合の参加者の準備処理｝
図１１は、調整者でロググループの更新が有る場合の参加者の準備処理を示すフローチャートである。
参加者は、調整者から受信する通信パケット（準備依頼パケット）から「グローバル代表ロググループ識別子」を取り出し、それを主記憶装置内に生成されたグローバル代表ロググループ表（後述）に設定する（ステップＳ１０１）。次に、更新ロググループリストの現在のエントリが終端であるか判断し（ステップＳ１０２）、終端でなければ（ステップＳ１０２、ＮＯ）ステップＳ１０３に進み、終端であれば（ステップＳ１０２、ＹＥＳ）ステップＳ１０９に進む。ステップＳ１０２の判断は、更新ロググループリストに登録されている全てのロググループについてステップＳ１０３以降の処理を終了したか判断する処理である。
参加者は、ステップＳ１０３において、更新ロググループリストの現在のエントリからロググループを取り出し、そのロググループのトランザクション準備処理を行う。次に、該トランザクション準備処理が失敗したか判断し（ステップＳ１０４）、成功したと判断すれば（ステップＳ１０４、ＮＯ）ステップＳ１０５に進み、失敗したと判断すれば（ステップＳ１０４、ＹＥＳ）ステップＳ１０９に進む。
参加者は、ステップＳ１０５において、「前記グローバル代表ロググループ表に設定されているグローバル代表ロググループ識別子を設定した準備完了ログ」を、ステップＳ１
０３で取り出したロググループのログ記憶装置に出力する（ステップＳ１０５）。その後、該準備完了ログの出力処理に失敗したか判断し（ステップＳ１０６）、その出力処理が成功であったと判断すれば（ステップＳ１０６、ＮＯ）、ステップＳ１０７に進み、失敗したと判断すれば（ステップＳ１０６、ＹＥＳ）ステップＳ１０９に進む。
参加者は、ステップＳ１０７において、前記ロググループをインダウト状態リスト（後述）に登録する。そして、更新ロググループリストの現在のエントリを次のエントリに位置づけ（ステップＳ１０８）、ステップＳ１０２に戻る。
このようにして、参加者は、ステップＳ１０２〜Ｓ１０８の処理を、「トランザクション準備処理」または「準備完了ログの出力処理」に失敗しないかぎり、ステップＳ１０２において更新ロググループリストの現在のエントリが終端であると判断するまで繰り返す。
これにより、更新ロググループリストに登録されている全てのロググループについて、「トランザクション準備処理」と「準備完了ログの出力処理」の両方が終了すると、参加者のトランザクション準備処理は成功となる。この場合、インダウト状態リストには、更新ロググループリストに登録されている全てのロググループの識別子が登録される。一方、更新ロググループリストに登録されているいずれか一つのロググループについて、「トランザクション準備処理」または「準備完了ログの出力処理」が失敗すると、参加者のトランザクション準備処理は失敗となる。この場合、トランザクション準備処理は失敗となる。
ステップＳ１０２、ステップＳ１０４またはステップ１０６でＹＥＳと判断されると、処理はステップＳ１０９に移る。
参加者は、ステップＳ１０９において、「トランザクション準備処理が行われた全てのロググループの識別子」と「該トランザクション準備処理の処理結果」を通信パケット（準備応答パケット）に設定し（ステップＳ１０９）、その準備応答パケットを調整者に送信し（ステップＳ１１０）、本フローチャートの処理を終了する。該準備応答パケットは、図１０のステップＳ７６において調整者に受信される。
このようにして、参加者は、更新ロググループリストに登録されている全てのロググループについてトランザクション準備処理を実施する。そして、該全てのロググループについてトランザクション準備処理が成功した場合（参加者がトランザクション準備処理に成功した場合）には、それら全てのロググループの識別子をインダウト状態リストに登録する。この結果、参加者のインダウト状態リストには、インダウト状態にある全てのロググループの識別子が登録されることになる。
｛２相コミットのトランザクション準備処理が行われた場合のシステム構成｝
図１２は、図７に示す分散トランザクションシステムにおいて、２相コミットのトランザクション準備処理が行われた場合のシステムの構成状態を示す図である。図１２において、図７と同一の構成要素には同じ符号を付与している。
調整者であるデータベース管理装置１は、ローカル代表ロググループ記憶表１４０−１に設定されているローカル代表ロググループの識別子Ｇ１１を、主記憶装置内に生成されたグローバル代表ロググループ表１６０に「グローバル代表ロググループの識別子」として設定する（ステップＳ７１）。そして、参加者（データベース管理装置２、データベース管理装置３）に送信する通信パケット（準備依頼パケット）６０１、６０２に上記グローバル代表ロググループの識別子Ｇ１１を設定し（ステップＳ７３）、該準備依頼パケット６０１、６０２を、それぞれ、データベース管理装置２、３に送信する（ステップＳ７４）。
第１の参加者であるデータベース管理装置２は、前記準備依頼パケット６０１を受信すると、そのパケット６０１からグローバル代表ロググループ表を取り出し、それをグローバル代表ロググループ表１６０に設定する（ステップＳ１０１）。そして、更新ロググループリスト１３０−２に識別子Ｇ２１が設定されているロググループ２１のトランザクション準備処理を実施し、（ステップＳ１０３）、該トランザクション準備処理に成功すると、グローバル代表ロググループの識別子Ｇ１１を設定した準備完了ログ２２０−２１を、ロググループ２１に出力する（ステップＳ１０５）。この準備完了ログ２２０−２１の出力に成功すると、ロググループ２１の識別子Ｇ２１をインダウト状態リスト１７０（１７０−２）に登録する（ステップＳ１０７）。データベース管理装置２の場合、更新ロググループリスト１３０−２に登録されているロググループはロググループ２１のみなので、ロググループ２１の識別子Ｇ２１と処理結果を通信パケット（準備応答パケット）６５１に設定し、それを調整者（データベース管理装置１）に送信する（ステップＳ１１０）。
調整者（データベース管理装置１）は、上記準備応答パケット６５１を受信し（ステップＳ７６）、その準備応答パケット６５１から「処理結果」を取り出し、データベース管理装置２のトランザクション準備処理が成功したと判断すると（ステップＳ７７、ＮＯ）、準備応答パケット６５１からロググループ２１の識別子Ｇ２１を取得する（ステップＳ７８）。そして、その識別子Ｇ２１を、参加者リスト１５０のＤＢＭＳ２に関連付ける。
上記と同様な処理が、調整者（データベース管理装置１）と第２の参加者（データベース管理装置３）において行われる。これにより、データベース管理装置１からデータベース管理装置２へ準備依頼パケット６０２が送信される。データベース管理装置２は、該準備応答パケット６０２からグローバル代表ロググループの識別子Ｇ１１を取り出し、それを主記憶装置内のグローバル代表ロググループ１６０に設定する。そして、更新ロググループリスト１３０−３に識別子（Ｇ３１、Ｇ３２）が登録されているロググループ３１、３２についてトランザクション準備処理を実施し、該トランザクション準備処理の準備完了ログ２２０−３１、２２０−３２を、それぞれ、ロググループ３１、３２のログ記憶装置に出力する。そして、トランザクション準備処理と準備完了ログの出力に成功すると、ロググループ３１、３２の識別子Ｇ３１、Ｇ３２をインダウト状態リスト１７０（１７０−３）に登録する。そして、「ロググループ３１、３２の識別子Ｇ３１、Ｇ３２」と「トランザクション準備処理の処理結果」を設定した準備応答パケット６５２をデータベース管理装置１へ送信する。データベース管理装置１は、該準備応答パケット６５２を受信し、データベース管理装置３がトランザクション準備処理に成功したと判断すると、参加者リスト１５０のＤＢＭＳ３にロググループ３１、３２の識別子Ｇ３１、Ｇ３２を関連付ける。
調整者（データベース管理装置１）は、更新ロググループリスト１３０−１から、最初に、ロググループ１１の識別子Ｇ１１を読み出し、ロググループ１１がグローバル代表ロググループであると判断する（ステップＳ８２、ＹＥＳ）。そして、次に、更新ロググループリスト１３０−１からロググループ１２の識別子Ｇ１２を読み出し、ロググループ１２はグローバル代表ロググループでないと判断し（ステップＳ８２、ＮＯ）、ロググループ１１のトランザクション準備処理を実行する（ステップＳ８３）。次に、グローバル代表ロググループ１１の識別子Ｇ１１を設定した準備完了ログ２２０−１２をロググループ１２のログ記憶装置に出力する（ステップＳ８４）。調整者（データベース管理装置１）は、次に、グローバル代表ロググループであるロググループ１１のトランザクション準備処理を行い（ステップＳ８８）、トランザクション準備処理を行ったグローバル代表ロググループ（ロググループ１１）以外のロググループ（ロググループ１２、２１、３１、３２）の識別子Ｇ１２、Ｇ２１、Ｇ３１、Ｇ３２を設定した準備完了ログ２２０−１１を、ロググループ１１のログ記憶装置に出力する（ステップＳ８８）。ステップＳ８８における準備完了ログ２２０−１１に設定するロググループの識別子の抽出する処理では、更新ロググループリスト１３０−１、参加者リスト１５０を参照する。
ここで、グローバル代表ロググループ（この例では、ロググループ１１）のトランザクション準備処理の準備完了ログ２２０には、２相コミットのトランザクション準備処理に参加したロググループの識別子（但し、グローバル代表ロググループの識別子は除く）が「参加ロググループリスト」として設定される（ステップＳ８８）。また、グローバル代表ロググループ以外のトランザクション準備処理の準備完了ログ２２０には、グローバル代表ロググループの識別子が「問い合せ先」として設定される。
以上説明したように、本実施形態においては、調整者から参加者に送信される準備依頼パケットには、グローバル代表ロググループの識別子が設定される。また、参加者から調整者への回答（投票）である準備応答パケットには、参加者が更新（トランザクション準備処理）を行ったロググループの識別子が設定される。また、参加者のインダウト状態リスト１７０には、参加者により管理されている、インダウト状態となっているロググループの識別子が設定される。このインダウト状態リスト１７０は、後述するように、インダウト状態となっているロググループを、インダウト状態から解放するために利用される。尚、グローバル代表ロググループは、分散トランザクションにおいて更新された（トランザクション準備処理が行われた）ロググループの中から選択されるロググループである。グローバル代表ロググループには、調整者の役割を担うデータベース管理装置ｉのローカル代表ロググループが選択される。本実施形態においては、トランザクション完了ログ出力先の優先順位定義表１２０において、最も重要度が高く設定されているロググループがグローバル代表ロググループとなる。このグローバル代表ロググループは、分散トランザクションに参加する各データベース管理装置の主記憶装置内に設けられるグローバル代表ロググループ表１６０に設定される。換言すれば、グローバル代表ロググループ表１６０は、グローバル代表ロググループが設定される表である。
｛２相コミットのコミット処理｝
図１３は、調整者で更新がある場合の調整者のコミット処理を示すフローチャートである。
図１２を参照すれば分かるように、２相コミットの準備処理終了後には、調整者の参加者リスト１５０には、分散トランザクションに参加（関与）した参加者の一覧が登録されており、各参加者における更新ロググループ（更新が行われたロググループ）の一覧も登録されている。したがって、調整者は、２相コミットのコミット処理において、参加者にコミットを依頼する場合には、参加者リスト１５０を参照する。また、調整者が管理するロググループの中で、分散トランザクションにおいて更新がなされたロググループは更新ロググループリスト１３０に登録されている。
以上のような前提を理解した上で、図１３のフローチャートを説明する。
調整者は、参加者リストの現在のエントリが終端であるか判断し（ステップＳ１２１）、参加者リストの終端でなければ（ステップＳ１２１、ＮＯ）ステップＳ１２２に進み、参加者リストの終端であればステップＳ１２８に進む。参加者リストの現在のエントリが終端であるということは、参加者リストに登録されている全ての参加者についてコミット依頼の送信が終了しているということを意味する。
調整者は、ステップＳ１２２において、参加者リストの現在のエントリから参加者の名称（ＤＢＭＳｉ）を取り出し、その名称を有する参加者にコミット依頼（コミット依頼パ
ケット）を送信する。その後、該コミット依頼の送信に失敗したか判断し（ステップＳ１２３）、送信成功であると判断すれば（ステップＳ１２３、ＮＯ）ステップＳ１２４に進み、送信失敗であると判断すれば（ステップＳ１２３、ＹＥＳ）ステップＳ１２６に進む。
調整者は、ステップＳ１２４において、上記コミット依頼を送信した参加者からの応答（コミット応答パケット）を受信する。そして、そのコミット応答パケットに格納された処理結果を参照して、参加者がコミット処理に失敗したか判断する（ステップＳ１２５）。そして、参加者がコミット処理に失敗していれば（ステップＳ１２５、ＹＥＳ）ステップＳ１２６に進み、成功していれば（ステップＳ１２５、ＮＯ）ステップＳ１２７に進む。
調整者は、ステップＳ１２６において、参加者リストから上記コミット処理に失敗した参加者の全ての更新ロググループを取得し、該取得した更新ロググループを主記憶装置内のコミット再送信リスト（後述）に出力する。そしてステップＳ１２７に進む。
調整者は、ステップＳ１２７において、参加者リストの現在のエントリを次のエントリに位置づける。そして、ステップＳ１２１に戻る。
このようにして、調整者は、ステップＳ１２１において、参加者リストの現在のエントリが終端であると判断する（ステップＳ１２１、ＹＥＳ）まで、ステップＳ１２１〜Ｓ１２７の処理を繰り返す。以上の処理により、調整者は、参加者リストに登録されている全ての参加者に対してコミット依頼パケットを送信する。この場合、調整者は、コミット依頼パケットの送信に失敗するか、または、コミット処理に失敗した参加者については、その全ての更新ロググループをログ記憶装置内のコミット再送信リストに登録する。
調整者は、次に、自身が管理する更新ロググループのコミット処理に移る。
調整者は、ステップＳ１２８において、更新ロググループリストの現在のエントリが終端であるか判断する。そして、更新ロググループリストの終端であれば（ステップＳ１２８、ＹＥＳ）ステップＳ１３６に進み、更新ロググループリストの終端でなければ（ステップＳ１２９、ＮＯ）ステップＳ１２９に進む。
調整者は、ステップＳ１２９において、更新ロググループリストの現在のエントリがグローバル代表ロググループ（グローバル代表ロググループの識別子）であるか判断する。そして、グローバル代表ロググループでなければ（ステップＳ１２９、ＮＯ）ステップＳ１３０に進み、グローバル代表ロググループであれば（ステップＳ１２９、ＹＥＳ）ステップＳ１３５に進む。
調整者は、ステップＳ１３０において、更新ロググループリストの現在のエントリのロググループ（グローバル代表ロググループ以外のロググループ）のトランザクションコミット処理を行う。そして、そのトランザクションコミット処理に失敗したか判断し（ステップＳ１３１）、失敗すれば（ステップＳ１３１、ＹＥＳ）ステップＳ１３４に進み、失敗しなければ（ステップＳ１３１、ＮＯ）ステップＳ１３２に進む。
調整者は、ステップＳ１３２において、トランザクションコミット処理に成功したロググループのコミットログをログ記憶装置に出力する。そして、該コミットログの出力に失敗したか判断し（ステップＳ１３３）、失敗していれば（ステップＳ１３３、ＹＥＳ）ステップＳ１３４に進み、失敗していなければ（ステップＳ１３３、ＮＯ）ステップＳ１３５に進む。
調整者は、ステップＳ１３４において、上記トランザクションコミット処理に失敗した
ロググループを、主記憶装置内のコミット再送信リストに登録する。その後、ステップＳ１３５に進む。調整者は、ステップＳ１３５において、更新ロググループリストの現在のエントリを次のエントリに位置づける。そして、ステップＳ１２８に戻る。
このようにして、調整者は、ステップＳ１２８において、更新ロググループリストの現在のエントリが終端であると判断するまで、ステップＳ１２８〜Ｓ１３５の処理を繰り返す。以上の処理により、調整者の更新ロググループリストに登録されているグローバル代表ロググループ以外のロググループについてトランザクションコミット処理が実施される。この場合、コミット処理に失敗するか、または、コミット処理に成功してもコミットログの出力に失敗したロググループについては、その識別子が主記憶装置内の前記コミット再送信リストに登録される。つまり、これらのロググループはコミット処理が完了していないので、再度、コミット処理を行うために、主記憶装置内のコミット再送信リストに記録される。
調整者は、ステップＳ１３６において、前記コミット再送信リストが“空”であるか判断する。そして、前記コミット再送信リストが空でなければ（ステップＳ１３６、ＮＯ）、前記コミット再送信リストをグローバル代表ロググループのログ記憶装置に出力し（ステップＳ１３７）、ステップＳ１３８に進む。一方、ステップＳ１３６において、前記コミット再送信リストが空であると判断すれば（ステップＳ１３６、ＹＥＳ）、ステップＳ１３８に進む。
このようにして、グローバル代表ロググループ以外の全ての更新ロググループについてコミット処理が実行しながら、コミットに失敗した全ての更新ロググループの識別子を主記憶装置上のコミット再送信リストに登録していき、それら更新ロググループのコミット処理の実行が終了すれば、該コミット再送信リストをログ記憶装置に記憶する。したがって、グローバル代表ロググループのログ記憶装置に記憶されたコミット再送信リストには、再度、コミット依頼の送信が必要なグローバル代表ロググループ以外の全ての更新ロググループの識別子が登録されている。
調整者は、ステップＳ１３８において、グローバル代表ロググループのトランザクションコミット処理を実施する。この場合、グローバル代表ロググループは、例えば、グローバル代表ロググループ表から取得する。そして、グローバル代表ロググループのコミットログをログ記憶装置に出力し（ステップＳ１３９）、本フローチャートの処理を終了する。
尚、ステップＳ１３８のグローバル代表ロググループのトランザクションコミット処理及びステップＳ１３９のグローバル代表ロググループのコミットログ出力の後で、それらの処理が失敗であったか判断する処理を行ってはいない。このように、グローバル代表ロググループの場合には、コミットログの出力に失敗しても、それを無視する。これは、この時点で、分散トランザクションの全参加者の全ての更新ロググループについてコミット状態であることが保証されており、調整者がダウンする事態が発生したとしても、後述するように、準備完了ログに記憶されている参加ロググループリストをコミット再送信リストとして利用できるからである。
図１４は、調整者で更新が有る場合の参加者のコミット処理を示すフローチャートである。尚、調整者で更新が無い場合の参加者のコミット処理も、図１４のフローチャートと同様になる。
参加者は、調整者が送信した「コミット依頼パケット」を受信すると（ステップＳ１５１）、更新ロググループリストの現在のエントリが終端であるか判断する（ステップＳ１５２）。そして、更新ロググループリストの終端でなければ（ステップＳ１５２、ＮＯ）ステップＳ１５３に進み、更新ロググループリストの終端であれば（ステップＳ１５２、ＹＥＳ）ステップＳ１５９に進む。
参加者は、ステップＳ１５３において、更新ロググループリストの現在のエントリに登録されている識別子を有するロググループのトランザクションコミット処理を実行する。そして、そのトランザクションコミット処理が失敗したか判断する（ステップＳ１５４）。参加者は、そのトランザクションコミット処理が成功したと判断すれば（ステップＳ１５４、ＮＯ）ステップＳ１５５に進み、失敗したと判断すれば（ステップＳ１５４、ＹＥＳ）ステップＳ１６０に進む。
参加者は、ステップＳ１５５において、上記トランザクションコミット処理に成功したロググループのコミットログをログ記憶装置に出力する。そして、該コミットログの出力に失敗したか判断し（ステップＳ１５６）、失敗しない（成功した）と判断すればステップＳ１５７に進み、失敗したと判断すればステップＳ１６０に進む。
参加者は、ステップＳ１５７において、上記コミットログの出力に成功したロググループの識別子をインダウト状態リストから削除する。そして、更新ロググループリストの現在のエントリを次のエントリに位置づけ（ステップＳ１５８）、ステップＳ１５２に戻る。
このようにして、参加者は、ステップＳ１５２において、更新ロググループリストの現在のエントリが終端であると判断する（ステップＳ１５２、ＹＥＳ）まで、ステップＳ１５２〜Ｓ１５８の処理を繰り返す。そして、ステップＳ１５２において、更新ロググループリストの現在のエントリが終端であると判断すると（ステップＳ１５２、ＹＥＳ）、「コミット完了応答」（処理結果が“成功”であるコミット応答パケット）を調整者に送信し（ステップＳ１５９）、本フローチャートの処理を終了する。
参加者は、ステップＳ１６０において、「コミット失敗応答」（処理結果が“失敗”であるコミット応答パケット）を調整者に送信し、本フローチャートの処理を終了する。
以上の処理により、参加者の更新ロググループリストに登録されている全てのロググループについて「トランザクションコミット処理」と「コミットログの出力」が成功した場合には、調整者に前記コミット完了応答が返信される。それ以外の場合には、調整者に前記コミット失敗応答が返信される。また、更新ロググループリストに登録されているロググループの内、「トランザクションコミット処理」と「コミットログの出力」に成功したロググループは、インダウト状態リストから削除される。
｛調整者で更新が有る場合のコミット処理を示すシステム構成図｝
図１５は、図１２に示すインダウト状態にある分散トランザクションシステムにおいて、上述した図１３及び図１４のフローチャートに示すコミット処理が行われた場合における、該分散トランザクションシステムの状態の遷移を示すシステム構成図（その１）である。図１５は、分散トランザクションの全ての参加者（この場合、調整者も含む）がコミット処理に成功した場合の例を示している。図１５において、図１２に示す構成要素と同一の構成要素には同じ符号を付与している。
調整者（データベース管理装置１）は、参加者リスト１５０を参照して、まず、最初のエントリに格納されている装置名ＤＢＭＳ２を有する第１の参加者（データベース管理装置２）に対してコミット依頼パケット７０１を送信する。第１の参加者は、該コミット依頼パケット７０１を受信すると、更新ロググループリスト１３０−２を参照して、更新ロググループリスト１３０−２に識別子（Ｇ２１）が登録されているロググループ２１のコ
ミット処理を行い、そのコミット処理が成功すると、コミットログ２３０（２３０−２１）をログ記憶装置２０１−２１に格納する。また、インダウト状態リスト１７０−２からロググループ２１の識別子Ｇ２１を削除する。図１５は、インダウト状態リスト１７０−２からこの識別子Ｇ２１が削除された状態を示している。第１の参加者は、次に、「処理結果（成功）」が格納されたコミット応答パケット７５１を調整者に送信する。調整者は、このコミット応答パケット７５１を受信すると、それに格納されている「処理結果」を参照して、第１の参加者がコミット処理に成功したと判断する。
次に、調整者は、参加者リスト１５０の第２のエントリに格納されている装置名ＤＢＭＳ３を有する第２の参加者（データベース管理装置３）に対してコミット依頼パケット７０２を送信する。第２の参加者は、該コミット依頼パケット７０２を受信すると、更新ロググループリスト１３０−３を参照して、それに識別子（Ｇ３１、Ｇ３２）が登録されているロググループ３１、３２について、コミット処理とコミットログの出力を行う。この場合、まず、ロググループ３１についてコミット処理とコミットログの出力が行われる。そして、次に、ロググループ３２についてコミット処理とコミットログの出力が行われる。ロググループ３１のコミットログ２３０（２３０−３１）はログ記憶装置２０１−３１に出力され、ロググループ３２のコミットログ２３０（２３０−３２）はログ記憶装置２０１―３２に出力される。第２の参加者は、ロググループ３１、３２のコミット処理とコミットログの出力が共に成功すると、インダウト状態リスト１７０−３から、それらの識別子Ｇ３１、Ｇ３２を削除する。図１５は、インダウト状態リスト１７０−３からこれらの識別子Ｇ３１、Ｇ３２が削除された状態を示している。第２の参加者は、次に、「処理結果（成功）」が格納されたコミット応答パケット７５２を調整者に送信する。調整者は、そのコミット応答パケット７５２を受信すると、そのパケット７５２内の「処理結果」を参照して、第２の参加者がコミット処理に成功したと判断する。
調整者は、次に、自身の更新ロググループリスト１３０−１を参照して、その更新ロググループリスト１３０−１に登録されているロググループのコミット処理を行う。図１５に示すように、更新ロググループリスト１３０１−１の第１のエントリにはロググループ（グローバル代表ロググループ）１１の識別子Ｇ１１が、第２のエントリにはロググループ１２の識別子Ｇ１２が登録されている。調整者は、まず、グローバル代表ロググループでないロググループ１２のコミット処理を行う。そして、そのコミット処理に成功すると、そのコミットログ２３０（２３０−１２）をロググループ１２のログ記憶装置２０１−１２に出力する。そして、その出力が成功すると、次に、コミット再送信リストが空であることを確認してから、グローバル代表ロググループであるロググループ１１のコミット処理を行う。このコミット処理が成功すると、次に、そのコミットログ２３０（２３０−１１）をロググループ１１のログ記憶装置２０１−１１に出力する。そして、その出力に成功すると、コミット処理を終了する。
図１６は、図１２に示すインダウト状態にある分散トランザクションシステムにおいて、上述した図１３及び図１４のフローチャートに示すコミット処理が行われた場合における、該分散トランザクションシステムの状態の遷移を示すシステム構成図（その２）である。図１６は、分散トランザクションの参加者（この場合、調整者も含む）の中の一部の参加者がコミット処理に失敗した場合の例を示している。図１６において、図１２に示す構成要素と同一の構成要素には同じ符号を付与している。
図１６は、第１の参加者（データベース管理装置２）がコミットログ２３０（２３０−２１）をロググループ２１のログ記憶装置に出力・格納した後に、調整者（データベース管理装置１）に対してコミット処理の応答（コミット応答パケット）を送信する前がダウンした場合のシステム状況を示している。この場合、調整者はデータベース管理装置２からコミット依頼７０１に対する応答を受けとらないので、調整者はデータベース管理装置
２がコミット処理に失敗したと判断し（ステップＳ１２５、ＹＥＳ）、データベース管理装置２の全ての更新ロググループ（Ｇ２１）を主記憶装置内のコミット再送信リスト１７０に登録する（ステップＳ１２６）。このコミット再送信リスト１７０は、コミット処理が完了しなかった参加者のロググループを記憶するリストである。このような参加者には、データベース管理装置ｉがダウン（障害）から復旧した場合に、分散トランザクションが「コミット」で終了したこと（２相コミットの投票結果）を通知する必要がある。コミット再送信リスト１７０は、このようなコミット処理が失敗した参加者の全更新ロググループを記憶しておくためのリストである。調整者は、主記憶装置内のコミット再送信リスト１７０を、最終的に、グローバル代表ロググループ（Ｇ１１）のロググループ１１のログ記憶装置２０１に書き込む（ステップＳ１３７）。したがって、調整者のコミット処理が終了した場合、コミット処理に失敗した参加者の全更新ロググループに関する情報は、グローバル代表ロググループのロググループのログ記憶装置２０１にコミット再送信リスト２４０として保存される。尚、図１６は参加者であるデータベース管理装置においてコミット処理に失敗した例であるが、調整者の更新ロググループのコミット処理に失敗する場合もありうる。この場合には、グローバル代表ロググループのロググループのコミット再送信リストに、そのコミット処理に失敗した更新ロググループの識別子が記録される。
｛調整者がダウンした場合の参加者の処理｝
図１７は、図１２に示すように、参加者がインダウト状態であるときに、調整者が障害によりダウンした場合の参加者の処理を示すフローチャートである。参加者は、クラスタ管理装置１０から「調整者となっているデータベース管理装置ｉがダウンした旨」を通知されることによって、図１７のフローチャートの処理を開始する。
参加者は、インダウト状態リストの現在のエントリが終端であるか判断し（ステップＳ１７１）、終端であれば（ステップＳ１７１、ＹＥＳ）ステップＳ１８２に進み、終端でなければステップＳ１７２に進む。
参加者は、ステップＳ１７２において、ロググループ偏在表から「グローバル代表ロググループの管理権を持つ（データベース管理装置）のＤＢＭＳ」を求める。この場合、ロググループ偏在表に登録されているＤＢＭＳｉの中から、正常に動作しているデータベース管理装置の中で最も優先順位が高いデータベース管理装置ｉのＤＢＭＳｉを求める。
参加者は、次に、上記求めたＤＢＭＳを有するデータベース管理装置に対して、「トランザクション状態（２相コミットの投票結果）の問合せ」を送信する（ステップＳ１７３）。そして、そのデータベース管理装置から「上記問合せの結果」を受信する（ステップＳ１７４）。参加者は、上記問合せの結果が「コミット指示」であるか判断し（ステップＳ１７５）、コミット指示でなければ（ステップＳ１７５、ＮＯ）ステップＳ１７６に進み、コミット指示であればステップＳ１７８に進む。
参加者は、ステップＳ１７６において、更新ロググループリストの現在のエントリに登録されているロググループについて「トランザクションのロールバック処理」を行う。そして、そのロールバック処理を行ったロググループの「ロールバックログ」を、そのロググループのログ記憶装置に出力し（ステップＳ１７７）、ステップＳ１８０に進む。
一方、参加者は、ステップＳ１７８において、更新ロググループリストの現在のエントリに登録されているロググループについて「トランザクションのコミット処理」を行う。そして、そのコミット処理を行ったロググループの「コミットログ」を、そのロググループのログ記憶装置に出力し（ステップＳ１７９）、ステップＳ１８０に進む。
参加者は、ステップＳ１８０において、上記ロールバック処理またはコミット処理を行
ったロググループをインダウト状態リストから削除する。そして、インダウト状態リストの現在のエントリを次のエントリに位置付け（ステップＳ１８１）、ステップＳ１７１に戻る。
このようにして、参加者は、ステップＳ１７１においてインダウト状態リストの現在のエントリが終端であると判断するまで、ステップＳ１７１〜Ｓ１８１の処理を繰り返す。これにより、参加者のインダウト状態リストに登録されている全てのロググループについて、２相コミットの投票結果に基づく処理（コミット処理またはロールバック処理）が実施され、それらのロググループのインダウト状態が解消される。また、参加者のインダウト状態リストは空となる。
参加者は、最後に、調整者との接続環境を削除し（ステップＳ１８２）、本フローチャートの処理を終了する。参加者は、ステップＳ１８２の処理において、調整者との通信路の切断や接続先情報の削除などを行う。
＜２相コミットに関係するデータベース管理装置がダウンした場合の処理＞
２相コミット中に、その２相コミットに関係するデータベース管理装置がダウンした場合、そのデータベース管理装置が管理していたロググループの管理は他の正常動作しているデータベース管理装置に委譲される。この場合、ダウンしたデータベース管理装置が調整者であった場合には、グローバル代表ロググループの管理権が他のデータベース管理装置に移る。また、調整者がグローバル代表ロググループ以外のロググループも管理していた場合には、そのロググループの管理権も他のデータベース管理装置に移ることになる。また、ダウンしたデータベース管理装置が参加者であった場合には、そのデータベース管理装置が管理していたロググループの管理権が、他のデータベース管理装置に移ることになるが、この場合は、グローバル代表ロググループの管理権の移動は無い。
｛グローバル代表ロググループ表以外のロググループの管理権を取得したデータベース管理装置におけるトランザクション解決処理｝
図１８は、グローバル代表ロググループ以外のロググループの管理権を取得したデータベース管理装置（ＤＢＭＳ）のトランザクション解決処理を示すフローチャートである。
データベース管理装置は、管理権を取得したロググループのログ記憶装置に「準備完了ログ」が格納されているか判断し（ステップＳ１９１）、準備完了ログだけが格納されている、つまり、管理権を取得したロググループに対して準備完了ログだけが出力されていれば（ステップＳ１９１、ＹＥＳ）、インダウト状態リストにそのロググループの識別子を登録し（ステップＳ１９２）、ステップＳ１９３に進む。一方、データベース管理装置は、ステップＳ１９１において、準備完了ログだけでなく２相コミットの投票結果に関するログ（コミットログまたはロールバックログ）もログ記憶装置に格納されていれば（ステップＳ１９１、ＮＯ）、本フローチャートの処理を終了する。
このように、データベース管理装置は、管理権を出力したログ記憶装置内に格納されている２相コミットに関係するログを調べ、インダウト状態となっているロググループの識別子のみをインダウト状態リストに登録する。
データベース管理装置は、ステップＳ１９３において、上記準備完了ログから「グローバル代表ロググループ（の識別子）」を取得する。そして、ロググループ偏在表から「グローバル代表ロググループの管理権を持つＤＢＭＳ」を求める（ステップＳ１９４）。尚、ステップＳ１９４の処理を行う時点で、ロググループ偏在表は最新の状態に更新されているので、ダウンしているデータベース管理装置のＤＢＭＳはロググループ偏在表に登録されていない。
データベース管理装置は、次に、上記求めたＤＢＭＳを有するデータベース管理装置に対して、「トランザクション結果の問合せ」を送信する（ステップＳ１９５）。そして、その後、上記問合せを送信したデータベース管理装置（グローバル代表ロググループの管理権を持つデータベース管理装置）からの応答を受信すると、その応答が「コミット指示」であるか判断する（ステップＳ１９６）。
データベース管理装置は、ステップＳ１９６において、コミット指示が返信されたと判断すると（ステップＳ１９６、ＹＥＳ）、上記インダウト状態リストに登録したロググループのコミット処理（トランザクションコミット処理）を行い（ステップＳ１９７）、コミットログをそのロググループのログ記憶装置に出力し（ステップＳ１９８）、ステップＳ２０１に進む。
一方、データベース管理装置は、ステップＳ１９６において、ロールバック指示が返信されたと判断すると（ステップＳ１９６、ＮＯ）、上記インダウト状態リストに登録したロググループのロールバック処理を行い（ステップＳ１９９）、ロールバックログをそのロググループのログ記憶装置に出力し（ステップＳ２００）、ステップＳ２０１に進む。
データベース管理装置は、ステップＳ２０１において、上記コミット処理またはロールバック処理を行ったロググループをインダウト状態リストから削除する。そして、本フローチャートの処理を終了する。
以上の処理により、インダウト状態となっていたロググループ（グローバル代表ロググループ以外のロググループ）を管理していたデータベース管理装置がダウンした場合でも、そのロググループの管理権を取得したデータベース管理装置によって、そのロググループのインダウト状態が解決される。
｛グローバル代表ロググループの管理権を取得したデータベース管理装置におけるトランザクション解決処理｝
図１９は、グローバル代表ロググループの管理権を取得したデータベース管理装置のトランザクション解決処理を示すフローチャートである。このグローバル代表ロググループの管理権を取得したデータベース管理装置は、元のグローバル代表ロググループの管理権の取得者である調整者に代わって、調整者の役割を果たす必要がある。図１３のフローチャートを参照して説明したように、調整者は、コミット依頼を再送信すべきロググループに関する情報を、グローバル代表ロググループのログ記憶装置にコミット再送信リストとして記録している。このコミット再送信リストには、調整者が管理していたロググループの中でコミットが完了していない（コミット処理とコミットログ出力の両方が終了していないロググループ）ロググループも含まれている。以上を前提にして、図１９のフローチャートを説明する。
データベース管理装置は、管理権を取得したグローバル代表ロググループのロググループのログ記憶装置を調べ、該ログ記憶装置内にコミット再送信リストが存在するか判断する（ステップＳ２１１）。そして、コミット再送信リストが存在すれば（ＹＥＳ）、そのコミット再送信リストを主記憶装置内に記憶し（ステップＳ２１２）、ステップＳ２１５に進む。
一方、データベース管理装置は、ステップＳ２１１において、コミット再送信リストがないと判断すれば（ステップＳ２１１、ＮＯ）、前記グローバル代表ロググループのログ記憶装置を調べ、そのログ記憶装置に準備完了ログだけが出力（格納）されており、コミットログは出力（格納）されていないか判断する（ステップＳ２１３）。そして、準備完了ログのみが出力されていれば（ステップＳ２１３、ＹＥＳ）、その準備完了ログから参加ロググループリストを取得し、それを、主記憶装置内にコミット再送信リストとして記憶し（ステップＳ２１４）、ステップＳ２１５に進む。
以上の処理により、データベース管理装置の主記憶装置内には、インダウト状態を解決する必要があるロググループが上記コミット再送信リストに登録される。つまり、グローバル代表ロググループのログ記憶装置にコミット再送信リストが記録されている場合には、そのコミット再送信リストに記録されている情報を、そのまま、コミット再送信リストとして利用することができる。また、グローバル代表ロググループのログ記憶装置に準備完了ログのみが記録されている場合には、その準備完了ログ内の参加ロググループリストをコミット再送信リストとして利用することで、分散トランザクションに参加している調整者以外の全参加者が登録されているコミット再送信リストを作成することができる。また、グローバル代表ロググループのログ記憶装置に準備完了ログとコミットログが記録されており、かつ、コミット再送信リストが存在しなければ、インダウト状態となっている参加者は存在しないので、コミット再送信リストを作成する必要はない。調整者は、既に、分散トランザクションの全ての参加者（調整者以外の参加者）にコミットを指示しているからである。
データベース管理装置は、ステップＳ２１５において、主記憶装置内のコミット再送信リスト（以後、コミット再送信リストとのみ記載）の現在のエントリ終端であるか判断する。そして、コミット再送信リストの終端でないと判断すると（ステップＳ２１５、ＮＯ）ステップＳ２１６に進み、コミット再送信リストの終端であると判断すると（ステップＳ２１５、ＹＥＳ）本フローチャートの処理を終了する。
データベース管理装置は、ステップＳ２１６において、ロググループ偏在表を参照して、コミット再送信リストの現在のエントリに登録されているロググループの管理権を持つＤＢＭＳを取得する。そして、その取得したＤＢＭＳを有するデータベース管理装置に対して、「該ロググループのコミット依頼（コミット依頼パケット）」を送信する（ステップＳ２１７）。そして、その後、該コミット依頼の送信に失敗したか判断し（ステップＳ２１８）、送信失敗であれば（ステップＳ２１８、ＹＥＳ）、ステップＳ２２２に進む。一方、データベース管理装置は、ステップＳ２１８において、上記コミット依頼の送信が成功したと判断すれば（ステップＳ２１８、ＮＯ）、その後、上記コミット依頼を送信したデータベース管理装置から応答を受信する（ステップＳ２１９）。そして、その応答結果が「コミット処理に失敗」であるか判断し（ステップＳ２２０）、「コミット処理に成功」であれば（ステップＳ２２０、ＹＥＳ）、コミット再送信リストの現在のエントリから「該コミット処理に成功したロググループ」を削除し（ステップＳ２２１）、ステップＳ２２２に進む。
データベース管理装置は、ステップＳ２２２において、コミット再送信リストの現在のエントリを次のエントリに位置付ける。そして、ステップＳ２１５に戻る。
以上のようにして、データベース管理装置は、ステップＳ２１５でコミット再送信リストの現在のエントリが終端であると判断するまで（ステップＳ２１５、ＹＥＳ）、ステップＳ２１５〜Ｓ２２２の処理を繰り返す。
これにより、グローバル代表ロググループの管理権を取得した時点でインダウト状態となっている全てのロググループについてコミット依頼が送信され、該ロググループのインダウト状態が解決される。但し、コミット依頼の送信に失敗したロググループ、または、コミット依頼の送信には成功したもののコミット処理に失敗したロググループはインダウト状態のままととなり、コミット再送信リストに登録されたままとなる。
｛調整者で更新が有る場合に、調整者がダウンした場合のシステム状況｝
図２０は、調整者（データベース管理装置１）で更新が有る場合に、調整者がダウンした場合のシステム状況の一例を示す図である。図２０において、図１５に示す構成要素と同じ構成要素には同一の符号を付与している。
図２０に示すシステムにおいては、第１の参加者（データベース管理装置２）の更新ロググループ２１には「コミットログ」が格納されているが、第２の参加者（データベース管理装置３）の更新ロググループ３１、３２には「コミットログ」が格納されていない。これは、調整者（データベース管理装置１）が第１の参加者（データベース管理装置２）にコミット依頼を送信した後にダウンしたことを示している（図１３のフローチャートを参照）。データベース管理装置２は、データベース管理装置２からコミット依頼を受信し、ロググループ２１のコミット処理を行い、そのコミット処理とコミットログの出力に成功している。調整者がダウンする前は、データベース管理装置２の主記憶装置にはインダウト状態リスト１７０（１７０−２）とコミット再送信リスト１８０（１８０−２）は記憶されていない。
調整者がダウンすると、調整者が管理していたグローバル代表ロググループ１１とロググループ１２の管理権はデータベース管理装置２に移動する。これに伴い、データベース管理装置２、３のロググループ偏在表１１０−２、１１０−３のロググループ１１、１２に関する情報は書き換えられる。この書き換え処理の詳細は後述する。具体的には、ロググループ１１の識別子Ｇ１１とロググループ１２の識別子Ｇ１２が、共に、データベース管理装置２の装置名ＤＢＭＳ２に関連付けられる。
データベース管理装置２は、グローバル代表ロググループ１１とロググループ１２の管理権を取得すると、グローバル代表ロググループ１１については図１９のフローチャートに示すトランザクション解決処理を、ロググループ１２については図１８のフローチャートに示すトランザクション解決処理を実行する。
グローバル代表ロググループ１１について図１９に示すトランザクション解決処理が実行されることによって、グローバル代表ロググループ１１のログ記憶装置に記録されている準備完了ログ２２０−１の参加ロググループリストが、データベース管理装置２の主記憶装置内にコミット再送信リスト１８０−２として記憶される（図２０参照）。そして、データベース管理装置２は、そのコミット再送信リスト１８０−２に識別子Ｇｉｋが登録されているロググループに対して、ロググループ偏在表１１０を参照してコミット依頼（コミット指示）を送信する。この例では、コミット再送信リスト１７０−２にはロググループの識別子Ｇ１２、Ｇ２１、Ｇ３１、Ｇ３２が登録されている。したがって、ロググループ１２、２１の管理権を有するデータベース管理装置２に対して「コミット指示」が送信される。また、ロググループ３１、３２の管理権を有するデータベース管理装置３に対して「コミット指示」が出力される。
以上のようにして、第１の参加者（データベース管理装置２）にコミット依頼を送信した後にダウンした調整者（データベース管理装置１）から、それが管理していたロググループ１１、１２の管理権を受け継いだデータベース管理装置２は、グローバル代表ロググループ（ロググループ１１）のログ記憶装置に記録されていた準備完了ログ２２０−１とロググループ偏在表１１０を基に、調整者の残りの処理、つまり第２の参加者（データベース管理装置２）に対するコミット依頼を代行する。これにより、２相コミットの準備処理終了後に調整者がダウンし、その調整者が管理していたロググループの管理権が分散トランザクションの他の参加者に移動しても、調整者のグローバル代表ロググループのログ記憶装置に記録されていた準備完了ログを基に、インダウト状態にある参加者にコミットを指示することができる。
また、図１６に示すように、グローバル代表ロググループのログ記憶装置にコミット再送信リストが記録されていた調整者がダウンした場合には、そのグローバル代表ロググループの管理権を引き継いだ参加者は、該コミット再送信リストを基に、インダウト状態となっているロググループにコミットを指示することができる。つまり、ロググループ偏在表を参照して、コミット再送信リストに登録されている識別子Ｇｉｋを有するロググループの管理権を有している参加者に対してコミットを指示することができる。
また、ロググループ１２について図１８のトランザクション解決処理が実行されることによって、ロググループ１２の識別子Ｇ１２がデータベース管理装置２の主記憶装置内のインダウト状態リスト１７０−２に登録される（図２０参照）。データベース管理装置２は、図１８のトランザクション解決処理の実行により、ロググループ１２のログ記憶装置に記録されている準備完了ログ２２０−１２からグローバル代表ロググループの識別子Ｇ１１を取得し、ロググループ偏在表１１０を参照して該取得したグローバル代表ロググループの識別子Ｇ１１の管理権を持つデータベース管理装置（のＤＢＭＳ）を求める。この場合、ＤＢＭＳ２が求まる。したがって、データベース管理装置２に対して、ロググループ２１の識別子Ｇ２１が設定された「トランザクション結果の問合せ依頼」１７０１を送信する。この場合、その問合せに対して、データベース管理装置２から「コミット指示」１７５１が返信される。したがって、データベース管理装置２は、ロググループ２１に対してコミット処理を行う。
参加者（データベース管理装置３）は、図１７のフローチャートに示す処理を実行する。まず、インダウト状態リスト１７０−３とロググループ偏在表１１０を参照することで、参加者（データベース管理装置２）に対してトランザクション結果の問合せ依頼１８０１、１８０２を送信する。トランザクション結果の問合せ依頼（トランザクション結果の問合せ依頼パケット）１８０１にはロググループ３１の識別子Ｇ３１が設定され、トランザクション結果の問合せ依頼（トランザクション結果の問合せ依頼パケット）１８０２にはロググループ３２の識別子Ｇ３２が設定されている。
参加者（データベース管理装置２）は、上記トランザクション結果の問合せ依頼１８０１に対して“コミット指示”の応答１８５１を返信する。また、上記トランザクション結果の問合せ依頼１８０２に対しても“コミット指示”の応答１８５２を返信する。
参加者（データベース管理装置２）は、上記応答１８５１、１８５２を受信すると、ロググループ３１、３２についてトランザクションコミット処理を行い、ロググループ３１、３２のログ記憶装置に、コミットログ（不図示）を出力・記録する。また、参加者（データベース管理装置３）は、主記憶装置内のインダウト状態リスト１７０−３から、コミットが完了したロググループ３１、３２の識別子Ｇ３１、３２を削除する。これにより、インダウト状態リスト１７０−３は“空”となる。
＜調整者で更新が無い場合の処理＞
調整者で更新がない場合、すなわち、調整者が分散トランザクションにおいて更新すべきロググループ（更新ロググループ）を管理していない場合には、分散トランザクションに参加する参加者の中から一人の「代表参加者」を選ぶ。この場合、代表参加者以外の参加者を「一般参加者」と呼ぶ。代表参加者は、調整者が決定する。代表参加者は、通常の２相コミットにおける調整者の機能の一部を代行する。一般に分散トランザクションの最終結果をログに記録する責務を担うプロセスは、２相コミットの各フェーズの最後にログ出力を行うため、代表参加者は、第１フェーズの最後に準備処理を、第２フェーズの最後にコミット処理を行う。
｛調整者の準備処理｝
図２１は、調整者で更新が無い場合の調整者の準備処理を示すフローチャートである。
この準備処理において、調整者は、まず、代表参加者を決定し、その代表参加者を主記憶装置内に記憶する（ステップＳ３７１）。この決定は、「トランザクション完了ログ出力先の優先順位定義表」と「ロググループ偏在表」を参照することにより行われる。調整者は、まず、トランザクション完了ログ出力先の優先順位定義表を参照し、その中で最も優先順位が高く設定されているロググループ（の識別子Ｇｉｋ）を取得する。次に、ロググループ偏在表を参照して、その取得したロググループの管理権を有するデータベース管理装置ｉ（ＤＢＭＳｉ）を取得し、そのデータベース管理装置ｉを「代表参加者」に決定する。尚、調整者で更新が無い場合の分散トランザクションシステムの「ロググループ偏在表及びロググループ偏在表」と「ロググループ偏在表」の内容は、上述した調整者で更新が有る場合の分散トランザクションシステムの「トランザクション完了ログ出力先の優先順位定義表ロググループ偏在表」と「ロググループ偏在表」の内容とは異なっている。これは、前者の場合、調整者が更新されるロググループ(更新ロググループ)を備えていないからである。
調整者は、次に、上記決定した代表参加者のローカル代表ロググループをグローバル代表ロググループ表に設定する（ステップＳ３７２）。そして、参加者リストの現在のエントリが終端であるか判断する（ステップＳ３７３）。参加者リストの終端でなければ（ステップＳ３７３、ＮＯ）ステップＳ３７４に進み、参加者リストの終端であれば（ステップＳ３７３、ＹＥＳ）、ステップＳ３８３に進む。
調整者は、ステップＳ３７４において、参加者リストの現在のエントリに登録されている参加者が代表参加者であるか判断する。そして、一般参加者であれば（ステップＳ３７４、ＮＯ）ステップＳ３７５に進み、代表参加者であればステップＳ３８３に進む。
調整者は、ステップＳ３７５において、グローバル代表ロググループの識別子Ｇｉｋを通信パケットに設定する。そして、この通信パケットを、一般参加者に「準備依頼パケット」として送信する（ステップＳ３７６）。その後、該準備依頼パケットの送信に失敗したか判断し（ステップＳ３７７）、送信失敗であると判断すれば（ステップＳ３７７、ＹＥＳ）本フローチャートの処理を異常終了し、送信成功であると判断すればステップＳ３７８に進む。
調整者は、ステップＳ３７８において、一般参加者から上記準備依頼パケットに対する応答（準備応答パケット）を受信する。そして、その準備応答パケットに設定されている処理結果を参照して、一般参加者が準備処理に失敗したか判断し（ステップＳ３７９）、一般参加者が準備処理に失敗したと判断すれば（ステップＳ３７９、ＹＥＳ）本フローチャートの処理を異常終了する。一方、一般参加者が準備処理に成功したと判断すれば（ステップＳ３７９、ＮＯ）、前記準備応答パケットから一般参加者が更新したロググループ（更新ロググループ）の識別子Ｇｉｋを取得し（ステップＳ３８０）、該識別子Ｇｉｋを、参加者リストの現在のエントリに関連付ける（ステップＳ３８１）。そして、参加者リストの現在のエントリを次のエントリに位置付け（ステップＳ３８２）、ステップＳ３７３に戻る。
調整者は、ステップＳ３７３において参加者リストの現在のエントリが終端であると判断するまで、ステップＳ３７３〜Ｓ８２の処理を繰り返す。これにより、調整者は、参加者リストに登録されている全ての一般参加者に「準備依頼パケット」を送信し、それに対する応答（準備応答パケット）を受信する。このとき、準備依頼パケットの送信と準備応答パケットの受信に成功した場合には、該準備応答パケットから「一般参加者が更新したロググループ（更新ロググループ）」を取得し、該更新ロググループを、参加者リストの
該一般参加者のＤＢＭＳｉが登録されているエントリに関連付ける。このようにして、参加者リストには、準備処理に成功した一般参加者の更新ロググループが登録される。
調整者は、ステップＳ３８３において、「全ての一般参加者の全ロググループの識別子Ｇｉｋ」と「代表参加者フラグ」を通信パケット（準備依頼パケット）に設定する。そして、該準備応答パケットを代表参加者に送信する（ステップＳ３８４）。その後、該準備応答パケットの送信に失敗したか判断し（ステップＳ３８５）、失敗したと判断すれば（ステップＳ３８５、ＹＥＳ）本フローチャートの処理を異常終了する。一方、該準備応答パケットの送信に成功したと判断すれば（ステップＳ３８５、ＮＯ）、該準備応答パケットに対する代表参加者からの応答（準備応答パケット）を受信する（ステップＳ３８６）。そして、該準備応答パケットに設定された処理結果を基に、代表参加者が準備処理に失敗したか判断し（ステップＳ３８７）、成功したと判断すれば（ステップＳ３８７、ＮＯ）本フローチャートの処理を終了する。一方、失敗したと判断すれば（ステップＳ３８７、ＹＥＳ）本フローチャートの処理を異常終了する。
このようにして、調整者は、代表参加者に対して「代表参加者フラグ」と「全一般参加者の全ての更新ロググループ」が設定された準備依頼パケットを送信し、該準備依頼パケットに対する応答（準備応答パケット）を受信する。そして、該準備応答パケットに設定された処理結果を基に、代表参加者が準備処理に成功したか判断する。
｛代表参加者の準備処理｝
図２２は、調整者で更新が無い場合の代表参加者の準備処理を示すフローチャートである。
この準備処理において、代表参加者は、まず、調整者が送信した準備依頼（準備依頼パケット）を受信する（ステップＳ４０１）。次に、ローカル代表ロググループをグローバル代表ロググループ表に設定し、該準備依頼パケットに設定されている代表参加者の指定（代表参加者フラグ）を主記憶装置に記憶する（ステップＳ４０２）。
代表参加者は、上記準備依頼パケットから分散トランザクションの全ての一般参加者の全更新ロググループの識別子を取得し（ステップＳ４０３）、該取得した全一般参加者の全ての更新ロググループの識別子を主記憶装置（の全一般参加者の全更新ロググループリスト）に記憶する（ステップＳ４０４）。
代表参加者は、更新ロググループリストの現在のエントリが終端であるか判断し（ステップＳ４０５）、終端であると判断すれば（ステップＳ４０５、ＹＥＳ）ステップＳ４１２に進み、終端でないと判断すれば（ステップＳ４０５、ＮＯ）ステップＳ４０６に進む。
代表参加者は、ステップＳ４０６において、更新ロググループリストの現在のエントリに登録されているロググループがグローバル代表ロググループであるか判断する。そして、グローバル代表ロググループであると判断すれば（ステップＳ４０６、ＹＥＳ）ステップＳ４１１に進み、グローバル代表ロググループでないと判断すれば（ステップＳ４０６、ＮＯ）ステップＳ４０７に進む。
代表参加者は、ステップＳ４０７において、更新ロググループリストの現在のエントリに登録されているロググループのトランザクション準備処理を行う。そして、該トランザクション準備処理が失敗したか判断し（ステップＳ４０８）、失敗したと判断すれば（ステップＳ４０８、ＹＥＳ）、通信パケット（準備応答パケット）に処理結果（＝“失敗”）を設定する（ステップＳ４１９）。そして、該準備応答パケットを調整者に送信して（ステップＳ４２０）、本フローチャートの処理を終了する。
一方、代表参加者は、ステップＳ４０８において、上記トランザクション準備処理が成功したと判断すれば（ステップＳ４０８、ＮＯ）、グローバル代表ロググループの識別子を設定した「準備完了ログ」をロググループ（更新ロググループリストの現在のエントリに識別子が登録されているロググループ）のログ記憶装置に出力する（ステップＳ４０９）。
代表参加者は、該準備完了ログの出力処理が失敗したか判断し（ステップＳ４１０）、失敗したと判断すれば（ステップＳ４１０、ＹＥＳ）、上述したステップＳ４１９、Ｓ４２０の処理を行い、本フローチャートの処理を終了する。一方、上記準備完了ログの出力処理が成功したと判断すれば（ステップＳ４１０、ＮＯ）、更新ロググループリストの現在のエントリを次のエントリに位置付け、ステップＳ４０５に戻る。
このようにして、代表参加者は、ステップＳ４０５において更新ロググループリストの現在のエントリが終端であると判断するか、ステップＳ４０８においてトランザクション準備処理に失敗したと判断するか、または、ステップＳ４１０において準備完了ログの出力処理に失敗したと判断するまで、ステップＳ４０５〜Ｓ４１１の処理を繰り返す。
以上の処理により、代表参加者は、自身の更新ロググループリストに登録されているロググループ（更新ロググループ）について、トランザクション準備処理と準備完了ログの出力処理を行う。
代表参加者は、ステップＳ４１２において、グローバル代表ロググループのトランザクション準備処理を行う。そして、該トランザクション準備処理が失敗したか判断し（ステップＳ４１３）、失敗していなければ（ステップＳ４１３、ＮＯ）ステップＳ４１４に進み、失敗していれば（ステップＳ４１３、ＹＥＳ）ステップＳ４１７に進む。
代表参加者は、ステップＳ４１４において、分散トランザクションの全ての一般参加者の全更新ロググループの識別子を設定した「準備完了ログ」を、グローバル代表ロググループのログ記憶装置に出力する。そして、該準備完了ログの出力処理が失敗したか判断し（ステップＳ４１５）、該出力処理が成功であれば（ステップＳ４１５、ＮＯ）、通信パケット（準備応答パケット）に処理結果（＝“成功”）を設定する（ステップＳ４１６）。そして、該準備応答パケットを調整者に送信し（ステップＳ４１７）、本フローチャートの処理を終了する。
一方、代表参加者は、ステップＳ４１５において、上記準備完了ログの出力処理に失敗したと判断すれば（ステップＳ４１５、ＮＯ）、通信パケット（準備応答パケット）に処理結果（＝“失敗”）を設定し（ステップＳ４１７）、該準備応答パケットを調整者に送信し（ステップＳ４１８）、本フローチャートの処理を終了する。
以上のようにして、代表参加者は、グローバル代表ロググループについて、トランザクション準備処理と準備完了ログの出力処理を行い、それらの処理結果を設定した準備応答パケットを調整者に送信する。
尚、一般参加者は、調整者から「準備依頼パケット」を受信した場合、前述した図１１に示すフローチャートの処理を行う。この場合、トランザクション準備処理と準備完了ログの出力処理に成功したロググループ（更新ロググループ）は「インダウト状態リスト」に登録される。
｛２相コミットにおける準備処理におけるシステム状況｝
図２３は、上述した図２１及び図２２のフローチャートの処理が実行された場合の分散トランザクションシステムの状況の一例を示す図である。図２３において、図８に示す分散トランザクションシステム５が備える構成要素と同一の構成要素には同じ符号を付与している。
図２３において、図８に示されていない構成要素について説明する。
調整者（データベース管理装置１）は、主記憶装置内に代表参加者のＤＢＭＳｉを記憶する領域である代表参加者記憶表１９０を備える。また、グローバル代表ロググループ表１６０も主記憶装置内に有している。
代表参加者（データベース管理装置２）は、主記憶装置内に自装置が「代表参加者」に指定されたことを記憶するためのフラグである代表参加者フラグ１０１０を備える。また、全一般参加者の全更新ロググループリスト１０２０を備える。この全一般参加者の全更新ロググループリスト１０２０には、調整者から通知される全ての一般参加者の全ての更新ロググループが登録される。また、グローバル代表ロググループ表１６０を主記憶装置内に有している。代表参加者に管理されるロググループ２１内には準備完了ログ２２０−２１が記録されている。ロググループ２１は、グローバル代表ロググループであり、その識別子Ｇ２１が上記グローバル代表ロググループ表１６０に設定されている。
一般参加者（データベース管理装置３）は、主記憶装置内にインダウト状態リスト１７０−３とグローバル代表ロググループ表１６０を備えている。
図２３を参照しながら、上述した図２１と図２２のフローチャートに示す処理の概要を説明する。
調整者は、一般参加者（データベース管理装置３）に対して、グローバル代表ロググループ２１の識別子Ｇ２１が設定された準備依頼パケット１６０２を送信する。
一般参加者（データベース管理装置３）は、該準備応答パケット１６０２を受信すると、そのパケット１６０２に設定されているグローバル代表ロググループ２１の識別子Ｇ２１を、主記憶装置内のグローバル代表ロググループ表１６０−３に記憶する。そして、更新ロググループリスト１３０−３に識別子が登録されているロググループ３１、３２についてトランザクション準備処理を行う。そして、該トランザクション準備処理に成功すると、ロググループ３１の準備完了ログ２２０−３１をロググループ３１のログ記憶装置に出力・記録する。また、ロググループ３２の準備完了ログ２２０−３２をロググループ３２のログ記憶装置に出力・記録する。準備完了ログ２２０−３１、２２０−３２には、２相コミットの投票結果の問合せ先情報として、グローバル代表ロググループ２１の識別子Ｇ２１が設定されている。一般参加者は、該準備完了ログ２２０−３１、２２０−３２の出力処理に成功すると、トランザクション準備処理の処理結果と更新ロググループ３１、３２の識別子Ｇ３１、Ｇ３２が設定された準備応答パケット１６５２を調整者に送信する。
次に、調整者（データベース管理装置１）は、代表参加者（データベース管理装置２）に対して、準備依頼パケット１６０１を送信する。この準備依頼パケット１６０１には、「代表参加者フラグ」と「一般参加者の全ての更新ロググループのリスト」が設定されている。
代表参加者（データベース管理装置２）は、該準備応答パケット１６０１を受信すると、そのパケット１６０１に設定されている代表参加者フラグを、主記憶装置内の代表参加者フラグ１０１０に記憶する。また、該パケット１６０１に設定されている一般参加者の全ての更新ロググループのリストを、主記憶装置内の全一般参加者の全更新ロググループリスト１０２０に設定する。また、代表参加者は、更新ロググループリスト１３０−２に識別子が設定されているロググループ２１についてトランザクション準備処理を行い、該トランザクション準備処理に成功すると、準備完了ログ２２０−２１をロググループ２１のログ記憶装置に出力・記録する。
｛調整者のコミット処理｝
図２４は、調整者で更新が無い場合の調整者のコミット処理を示すフローチャートである。
調整者は、参加者リストの現在のエントリが終端であるか判断し（ステップＳ４３１）、終端であると判断すれば（ステップＳ４３１、ＹＥＳ）ステップＳ４３９に進み、終端でないと判断すれば（ステップＳ４３１、ＮＯ）ステップＳ４３２に進む。
調整者は、ステップＳ４３２において、参加者リストの現在のエントリに登録されている参加者（ＤＢＭＳｉ）が代表参加者（ＤＢＭＳｉ）であるか判断する。そして、代表参加者であると判断すると（ステップＳ４３２、ＹＥＳ）ステップＳ４３８に進み、代表参加者でないと判断すると（ステップＳ４３２、ＮＯ）ステップＳ４３３に進む。
調整者は、ステップＳ４３３において、一般参加者にコミット依頼（コミット依頼パケット）を送信する。そして、該コミット依頼の送信に失敗したか判断し（ステップＳ４３４）、該送信に失敗したと判断すると（ステップＳ４３４、ＹＥＳ）ステップＳ４３７に進み、該送信に成功したと判断すると（ステップＳ４３４、ＮＯ）ステップＳ４３５に進む。
調整者は、ステップＳ４３５において、上記コミット依頼を送信した一般参加者からの応答（コミット応答パケット）を受信する。そして、そのコミット応答パケットに設定されている処理結果を基に、該一般参加者がコミット処理に失敗したか判断し（ステップＳ４３６）、失敗したと判断すれば（ステップＳ４３６、ＹＥＳ）ステップＳ４３７に進み、成功したと判断すれば（ステップＳ４３６、ＮＯ）ステップＳ４３８に進む。
調整者は、ステップＳ４３７において、現在処理中の一般参加者（参加者リストの現在のエントリに登録されている一般参加者）の全更新ロググループのリストを主記憶装置内に一時的に記憶する。そして、ステップＳ４３８に進む。調整者は、ステップＳ４３７において、参加者リストの現在のエントリに登録されている一般参加者のＤＢＭＳに関連付けられているロググループを取得することにより、該一般参加者の全更新ロググループのリストを取得する。
調整者は、ステップＳ４３８において、参加者リストの現在のエントリを次のエントリに位置づけ、ステップＳ４３１に戻る。
このようにして、調整者は、ステップＳ４３１において、参加者リストの現在のエントリが終端であると判断するまで、ステップＳ４３１〜Ｓ４３８の処理を繰り返す。以上の処理により、調整者は、一般参加者に対してコミット依頼（コミット依頼パケット）を送信する。そして、一般参加者に対する該コミット依頼の送信に失敗するか、または、該コミット依頼に対する一般参加者からの応答（コミット応答パケット）に設定された処理結果に基づき、該一般参加者がコミット処理に失敗したと判断した場合には、該一般参加者の全更新ロググループのリストを主記憶装置内に記憶する。
調整者は、ステップＳ４３９において、主記憶装置に記憶されている、コミットに失敗した全ての一般参加者の全更新ロググループの識別子を通信パケット（コミット依頼パケット）に設定する。そして、該コミット依頼パケットを代表参加者に送信し（ステップＳ４４０）、その後、代表参加者から該コミット依頼パケットの送信に対する応答を受信し（ステップＳ４４１）、本フローチャートの処理を終了する。
尚、ステップＳ４３９において、参加者リストに登録されている全ての一般参加者に対してコミット依頼パケットの送信に成功し、かつ、該全ての一般参加者がコミット処理に成功したと判断した場合には、代表参加者に送信するコミット依頼パケットには更新ロググループは設定されない。
以上のようにして、調整者は、代表参加者に対して、コミットに失敗した一般参加者の更新ロググループに関する情報が設定されたコミット依頼（コミット依頼パケット）を送信する。
｛代表参加者のコミット処理｝
図２５は、調整者で更新が無い場合の代表参加者のコミット処理を示すフローチャートである。
代表参加者は、調整者から通信パケット（コミット依頼パケット）を受信すると、該コミット依頼パケットに設定されている「コミットに失敗したロググループ（更新ロググループ）のリスト」を取得する（ステップＳ４５１）。そして、その取得したロググループのリストを、主記憶装置内にコミット再送信リストとして記憶する（ステップＳ４５２）。この場合、上記コミット依頼パケットにロググループが設定されていなければ、該コミット再送信リストは“空”となる。
代表参加者は、代表参加者の更新ロググループリスト（以下、更新ロググループリストと呼ぶ）の現在のエントリが終端であるか判断し（ステップＳ４５３）、終端であると判断すると（ステップＳ４５３、ＹＥＳ）ステップＳ４６１に進み、終端でないと判断すると（ステップＳ４５３、ＮＯ）ステップＳ４５４に進む。
代表参加者は、ステップＳ４５４において、更新ロググループリストの現在のエントリに登録されているロググループが「グローバル代表ロググループ」であるか判断する。そして、グローバル代表ロググループであると判断すると（ステップＳ４５４、ＹＥＳ）ステップＳ４６０に進み、グローバル代表ロググループでないと判断するとステップＳ４５５に進む。ここで、グローバル代表ロググループの識別子は、主記憶装置内のグローバル代表ロググループ表に設定されているので、この識別子を基に、ステップＳ４５４の判断を行う。
代表参加者は、ステップＳ４５５において、ロググループ（グローバル代表ロググループ以外の更新ロググループ）のトランザクションコミット処理を行う。そして、該コミット処理に失敗したか判断し（ステップＳ４５６）、失敗したと判断すると（ステップＳ４５６、ＹＥＳ）ステップＳ４５９に進み、該コミット処理に成功したと判断すると（ステップＳ４５６、ＮＯ）ステップＳ４５７に進む。
代表参加者は、ステップＳ４５７において、コミットログを、現在処理中のロググループのログ記憶装置に出力する。そして、該コミットログの出力処理が失敗したか判断し（ステップＳ４５８）、失敗したと判断すると（ステップＳ４５８、ＹＥＳ）、主記憶装置内のコミット再送信リストに現在処理中のロググループを登録し（ステップＳ４５９）、ステップＳ４６０に進む。一方、代表参加者は、ステップＳ４５８において、上記コミットログの出力処理に成功したと判断すると（ステップＳ４５８、ＮＯ）ステップＳ４６０に進む。
代表参加者は、ステップＳ４６０において、更新ロググループリストの現在のエントリ
を次のエントリに位置づけ、ステップＳ４５３に戻る。
このようにして、代表参加者は、ステップＳ４５３において、更新ロググループリストの現在のエントリが終端であると判断するまで、ステップＳ４５３〜Ｓ４６０の処理を繰り返す。
以上の処理により、代表参加者は、更新ロググループリスト（代表参加者の更新ロググループリスト）に登録されているグローバル代表ロググループ以外のロググループについてトランザクションコミット処理とコミットログの出力処理を行う。この場合、該２つの処理が共に成功しなかったロググループ、つまり、コミットに失敗したロググループは主記憶装置内のコミット再送信リストに登録する。
代表参加者は、ステップＳ４６１において、該コミット再送信リストが“空”であるか判断する。そして、該コミット再送信リストが空でなければ（ステップＳ４６１、ＮＯ）、該コミット再送信リストをグローバル代表ロググループのログ記憶装置に記憶し（ステップＳ４６２）、ステップＳ４６３に進む。
代表参加者は、ステップＳ４６３において、グローバル代表ロググループのトランザクションコミット処理を行う。そして、該コミット処理に関するコミットログを、グローバル代表ロググループのログ記憶装置に出力し（ステップＳ４６４）、主記憶装置内の全一般参加者の全更新ロググループリストを削除する（ステップＳ４６５）。そして、調整者にコミット完了のパケット（コミット応答パケット）を送信し（ステップＳ４６６）、本フローチャートの処理を終了する。
｛代表参加者及び一般参加者がコミットに成功した場合のシステム状況｝
図２６は、調整者で更新が無い分散トランザクションシステムにおいてのコミット処理が行われた場合のシステム状況（その１）を示す図である。図２６において、図２３の分散トランザクションシステムが備える構成要素と同一の構成要素には同じ符号を付与している。
調整者（データベース管理装置１）は、参加者リスト１５０を参照して、一般参加者であるデータベース管理装置３に対してコミット依頼（コミット依頼パケット）１７０２を送信する。一般参加者（データベース管理装置３）は、更新ロググループリスト１３０−３を参照して、ロググループ３１、ロググループ３２の順に、トランザクションコミット処理とコミットログ出力処理を行い、それらの処理に成功して、ロググループ３１、３２に、それぞれ、コミットログ２３０−３１、２３０−３２を記録する。そして、処理結果（＝“成功”）が設定されたコミット応答パケット１７５２を調整者に送信する。
調整者は、次に、更新ロググループの識別子Ｇｉｋが設定されていないコミット依頼パケット１７０１を、代表参加者（データベース管理装置２）に送信する。今回の場合、コミットに失敗した一般参加者が存在しないので、コミット依頼パケット１７０１にはロググループは設定されない。
代表参加者は、調整者が送信した上記コミット依頼パケット１７０１を受信する。代表参加者は、そのパケット１７０１に「コミットに失敗したロググループのリスト」が設定されていないので、主記憶装置にコミット再送信リストを作成しない。代表参加者は、次に、代表参加者の更新ロググループリスト１３０−２を参照するが、そのリスト１３０−２にはグローバル代表ロググループの識別子Ｇ２１のみが設定されており、かつ、コミット再送信リストは空なので（コミット再送信リストが無いので）、グローバル代表ロググループのトランザクションコミット処理を行い、それに成功すると、コミットログ２３０−２１をグローバル代表ロググループ２１のログ記憶装置に出力する。そして、主記憶装
置内の全一般参加者の全更新ロググループリスト１０２０を削除して、「コミット完了応答」であるコミット応答パケット１７５１を調整者に送信する。調整者は、そのコミット応答パケット１７５１を受信する。
｛一般参加者がコミットに失敗した場合のシステム状況｝
図２７は、調整者で更新が無い分散トランザクションシステムにおいてのコミット処理が行われた場合のシステム状況（その２）を示す図である。図２７において、図２３の分散トランザクションシステムが備える構成要素と同一の構成要素には同じ符号を付与している。
図２７は、一般参加者がダウンしてしまい、一般参加者においてコミットに失敗した場合のシステム状況の一例を示す図である。
図２７に示すシステムは、調整者（データベース管理装置１）から一般参加者（データベース管理装置３）にコミット依頼パケット１７１２が送信され、一般参加者はそのパケット１７１２を受信したが、ロググループ３１のログ記憶装置にコミットログを出力する前にダウンした例を示している。
この場合、調整者（データベース管理装置１）は、一般参加者（データベース管理装置３）から「コミット完了応答」のパケットを受信できないので、一般参加者がコミット処理に失敗したと判断する。そして、参加者リスト１５０から一般参加者の全更新ロググループの識別子（Ｇ３１、Ｇ３２）を取得し、それらの識別子Ｇ３１、Ｇ３２を設定したコミット依頼パケット１７１１を代表参加者（データベース管理装置２）に送信する。
代表参加者（データベース管理装置２）は、該コミット依頼パケット１７１１を受信すると、そのパケット１７１１からコミットに失敗したロググループのリスト（Ｇ３１、Ｇ３２）を取得する。そして、そのリスト（Ｇ３１、Ｇ３２）を、コミット再送信リスト１８０−２として主記憶装置内に一時的に記憶する。代表参加者は、次に、代表参加者の更新ロググループリスト１３０−２を参照する。この例では、そのリスト１３０−２にはグローバル代表ロググループの識別子Ｇ２１のみが登録されているので、上記主記憶装置内に記憶したコミット再送信リストを、コミット再送信リスト２４０−２１として、グローバル代表ロググループであるロググループ２１のログ記憶装置に出力・記録する。そして、グローバル代表ロググループ（ロググループ２１）のトランザクションコミット処理を行い、次に、コミットログ２３０−２１を、グローバル代表ロググループ（ロググループ２１）のログ記憶装置に出力・記録する。そして、主記憶装置内の全一般参加者の全更新ロググループリスト１０２０を削除して、「コミット完了応答」であるコミット応答パケット１７６１を調整者に送信する。調整者は、そのコミット応答パケット１７６１を受信する。
｛調整者で更新が無い場合の調整者ダウン時の一般参加者の処理｝
図２８は、調整者で更新が無い分散トランザクションにおいて、調整者がダウンした時の一般参加者の処理を示すフローチャートである。
調整者で更新が無い分散トランザクションの２相コミットにおいて調整者がダウンした場合には、一般参加者は、インダウト状態となっている更新ロググループのインダウト状態を解決するために、代表参加者にトランザクション状態（トランザクション結果）を問い合わせ、代表参加者からコミットまたはロールバックの指示を受ける必要がある。
図２８のフローチャートの処理を説明する。
一般参加者は、インダウト状態リストの現在のエントリが終端であるか判断し（ステップＳ４８１）、終端であれば（ステップＳ４８１、ＹＥＳ）ステップＳ４９２に進み、終
端でなければ（ステップＳ４８１、ＮＯ）ステップＳ４８２に進む。
一般参加者は、ステップＳ４８２において、ロググループ偏在表を参照して、グローバル代表ロググループの管理権を持つデータベース管理装置のＤＢＭＳを求める。つまり、グローバル代表ロググループ表からグローバル代表ロググループの識別子を求め、ロググループ偏在表から、その識別子に対応するＤＢＭＳを求める。この場合、該ＤＢＭＳは代表参加者のＤＢＭＳである（図２６参照）。
一般参加者は、その求めたＤＢＭＳを有するデータベース管理装置（代表参加者）に対して、「トランザクション結果の問合せ」を送信する（ステップＳ４８３）。そして、該データベース管理装置（代表参加者）から、トランザクション結果を受信し（ステップＳ４８４）、その受信内容から代表参加者の依頼がコミット指示であるか判断する（ステップＳ４８５）。
一般参加者は、ステップＳ４８５において、コミット指示であると判断すれば（ステップＳ４８５、ＹＥＳ）、インダウト状態リストの現在のエントリに登録されているロググループ（処理中のロググループ）のトランザクションコミット処理を実行し（ステップＳ４８８）、コミットログを、該処理中のロググループのログ記憶装置に出力し（ステップＳ４８９）、ステップＳ４９０に進む。
一方、一般参加者は、ステップＳ４８５において、上記投票結果がロールバック、つまりロールバック指示であると判断すれば（ステップＳ４８５、ＮＯ）、処理中のロググループのロールバック処理を実行し（ステップＳ４８６）、ロールバックログを、該処理中のロググループのログ記憶装置に出力し（ステップＳ４８７）、ステップＳ４９０に進む。
一般参加者は、ステップＳ４９０において、インダウト状態リストの現在のエントリに登録されているロググループ（処理中のロググループ）を削除する。そして、インダウト状態リストの現在のエントリを次のエントリに位置づけ（ステップＳ４９１）、ステップＳ４８１に戻る。
このようにして、一般参加者は、ステップＳ４８１において、インダウト状態リストの現在のエントリが終端であると判断するまで、ステップＳ４８１〜Ｓ４９１の処理を繰り返す。以上の処理により、一般参加者は、インダウト状態リストに登録されている各ロールバックについて、その２相コミットの投票結果を代表参加者から受け取り、該投票結果に従って、該各ロールバックのコミット処理またはロールバック処理を行う。そして、コミット処理を行った場合にはコミットログを、ロールバック処理を行った場合にはロールバックログを、各ロググループのログ記憶装置に出力する。
一般参加者は、ステップＳ４９２において調整者との接続環境を解除し、本フローチャートの処理を終了する。
｛調整者で更新が無い場合の調整者ダウン時の代表参加者の処理｝
図２９は、調整者で更新が無い分散トランザクションにおいて、調整者がダウンした時の代表参加者の処理を示すフローチャートである。
調整者で更新が無い分散トランザクションの２相コミットにおいて調整者がダウンした場合には、代表参加者は、調整者に代わって、一般参加者に対して「コミット依頼」または「ロールバック依頼」を送信する必要がある。また、自装置が管理する更新ロググループについて、「コミット処理」または「ロールバック処理」を行う必要がある。代表参加者は、グローバル代表ロググループのログ記憶装置に「準備完了ログ」が記録されていれ
ば「コミット」を、準備完了ログが記録されていなければ「ロールバック」を決定する。
図２９のフローチャートを説明する。
代表参加者は、全一般参加者の全更新ロググループリストの現在のエントリが終端であるか判断し（ステップＳ５０１）、終端であると判断すれば（ステップＳ５０１、ＹＥＳ）ステップＳ５１２に進み、終端でないと判断すれば（ステップＳ５０１、ＮＯ）ステップＳ５０２に進む。
代表参加者は、ステップＳ５０２において、グローバル代表ロググループのログ記憶装置に準備完了ログが記録されているか調べ、グローバル代表ロググループは「準備完了後の状態」であるか判断する。この場合、該準備完了ログが記録されていれば、グローバル代表ロググループは準備完了後の状態である判断する。
代表参加者は、ステップＳ５０２において、グローバル代表ロググループは準備完了後の状態である判断すれば（ステップＳ５０２、ＹＥＳ）ステップＳ５０３に進み、準備完了後の状態でないと判断すれば（ステップＳ５０２、ＮＯ）ステップＳ５０８に進む。
代表参加者は、ステップＳ５０３において、一般参加者に対して、処理中のロググループ（全一般参加者の全更新ロググループリストの現在のエントリに登録されているロググループ）を設定した「コミット依頼（コミット依頼パケット）」を送信する。そして、その送信が失敗したか判断し（ステップＳ５０４）、送信失敗であると判断すると（ステップＳ５０４、ＹＥＳ）ステップＳ５１１に進み、送信成功であると判断すると（ステップＳ５０４、ＮＯ）ステップＳ５０５に進む。尚、代表参加者は、ステップＳ５０３において一般参加者にコミット依頼を送信する際に該一般参加者の通信アドレスを取得する必要があるが、その通信アドレスはロググループ偏在表を参照することで取得する。つまり、ロググループ偏在表から、コミットを指示するロググループの管理権を持つデータベース管理装置のＤＢＭＳを取得することで、該ＤＢＭＳに対応する通信アドレスを取得する。これは、後述する、ステップＳ５０８における一般参加者に対する「ロールバック依頼」の送信処理においても同様である。
代表参加者は、ステップＳ５０５において、上記コミット依頼を送信した一般参加者からの応答（コミット応答パケット）を受信する。そして、その応答に含まれる情報（処理結果）を調べ、該一般参加者が上記指定したロググループのコミットに失敗したか判断する（ステップＳ５０６）。
代表参加者は、一般参加者が該ロググループのコミットに失敗したと判断すると（ステップＳ５０６、ＹＥＳ）ステップＳ５１１に進み、コミットに成功したと判断すると（ステップＳ５０６、ＮＯ）ステップＳ５０７に進む。
代表参加者は、ステップＳ５０７において、全一般参加者の全更新ロググループリストから、上記コミットに失敗したロググループ（全一般参加者の全更新ロググループリストの現在のエントリに登録されているロググループ）を削除する。そして、ステップＳ５１１に進む。
代表参加者は、ステップＳ５０８において、一般参加者に対して、処理中のロググループを指定した「ロールバック依頼（ロールバック依頼パケット）」を送信する。そして、該一般参加者から該ロールバック依頼に対する応答を受信し（ステップＳ５０９）、全一般参加者の全更新ロググループリストから該処理中のロググループを削除し（ステップＳ５１０）、ステップＳ５５１１に進む。
代表参加者は、ステップＳ５１１において、全一般参加者の全更新ロググループリストの現在のエントリを次のエントリに位置づけ、ステップＳ５０１に戻る。
このようにして、代表参加者は、ステップＳ５０１において、全一般参加者の全更新ロググループリストの現在のエントリが終端であると判断するまで、ステップＳ５０１〜Ｓ５１１の処理を繰り返す。以上の処理により、代表参加者の全一般参加者の全更新ロググループリストに登録されている全てのロググループについて「コミット」または「ロールバック」の指示が決定され、各ロググループの管理権を持つ一般参加者に対して「コミット依頼」または「ロールバック依頼」が送信される。そして、コミット依頼を受信した一般参加者が指定されたロググループのコミットに成功した場合には、そのロググループが全一般参加者の全更新ロググループリストから削除される。該ロググループはコミットが完了し、インダウト状態が解決されたからである。また、ロールバック依頼を送信した一般参加者から応答を受信した場合にも、該ロールバック依頼で指定したロググループを、全一般参加者の全更新ロググループリストから削除する。
代表参加者は、ステップＳ５１２において、ステップＳ５０２と同様な処理により、グローバル代表ロググループは「準備完了後の状態」であるか判断する。そして、準備完了後の状態であると判断すれば（ステップＳ５１２、ＹＥＳ）ステップＳ５１３に進み、準備完了後の状態でないと判断すればステップＳ５２０に進む。
代表参加者は、ステップＳ５１３において、代表参加者の更新ロググループの現在のエントリが終端であるか判断する。そして、終端であると判断すると（ステップＳ５１３、ＹＥＳ）ステップＳ５１８に進み、終端でないと判断すると（ステップＳ５１３、ＮＯ）ステップＳ５１４に進む。
代表参加者は、ステップＳ５１４において、更新ロググループの現在のエントリに登録されているロググループが代表ロググループ（ローカル代表ロググループまたはグローバル代表ロググループ）であるか判断する。そして、代表ロググループであると判断すると（ステップＳ５１４、ＹＥＳ）、ステップＳ５１７に進み、代表ロググループでないと判断すると（ステップＳ５１４、ＮＯ）ステップＳ５１５に進む。
代表参加者は、ステップＳ５１５において、更新ロググループの現在のエントリに登録されているロググループ（処理中のロググループ）のトランザクションコミット処理を実行する。そして、コミットログを該処理中のロググループのログ記憶装置に出力し（ステップＳ５１６）、ステップＳ５１７に進む。
代表参加者は、ステップＳ５１７において、代表参加者の更新ロググループの現在のエントリを次のエントリに位置づける。そして、ステップＳ５１３に戻る。
このようにして、代表参加者は、ステップＳ５１３において、代表参加者の更新ロググループの現在のエントリが終端であると判断するまで、ステップＳ５５１２〜Ｓ５１７の処理を繰り返す。以上の処理により、代表参加者の更新ロググループリストに登録されている代表ロググループ以外のロググループ（更新ロググループ）について、トランザクションコミット処理とコミットログの出力が行われる。これにより、これらのロググループはコミットされる。つまり、インダウト状態が解決される。
代表参加者は、ステップＳ５１８において、代表ロググループのトランザクションコミット処理を行う。そして、コミットログを該代表ロググループのログ記憶装置に出力し（ステップＳ５１９）、本フローチャートの処理を終了する。
これにより、グローバル代表ロググループが準備完了後の状態になっている場合には、代表ロググループのコミットが完了する。以上のようにして、代表参加者が管理する全て
の更新ロググループのコミットが完了する。
代表参加者は、ステップＳ５２０において、代表参加者の更新ロググループリストの現在のエントリが終端であるか判断する。そして、終端であると判断すると（ステップＳ５２０、ＹＥＳ）、本フローチャートの処理を終了する。一方、終端でないと判断すると（ステップＳ５２０、ＮＯ）、更新ロググループの現在のエントリに登録されているロググループ（処理中のロググループ）のトランザクションロールバック処理を行い（ステップＳ５２１）、ロールバックログを該処理中のロググループのログ記憶装置に出力し（ステップＳ５２２）、代表参加者の更新ロググループリストの現在のエントリを次のエントリに位置付け（ステップＳ５２３）、ステップＳ５２０に戻る。
このようにして、代表参加者は、ステップＳ５２０において代表参加者の更新ロググループリストの現在のエントリが終端であると判断するまで、ステップＳ５２０〜Ｓ５２３の処理を繰り返す。以上の処理により、グローバル代表ロググループが準備完了後の状態になっていない場合には、代表参加者が管理権を持つ全ての更新ロググループについて、ロールバック処理とロールバックログの出力が行われ、該全ての更新ロググループのロールバックが完了する。
｛調整者で更新が無い場合に、調整者がダウンした場合のシステム状況｝
図３０は、調整者で更新が無い場合に、調整者がダウンした場合のシステム状況を示す図である。図３０において、図２６の分散トランザクションシステムが備える構成要素と同一の構成要素には同じ符号を付与している。
図３０は、分散トランザクションシステムが図２３に示す状況、つまり、トランザクション準備処理が完了した状況にあるときに、調整者がダウンした場合の代表参加者と一般参加者の動作を示している。図２３に示すシステム状況においては、一般参加者（データベース管理装置３）の更新ロググループ３１、３２がインダウト状態となっている。
図２３に示す状況において、上述した図２８と図２９のフローチャートに示す処理を、それぞれ、代表参加者（データベース管理装置２）と一般参加者（データベース管理装置３）が実行する。
次に、システムが図２３に示す状況後に調整者（データベース管理装置１）がダウンした場合に代表参加者（データベース管理装置２）が図２９のフローチャートに示す処理を行ったときのシステムの動作を、図３０を参照しながら説明する。
代表参加者（データベース管理装置２）は、まず、グローバル代表ロググループ２１のログ記憶装置に準備完了ログ２２０−２１が記録されていることを確認する。そして、全一般参加者の全更新ロググループリスト１０２０を参照して、一般参加者（データベース管理装置３）にコミット依頼（コミット依頼パケット）２００１、２００２を送信する。コミット依頼２００１には、ロググループ３１の識別子Ｇ３１が設定されており、コミット依頼２００２にはロググループ３２の識別子Ｇ３２が設定されている。
調整者は、代表参加者から上記コミット依頼２００１、２００２を受信すると、図１４のフローチャートに示す処理を実行し、ロググループ３１、３２についてトランザクションコミット処理とコミットログの出力を終了した後、コミット完了であるコミット応答（コミット応答パケット）２０５１、２０５２を代表参加者に送信する（図１４のステップＳ１５９）。
代表参加者は、グローバル代表ロググループ２１のログ記憶装置に準備完了ログ２２０
−２１が記録されていることを確認すると、代表参加者の更新ロググループリスト１３０−２１を参照して、グローバル代表ロググループ２１のトランザクションコミット処理を行い、グローバル代表ロググループ２１のログ記憶装置にコミットログ２３０−２１を出力・記録する。
［データベース管理装置がダウンした場合の処理］
図３１は、クラスタ管理装置がシステム内の、あるデータベース管理装置のダウンを検知した場合の他のデータベース管理装置の動作を示すフローチャートである。
クラスタ管理装置は、システム内の、あるデータベース管理装置のダウンを検知すると、システム内の他のデータベース管理装置に対して、上記ダウンしたデータベース管理装置のダウンを通知する。
これにより、ダウンしたデータベース管理装置以外のデータベース管理装置は、図３１のフローチャートに示す処理を実行する。
図３１のフローチャートを説明する。
データベース管理装置（ダウンしたデータベース管理装置以外のデータベース管理装置、以後、他のデータベース管理装置と記載する）は、クラスタ管理装置から「ＤＢＭＳダウン通知」を受信する（ステップＳ７０１）。
他のデータベース管理装置は、ロググループ偏在表と管理権の優先順位定義ファイル（図１参照）を参照し、ダウンしたデータベース管理装置が管理していたロググループの中から、自装置が管理権を引き継ぐべきロググループを特定する（ステップＳ７０２）。
この特定処理においては、まず、ロググループ偏在表を参照し、ダウンしたデータベース管理装置が管理していたロググループを特定する。次に、管理権の優先順位定義ファイルを参照し、該特定したロググループを自装置が引き継ぐ必要があるか判断する。上述したように、管理権の優先順位定義ファイルには、各ロググループについて、その管理権を有するデータベース管理装置の優先順位が設定されている。したがって、ダウンしたデータベース管理装置の次に位置付けられているデータベース管理装置が、ダウンしたデータベース管理装置が管理権を有していたロググループの管理権を引き継ぐことになる。
該ロググループの管理権を引き継いだデータベース管理装置は、該管理権を引き継いだロググループ毎のトランザクション復旧プロセスを生成する（ステップＳ７０３）。他のデータベース管理装置は、主記憶装置内のロググループ偏在表を更新し（ステップＳ７０４）、本フローチャートの処理を終了する。
ロググループ偏在表の更新は、管理権の優先順位定義ファイルを基に行うことができる。つまり、管理権の優先順位定義ファイルにおいて、ダウンしたデータベース管理装置のＤＢＭＳｉを削除して繰り上げればよい。
｛あるデータベース管理装置がダウンした場合における復旧後のシステム構成｝
図３２は、調整者（データベース管理装置１）、第１の参加者（データベース管理装置２）及び第２の参加者（データベース管理装置３）を備える分散トランザクションシステムにおいて、調整者がダウンした場合のシステム復旧処理を説明するシステム構成図である。図３２に示すシステム状況は図２０に類似しており、図２０に示す構成要素と同一の構成要素には同じ符号を付与している。
図３２に示す分散トランザクションシステムにおいて、クラスタ管理装置１０は、デー
タベース管理装置１（調整者）のダウンを検知すると、データベース管理装置１の装置名「ＤＢＭＳ１」が設定されたダウン通知２００２を、データベース管理装置２（第１の参加者）とデータベース管理装置３（第２の参加者）に送信する。
データベース管理装置２は、該ダウン通知２００２を受信すると、上述した図３１のフローチャートの処理を実行する。そして、図１に示す管理権の優先順位定義ファイル３００を参照して、データベース管理装置１が管理していたロググループ１１、１２の管理権を引き継ぐ。また、データベース管理装置２は、第１のトランザクション復旧プロセス２１１２及び第２のトランザクション復旧プロセス２１１３を主記憶装置上で生成・起動する。インダウト状態復旧プロセス２１１１は永続的なデーモン・プロセス(daemon process)である。
第１のトランザクション復旧プロセス２１１２（以下、トランザクション復旧プロセス２１１２と記載）は、ロググループ１１のトランザクションを復旧するためのプロセスである。また、第２のトランザクション復旧プロセス２１１３（以下、トランザクション復旧プロセス２１１３と記載）は、ロググループ１２のトランザクションを復旧するためのプロセスである。インダウト状態復旧プロセス２１１１は、トランザクション復旧プロセス２１１２、２１１３が即座に復旧できないトランザクションを解決するためのプロセスであり、それらの復旧プロセス２１１２、２１１３からのインダウト復旧依頼を非同期に受け付ける。
トランザクション復旧同期タイム時間２０１０は、トランザクション復旧プロセス２１１３が使用するタイムアウト時間であり、ユーザが設定する時間である。トランザクション復旧プロセス２１１３は、準備完了ログが出力されているが、コミットログまたはロールバックログが出力されていないロググループ１２をコミット状態まで復元した後、該準備完了ログに設定されているグローバル代表ロググループの復旧処理を、トランザクション復旧同期タイム時間２０１０に設定されている時間まで待つ。そして、タイムアウトした場合には、ロググループ１２のデータをインダウト状態に設定する。
トランザクション復旧同期タイム時間設定ファイル３２０は、上述トランザクション復旧同期タイム時間２０１０が設定されているファイルであり、各データベース管理装置の外部記憶装置（不図示）に記憶されている。データベース管理装置２は、外部記憶装置から該トランザクション復旧同期タイム時間設定ファイル３２０を読み出し、それに設定されている時間を、トランザクション復旧同期タイム時間２０１０として主記憶装置に記憶する。
｛グローバル代表ロググループのトランザクション復旧プロセス｝
図３３は、グローバル代表ロググループのトランザクション復旧プロセス（図３２のトランザクション復旧プロセス２１１２に該当）の処理を示すフローチャートである。
グローバル代表ロググループのトランザクション復旧プロセスは、当該ロググループ（グローバル代表ロググループ）のデータのアクセス禁止区間（アクセス禁止期間）を開始する（ステップＳ６０１）。そして、該グローバル代表ロググループのログ記憶装置からログを読み込む（ステップＳ６０２）。そして、該グローバル代表ロググループについて、準備完了ログは出力されているが、コミットまたはロールバックの完了ログが出力されていないか判断する（ステップＳ６０３）。
グローバル代表ロググループのトランザクション復旧プロセスは、ステップＳ６０３において、準備完了ログのみが出力されていると判断すると（ステップＳ６０３、ＹＥＳ）、その準備完了ログに設定されている「参加ロググループリスト」を読み込み、それをコミット再送信リストとして主記憶装置上に保持する（ステップＳ６０４）。そして、前記グローバル代表ロググループのデータを“コミット状態”まで復元し（ステップＳ６０５）、インダウト状態復旧プロセス（図３２のインダウト状態復旧プロセス２１１１に該当）にコミット再送信処理を依頼する（ステップＳ６１１）。該コミット再送信処理は、本プロセスとは非同期で実行される。そして、ステップＳ６１２に進む。
グローバル代表ロググループのトランザクション復旧プロセスは、ステップＳ６０３において、準備完了ログと、コミットまたロールバックの完了ログが出力されていると判断すれば（ステップＳ６０３、ＮＯ）、コミットログが出力されているか判断する（ステップＳ６０６）。そして、コミットログが出力されていれば（ステップＳ６０６、ＹＥＳ）、上記準備完了ログ内にコミット再送信リストがあるか判断する（ステップＳ６０７）。そして、コミット再送信リストがあれば（ステップＳ６０７、ＹＥＳ）、ステップＳ６０８に進み、コミット再送信リストがなければ（ステップＳ６０７、ＮＯ）ステップＳ６０９に進む。
グローバル代表ロググループのトランザクション復旧プロセスは、ステップＳ６０８において、そのコミット再送信リストを主記憶装置上に読み込む。そして、グローバル代表ロググループのデータを“コミット状態”まで復元し（ステップＳ６０９）、ステップＳ６１２に進む。
グローバル代表ロググループのトランザクション復旧プロセスは、ステップＳ６０６において、ロールバックログが出力されていると判断すれば（ステップＳ６０６、ＮＯ）、グローバル代表ロググループをロールバックし（ステップＳ６１０）、ステップＳ６１２に進む。
グローバル代表ロググループのトランザクション復旧プロセスは、ステップＳ６１２において、当該ロググループ（グローバル代表ロググループ）のデータのアクセス禁止区間を終了する。そして、本フローチャートの処理を終了する。
以上のようにして、グローバル代表ロググループのトランザクション復旧プロセスは、ダウンしたデータベース管理装置から管理権を引き継いだグローバル代表ロググループのトランザクションを復旧させる。この復旧処理の期間、グローバル代表ロググループのデータに対するアクセスを禁止させる。そして、グローバル代表ロググループのログ記憶装置に準備完了ログのみが出力（記録）されている場合、または、準備完了ログとコミットログが出力されている場合には、コミット再送信リストを主記憶装置上に作成し、グローバル代表ロググループのデータを“コミット状態”まで復元する。そして、インダウト状態復旧プロセスに対して、上記コミット再送信リストに登録されたロググループに対する「コミット依頼」の送信を依頼し、グローバル代表ロググループのデータに対するアクセス禁止を解除する。また、グローバル代表ロググループのログ記憶装置に準備完了ログとロールバックログが出力（記録）されている場合には、グローバル代表ロググループのデータをロールバックして、グローバル代表ロググループのデータに対するアクセス禁止を解除する。
また、グローバル代表ロググループのトランザクション復旧プロセスは、グローバル代表ロググループ以外のロググループが、グローバル代表ロググループと同一のデータベース管理装置（ＤＢＭＳ）にある場合は、即座に解決可能なトランザクションは自プロセスで実施し、即座に解決できないトランザクションについてはインダウト状態復旧プロセスに委託し、システム内のその他のロググループ全体に対するアプリケーションによる更新処理の再開を可能にする。
｛グローバル代表ロググループ以外のロググループのトランザクション復旧プロセス｝
図３４は、グローバル代表ロググループ以外のロググループのトランザクション復旧プロセスの処理を示すフローチャートである。
グローバル代表ロググループ以外のロググループのトランザクション復旧プロセス（図３２のトランザクション復旧プロセス２１１３に該当）は、当該ロググループ（自プロセスがトランザクション復旧処理を担当するロググループ）のデータのアクセス禁止区間（アクセス禁止期間）を開始し（ステップＳ６２１）、該ロググループのログ記憶装置からログを読み込む（ステップＳ６２２）。そして、該ロググループに対して準備完了ログのみが出力されているか判断する（ステップＳ６２３）。
グローバル代表ロググループ以外のロググループのトランザクション復旧プロセス（以下、便宜上、ロググループのトランザクション復旧プロセスを呼ぶ）は、ステップＳ６２３において、準備完了ログのみが出力されていると判断すれば（ステップＳ６２３、ＹＥＳ）、当該ロググループのデータをコミット状態まで復元し（ステップＳ６２４）、該準備完了ログに設定されたグローバル代表ロググループの復旧処理を、ユーザが設定した時間（図３２のトランザクション復旧同期タイム時間２０１０に該当）だけ待つ（ステップＳ６２５）。そして、タイムアウト、つまり、グローバル代表ロググループの復旧処理が該ユーザの設定時間内に終了しなかったか判断し（ステップＳ６２６）、タイムアウトであれば（ステップＳ６２６、ＹＥＳ）、ステップＳ６２７に進み、タイムアウトでなければ（ステップＳ６２６、ＮＯ）ステップＳ６３０に進む。
ロググループのトランザクション復旧プロセスは、ステップＳ６２７において、当該ロググループのデータ（更新データ）を“インダウト状態”に設定する。そして、当該ロググループを主記憶装置上のインダウト状態リストに登録し（ステップＳ６２８）、該インダウト状態に設定されたデータ（更新データ）を更新抑止状態にする（ステップＳ６２９）。そして、インダウト状態復旧プロセス（図３２のインダウト状態復旧プロセス２１１１に該当）にインダウト復旧依頼を行う（ステップＳ６４１）。該インダウト復旧依頼に対する処理は、本プロセスとは非同期で実行される。そして、ステップＳ６４２に進む。
ロググループのトランザクション復旧プロセスは、ステップＳ６３０において、グローバル代表ロググループの管理権を持つＤＢＭＳ（データベース管理装置）へトランザクションの最終結果を問い合わせる。そして、該問合せに対する応答が“コミット指示”であるか判断し（ステップＳ６３１）、コミット指示であると判断すれば（ステップＳ６３１、ＹＥＳ）、当該ロググループをコミットし（ステップＳ６３２）、当該ロググループのログ記憶装置にコミットログを出力し（ステップＳ６３３）、ステップＳ６４２に進む。
ロググループのトランザクション復旧プロセスは、ステップＳ６３１において、ロールバック指示であると判断すれば（ステップＳ６３１、ＮＯ）、当該ロググループをロールバックし、当該ロググループのログ記憶装置にロールバックログを出力し（ステップＳ６３５）、ステップＳ６４２に進む。
ロググループのトランザクション復旧プロセスは、ステップＳ６２３において、準備完了ログとそれ以外のログが出力されていると判断すれば（ステップＳ６２３、ＮＯ）、コミットログが出力されているか判断する（ステップＳ６３６）。そして、コミットログが出力されている判断すれば（ステップＳ６３６、ＹＥＳ）、当該ロググループのデータを“コミット状態”まで復元し（ステップＳ６３７）、ステップＳ６４２に進む。
ロググループのトランザクション復旧プロセスは、ステップＳ６３６において、ロールバックログが出力されていると判断すれば（ステップＳ６３６、ＮＯ）、当該ロググルー
プをロールバックし（ステップＳ６３９）、ステップＳ６４２に進む。
ロググループのトランザクション復旧プロセスは、ステップＳ６４２において、当該ロググループのデータのアクセス禁止区間を終了する。そして、本フローチャートの処理を終了する。
このように、グローバル代表ロググループ以外のロググループのトランザクション復旧プロセスも、グローバル代表ロググループのトランザクション復旧プロセスと同様に、即座に解決可能なトランザクションは自プロセスで実施し、即座に解決できないトランザクションについてはインダウト状態復旧プロセスに委託し、システム内のその他のロググループ全体に対するアプリケーションによる更新処理の再開を可能にする。
また、インダウト状態のデータだけを更新抑止する処理（ステップＳ６２７〜Ｓ６２９）は、トランザクションのデータ量やデータ記憶装置に対するランダムアクセス頻度に応じて処理時間及びデータ記憶装置に対する入出力のアクセス時間がかかる。このため、本プロセスの処理時間を短くするためには、ステップＳ６２５におけるグローバル代表ロググループのトランザクション復旧処理が成功する（タイムアウトしない）、つまり、ステップＳ６２７〜Ｓ６２９のインダウト状態のデータだけを更新抑止する処理を実施しないことが望ましい。本プロセスでは、該タイムアウトの時間をユーザが設定可能にすることで、グローバル代表ロググループのトランザクション復旧処理が終了するまでの待ち合わせ時間を長くして、該インダウト状態のデータだけを更新抑止する処理時間を避けることで、本プロセスに要する処理時間を短くするか、前記待ち合わせ時間を短くして、当該ロググループ全体に対するアクセスが許可されるまでの時間を短くするかのどちらかを、ユーザが選択できるようにしている。
｛インダウト状態復旧プロセス｝
図３５は、インダウト状態復旧プロセスの処理を示すフローチャートである。
インダウト状態復旧プロセスは、まず、終了指示であるか判断し（ステップＳ６５１）、終了指示であると判断すれば、本フローチャートの処理を終了する。一方、終了指示でないと判断すれば（ステップＳ６５１、ＮＯ）、コミット再送信リストの現在のエントリが終端であるか、または、コミット再送信リストが無いか判断する（ステップＳ６５２）。そして、コミット再送信リストの終端であると判断するか、または、コミット再送信リストが無いと判断すると（ステップＳ６５２、ＹＥＳ）ステップＳ６５９に進み、コミット再送信リストの終端でないと判断すると（ステップＳ６５２、ＮＯ）ステップＳ６５３に進む。
インダウト状態復旧プロセスは、ステップＳ６５３において、コミット再送信リストの現在のエントリに登録されているロググループのコミット依頼を、該ロググループの管理権を持つデータベース管理装置（ＤＢＭＳ）に送信する。そして、該コミット依頼の送信処理が失敗したか判断し（ステップＳ６５４）、該送信処理が失敗したと判断すると（ステップＳ６５４、ＹＥＳ）ステップＳ６５８に進み、該送信処理に成功したと判断すると（ステップＳ６５４、ＮＯ）ステップＳ６５５に進む。
インダウト状態復旧プロセスは、該コミット依頼に対する応答（応答パケット）を受信し（ステップＳ６５５）、その応答パケットに設定された「処理結果」を参照して、前記ロロググループのコミットに失敗したか判断する（ステップＳ６５６）。そして、該コミットに成功したと判断すれば（ステップＳ６５６、ＮＯ）、ステップＳ６５７に進み、コミット再送信リストの現在のエントリを削除する（ステップＳ６５７）。一方、該コミットに失敗したと判断すれば（ステップＳ６５６、ＹＥＳ）ステップＳ６５８に進む。
インダウト状態復旧プロセスは、ステップＳ６５７において、コミット再送信リストの現在のエントリを次のエントリに位置づけ、ステップＳ６５２に戻る。
このようして、インダウト状態復旧プロセスは、ステップＳ６５２において、コミット再送信リストの現在のエントリが終端となるまで、ステップＳ６５２〜Ｓ６５８の処理を繰り返す。以上の処理により、コミット再送信リストに登録されている全てのロググループについて、コミット依頼が、ロググループの管理権を持つデータベース管理装置に送信される。そして、コミットが成功したロググループについては、コミット再送信リストからそのエントリが削除される。また、コミットに失敗したロググループについては、コミット再送信リストのそのエントリは残ったままとまる。
インダウト状態復旧プロセスは、ステップＳ６５９において、インダウト状態リストの現在のエントリは終端であるか判断する。そして、終端であると判断すると（ステップＳ６５９、ＹＥＳ）ステップＳ６６８に進む。一方、終端でないと判断すると（ステップＳ６５９、ＮＯ）、ステップＳ６６０に進む。
インダウト状態復旧プロセスは、ステップＳ６６０において、グローバル代表ロググループの管理権を持つデータベース管理装置（ＤＢＭＳ）へトランザクションの最終結果を問い合わせる。そして、該問合せに対する応答を該データベース管理装置から受信し、該応答がコミット指示であるか判断する（ステップＳ６６１）。コミット指示であると判断すると（ステップＳ６６１、ＹＥＳ）、インダウト状態リストの現在のエントリに登録されているロググループをコミットし（ステップＳ６６２）、該ロググループのログ記憶装置にコミットログを出力する（ステップＳ６６３）。そして、ステップＳ６６６に進む。
一方、インダウト状態復旧プロセスは、ステップＳ６６１において、前記応答がロールバック指示であると判断すると（ステップＳ６６１、ＮＯ）、インダウト状態リストの現在のエントリに登録されているロググループをロールバックし（ステップＳ６６４）、該ロググループのログ記憶装置にロールバックログを出力する（ステップＳ６６５）。そして、ステップＳ６６６に進む。
インダウト状態復旧プロセスは、ステップＳ６６６において、現在のエントリを削除する。そして、インダウト状態リストの現在のエントリを次のエントリに位置づけ（ステップＳ６６７）、ステップＳ６５９に戻る。
このようにして、インダウト状態復旧プロセスは、インダウト状態リストの現在のエントリが終端となるまで、ステップＳ６５９〜Ｓ６６７の処理を繰り返す。以上の処理により、インダウト状態リストに登録されている全てのロググループについて、トランザクションの最終結果に応じた処理（コミットまたはロールバック）が行われ、各ロググループのログ記憶装置にコミットログまたはロールバックログが出力される。また、コミットまたはロールバックが実施されたロググループは、インダウト状態リストから削除される。
インダウト状態復旧プロセスは、ステップＳ６６８において、「トランザクション結果の問合せ（トランザクション結果問合せ）」、または「コミット依頼」を待つ。該トランザクション結果の問合せと該コミット依頼には、下記（１）〜（６）のようなものがある。
（１）インダウト状態であるときに、調整者のダウンを、クラスタ管理装置からの通知により検知した参加者からのトランザクション結果問合せ
（２）参加者ダウンによって、コミット処理の失敗を検知した調整者からのコミット依頼（３）他のデータベース管理装置（ＤＢＭＳ）のトランザクション復旧プロセスからのトランザクション結果問合せ
（４）他のデータベース管理装置（ＤＢＭＳ）のトランザクション復旧プロセスからのコ
ミット依頼
（５）他のデータベース管理装置（ＤＢＭＳ）のインダウト状態復旧プロセスからのトランザクション結果問合せ
（６）他のデータベース管理装置（ＤＢＭＳ）のインダウト状態復旧プロセスからのコミット依頼
インダウト状態復旧プロセスは、ステップＳ６６９において、トランザクション結果問合せであると判断すると（ステップＳ６６９、ＹＥＳ）ステップＳ６７０に進み、コミット依頼であると判断すると（ステップＳ６６９、ＮＯ）ステップＳ６７６に進む。
インダウト状態復旧プロセスは、ステップＳ６７０において、コミット再送信リストに、該トランザクション結果問合せのパケットに設定されているロググループ（以下、指定ロググループと記載）が登録されているエントリ（該当エントリ）があるか判断し（ステップＳ６７０）、該当エントリがあれば（ステップＳ６７０、ＹＥＳ）ステップＳ６７１に進み、該当エントリがなければ（ステップＳ６７０、ＮＯ）ステップＳ６７５に進む。
インダウト状態復旧プロセスは、ステップＳ６７１において、前記トランザクション結果問合せを送信してきたデータベース管理装置（ＤＢＭＳ）に「コミット（コミット指示）」を返信する。そして、該データベース管理装置から「該コミットの処理結果」が設定された応答を受信し（ステップＳ６７２）、該処理結果を調べ、該データベース管理装置が前記指定ロググループのコミットに失敗したか判断する（ステップＳ６７３）。そして、該コミットに成功したと判断すれば（ステップＳ６７３、ＮＯ）、コミット再送信リストから前記指定ロググループが登録されたエントリを削除し（ステップＳ６７４）、ステップＳ６７９に進む。一方、ステップＳ６７３において、前記コミットに失敗したと判断すれば（ステップＳ６７３、ＹＥＳ）、ステップＳ６７９に進む。
インダウト状態復旧プロセスは、ステップＳ６７５において、前記トランザクション結果問合せを送信してきたデータベース管理装置（ＤＢＭＳ）に「ロールバック（ロールバック指示）」を返信する。そして、ステップＳ６７９に進む。
インダウト状態復旧プロセスは、ステップＳ６７６において、コミットを依頼されたロググループをコミットする。そして、コミット処理が失敗したか判断し（ステップＳ６７６ａ）、成功していれば（ステップＳ６７８ａ、ＮＯ）ステップＳ６７７に進み、失敗していれば（ステップＳ６７６ａ、ＹＥＳ）ステップＳ６７７に進む。
インダウト状態復旧プロセスは、ステップＳ６７７において、該ロググループのログ記憶装置にコミットログを出力する。そして、該出力処理が失敗したか判断し（ステップＳ６７７ａ）、成功していれば（ステップＳ６７７ａ、ＮＯ）ステップＳ６７８に進み、失敗していれば(ステップＳ６７７ａ、ＹＥＳ)ステップＳ６７８ａに進む。
インダウト状態復旧プロセスは、ステップＳ６７８において、インダウト状態リストから、該ロググループが登録されているエントリを削除する。そして、コミット処理結果を返信し（ステップＳ６７８ａ）、ステップＳ６７９に進む。
インダウト状態復旧プロセスは、ステップＳ６７９において、インダウト状態リストが空であるか判断する。そして、インダウト状態リストが“空”であれば（ステップＳ６７９、ＹＥＳ）ステップＳ６５１に進み、インダウト状態リストが“空”でなければ、ステップＳ６５９に進む。
インダウト状態復旧プロセスは、上述したように、グローバル代表ロググループの復旧プロセスから「コミット再送信処理」を依頼され、グローバル代表ロググループ以外のロ
ググループのトランザクション復旧プロセスからは「インダウト状態の復旧」を依頼される。グローバル代表ロググループのトランザクション復旧プロセスは、グローバル代表ロググループの管理権が別のデータベース管理装置（ＤＢＭＳ）に移動するたびに生成・起動される。また、グローバル代表ロググループ以外のロググループのトランザクション復旧プロセスは、グローバル代表ロググループ以外のロググループの管理権が別のデータベース管理装置（ＤＢＭＳ）に移動するたびに生成・起動される。したがって、インダウト状態復旧プロセスは、システム内で、バックグラウンドで自動的に実行されながら、ステップＳ６４８において終了指示があったと判断するまで、システム内に常駐し、ステップＳ６４８〜Ｓ６７９の処理を繰り返し実行し続け、コミット再送信リスト及びインダウト状態リストの状態を常時監視する。また、参加者や調整者、及び他のデータベース管理装置（ＤＢＭＳ）からの「トランザクション結果問合せ」や「コミット依頼」に常時対応する。
ここで、図３２に示す状況にあるシステムでの、インダウト状態復旧プロセス２１１１、トランザクション復旧プロセス（グローバル代表ロググループのトランザクション復旧プロセス）２１１２及びトランザクション復旧プロセス（グローバル代表ロググループ以外のロググループの復旧プロセス）２１１３の動作の概要を説明する。
トランザクション復旧プロセス２１１２は、グローバル代表ロググループ１１のログ記憶装置から準備完了ログ２２０−１１を読み込み、それに設定された参加ロググループリスト（Ｇ１２、Ｇ２１，Ｇ３１、Ｇ３２）を、コミット再送信リスト１８０−２として主記憶装置に保持する。そして、グローバル代表ロググループ１１をコミット状態まで復元し、インダウト状態復旧プロセス２１１１に「コミット再送信処理」を依頼する。
トランザクション復旧プロセス２１１３は、ロググループ１２のログ記憶装置から準備完了ログ２２０−１２を読み込み、ロググループ１２をコミット状態まで復元する。そして、該準備完了ログ２２０−１２に識別子Ｇ１１が設定されたグローバル代表ロググループ１１の復旧処理を、トランザクション復旧同期タイム時間２０１０に設定されている時間だけ待つ。そして、該設定時間内に、グローバル代表ロググループ１１の復旧処理が終了すれば、グローバル代表ロググループ１１の管理権を持つデータベース管理装置（この場合、データベース管理装置２）にトランザクションの最終結果を問い合わせる。
インダウト状態復旧プロセス２１１１は、該トランザクション結果問合せを受けると、トランザクション復旧プロセス２１１３に「コミット指示」または「ロールバック指示」を返信する。トランザクション復旧プロセス２１１３は、インダウト状態復旧プロセス２１１１から「コミット指示」を受信すると、ロググループ１２をコミットし、ロググループ１２のログ記憶装置に「コミットログ（不図示）」を出力・記録する。また、「ロールバック指示」を受信すると、ロググループ１２をロールバックし、ロググループ１２のログ記憶装置に「ロールバックログ（不図示）」を出力・記録する。
インダウト状態復旧プロセス２１１１は、コミット再送信リスト１８０−２を参照し、ロググループ１２、２１、３１、３２の管理権を持つデータベース管理装置（ＤＢＭＳ）に「コミット依頼」を送信する。ロググループ１２、２１のコミット依頼はデータベー管理装置２に送信され、ロググループ３１、３２のコミット依頼はデータベース管理装置３に送信される。インダウト状態復旧プロセス２１１１は、該コミット依頼を送信したロググループの内、コミットが成功したロググループについては、コミット再送信リストからその登録エントリを削除する。また、コミットに失敗したロググループについては、その登録エントリを残す。
インダウト状態復旧プロセス２１１１は、インダウト状態リスト１７０−２にロググル
ープ１２の識別子Ｇ１２が登録されていると判断すると、グローバル代表ロググループの管理権を持つデータベース管理装置（この場合、データベース管理装置２）へトランザクションの最終結果を問い合わせる。そして、データベース管理装置２から「コミット指示」を受信すると、ロググループ１２をコミットし、ロググループ１２のログ記憶装置に「コミットログ（不図示）」を出力・記録する。また、「ロールバック指示」を受信すると、ロググループ１２をロールバックし、ロググループ１２のログ記憶装置に「ロールバックログ（不図示）」を出力・記録する。
インダウト状態復旧プロセス２１１１は、データベース管理装置２からロググループ１２のトランザクション結果問合せを、データベース管理装置３からロググループ３１、３２のトランザクション結果問合せを受信する。そして、コミット再送信リスト１８０を参照し、コミット再送信リスト１８０−２に識別子Ｇｉｋが登録されているロググループについては、該ロググループの管理権を持つデータベース管理装置（ＤＢＭＳ）に「コミット（コミット指示）」を返信する。また、コミット再送信リスト１８０−２に識別子Ｇｉｋが登録されていないロググループについては、該ロググループの管理権を持つデータベース管理装置（ＤＢＭＳ）に「ロールバック（ロールバック指示）」を返信する。そして、「コミット処理成功」の応答を受け取ったロググループについては、コミット再送信リスト１８０−２から、そのロググループの識別子Ｇｉｋを削除する。また。「コミット処理失敗」の応答を受け取ったロググループについては、コミット再送信リスト１８０−２内のそのロググループの識別子Ｇｉｋを削除しない。
本発明は、上述した実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内で種々に変形して実施することができる。
尚、上記実施形態では、主に、トランザクション結果が“コミット”である場合について説明したが、本発明は、トランザクション結果が“ロールバック”である場合も、コミットの場合とほぼ同様にして実施することが可能である。また、分散トランザクションシステムの構成例として、データベース管理装置を３台備えるシステムを取上げて説明したが、本発明は、４台以上のデータベース管理装置を備える分散トランザクションシステム１にも適用可能である。
以上の実施形態に関し、更に以下の付記を記載する。
（付記１）
データを記憶するデータ記憶装置と該データのログを記憶するログ記憶装置のパッケージであるロググループを備え、該ロググループの管理権がシステム内のデータベース管理装置間で移動可能な分散トランザクションシステムの２相コミットプロトコルにおけるインダウト状態の解決方法であって、
各ロググループに一意の識別子を付与し、各ロググループの管理権を持つデータベース管理装置に関する情報を第１のテーブルに登録するステップと、
複数のロググループが参加する分散トランザクションの２相コミットにおいて調整者となるデータベース管理装置が管理するロググループの中で代表となるロググループ（グローバル代表ロググループ）のログ記憶装置に出力される準備完了ログ（第１の準備完了ログ）に、該分散トランザクションの参加者となっているデータベース管理装置が管理するロググループの識別子のリスト（参加ロググループリスト）を記憶するステップと、
前記２相コミットにおいて参加者となるデータベース管理装置が管理するロググループのログ記憶装置に出力する準備完了ログ（第２の準備完了ログ）に、前記グローバル代表ロググループの識別子を記憶するステップと、
２相コミットのインダウト状態期間中に、前記グローバル代表ロググループの管理権が別のデータベース管理装置に移動した場合に、該グローバル代表ロググループの管理権を該別のデータベース管理装置が持つように、前記第１のテーブルを書き換えるステップと、
２相コミットのインダウト状態期間中に、前記グローバル代表ロググループ以外のロググループの管理権が別のデータベース管理装置に移動した場合に、該ロググループの管理権を該別のデータベース管理装置が持つように書き換えるステップと、
インダウト状態となっている参加者は、前記第２の準備完了ログに記憶されているグローバル代表ロググループの識別子と前記第１のテーブルを参照して、該グローバル代表ロググループの管理権を持つデータベース管理装置に、トランザクション結果の問合せを送信するステップと、
前記調整者は、インダウト状態となっている参加者からトランザクション結果の問合せを受信した場合に、前記第１の準備完了ログに記憶されているロググループの識別子のリストと前記第１のテーブルを参照して、前記参加者に該トランザクション結果を返信するステップと、
を備えることを特徴とする分散トランザクションの２相コミットにおけるインダウト状態の解決方法。
（付記２）
付記１記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
さらに、
調整者は、
前記第１の準備完了ログに記憶されている識別子のリストと前記第１のテーブルを基に、該識別子とコミット指示またはロールバック指示が設定された通知を、該識別子を有するロググループを管理している参加者に送信し、該参加者に該ロググループのコミットまたはロールバックを依頼するステップと、
前記コミット依頼通知を受信した参加者がコミットに失敗した場合には、該参加者が管理している全ての更新ロググループの識別子のリスト（コミット再送信リスト）を記憶するステップを備え、
参加者は、調整者から前記コミットまたはロールバック依頼の通知を受信した場合には、前記第１のテーブルを参照して、該依頼に対する処理結果の応答を、該調整者に送信するステップを備える。
（付記３）
付記１記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
さらに、
調整者が分散トランザクションにおいて自装置のロググループのデータを更新する場合の２相コミットの準備処理において、
調整者は、
参加者に対して、前記グローバル代表ロググループの識別子が設定された準備処理依頼の通知を送信するステップと、
該準備処理依頼通知を送信した参加者から準備処理成功の応答を受信した場合には、該応答から該参加者が更新したロググループの識別子を取得し、該識別子を該参加者に関連付けて記憶するステップと、
調整者が管理するグローバル代表ロググループ以外のロググループについてトランザクション準備処理を行い、グローバル代表ロググループの識別子が設定された準備完了ログを、該ロググループのログ記憶装置に出力するステップと、
を備え、
参加者は、
調整者から前記準備依頼の通知を受信すると、前記準備依頼通知から前記グローバル代表ロググループを取り出すステップと、
自装置が管理するロググループの準備処理を行い、該準備処理に成功したロググループのログ記憶装置には、前記取り出したグローバル代表ロググループの識別子を設定した準備完了ログを、自装置が管理しているロググループのログ記憶装置に出力するステップと
、
該準備完了ログを前記ログ記憶装置に出力する処理に成功した場合には、前記準備処理に成功したロググループの識別子をインダウト状態リストに登録し、調整者に準備成功した全ロググループ識別子を送信するステップを備える。
（付記４）
付記３記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
さらに、
前記準備処理終了後の２相コミットのコミット処理において、
調整者は、
参加者にコミット依頼を送信するステップと、
該コミット依頼を送信した参加者のコミットが失敗したと判断した場合には、該参加者が管理している全ての更新ロググループの識別子を、前記グローバル代表ロググループのログ記憶装置に出力するステップと、
自装置が管理するグローバル代表ロググループ以外の更新ロググループのコミット処理を実行するステップと、
コミットに成功した更新ロググループについては、その更新ロググループのログ記憶装置にコミットログを出力し、コミットに失敗した更新ロググループについては、その更新ロググループの識別子をグローバル代表ロググループのログ記憶装置に出力するステップと、
グローバル代表ロググループのコミット処理を実行するステップと、
該グローバル代表ロググループのコミットログを、該グローバル代表ロググループのログ記憶装置に出力するステップを備え、
参加者は、
調整者から前記コミット依頼をすると、自装置が管理する全ての更新ロググループについてコミット処理を実行するステップと、
コミットに成功した更新ロググループについては、その識別子を前記インダウト状態リストから削除し、コミット完了の応答を調整者に送信するステップと、
コミットに失敗した更新ロググループについては、コミット失敗の応答を調整者に送信するステップを備える。
（付記５）
付記３記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
さらに、
調整者がダウンした場合、
参加者は、
前記インダウト状態リストに更新ロググループの識別子が登録されている場合には、グローバル代表ロググループの管理権を持つ参加者に対して、トランザクション結果の問合せ通知を送信するステップと、
該トランザクション結果の問合せに対する調整者の応答を受信し、該応答がコミット指示であれば、前記インダウト状態リストに登録されている更新ロググループについてコミット処理と該更新ロググループのログ記憶装置へのコミットログの出力を行い、該応答がロールバック指示であれば、前記インダウト状態リストに登録されている更新ロググループについてロールバック処理該更新ロググループのログ記憶装置へのロールバックログの出力を行うステップと、
を備える。
（付記６）
付記１記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
さらに、
調整者が分散トランザクションにおいて自装置のロググループのデータを更新しない場合の２相コミットの準備処理において、
調整者は
参加者の中から代表参加者を決定するステップと、
該代表参加者が管理するロググループの中からグローバル代表ロググループを決定するステップと、
代表参加者以外の参加者である一般参加者に準備処理依頼の通知を送信する際に、該通知に前記グローバル代表ロググループの識別子を設定するステップと、
代表参加者に準備処理依頼の通知を送信する際に、該通知に全ての前記一般参加者が管理する全てのロググループの識別子と、代表参加者に決定された旨を示す情報を設定するステップを備え、
一般参加者は、
調整者から前記準備依頼の通知を受信すると、前記準備依頼通知から前記グローバル代表ロググループの識別子を取得するステップと、
自装置が管理するロググループの準備処理を行い、該準備処理に成功したロググループについては、そのログ記憶装置に、前記取得したグローバル代表ロググループの識別子を設定した準備完了ログを出力するステップと、
該準備完了ログを前記ログ記憶装置に出力する処理に成功した場合には、前記準備処理に成功したロググループの識別子をインダウト状態リストに登録するステップを備え、
代表参加者は、
前記調整者から前記準備依頼通知を受信すると、該通知から前記全ての一般参加者の全ロググループの識別子を取得・記憶するステップと、
自装置が管理するグローバル代表ロググループ以外のロググループの準備処理を行い、該準備処理に成功したロググループについては、そのログ記憶装置に、前記取得したグローバル代表ロググループの識別子を設定した準備完了ログを出力するステップと、
グローバル代表ロググループの準備処理を行い、該準備処理に成功した場合には、グローバル代表ロググループのログ記憶装置に、前記取得した全ての一般参加者の全ロググループの識別子を設定した準備完了ログを出力し、調整者に準備成功した全ロググループ識別子を送信するステップと、
調整者に対して、上記準備処理の結果を通知する応答を送信するステップを備える。
（付記７）
付記６記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
さらに、
前記準備処理終了後の２相コミットのコミット処理において、
調整者は
一般参加者にコミット依頼の通知を送信するステップと、
該コミット依頼の通知を送信した一般参加者がコミットに失敗したか判断するステップと、
コミットに失敗した全ての一般参加者の全更新ロググループの識別子を設定したコミット依頼の通知を、代表参加者に送信するステップを備え、
一般参加者は、
調整者から前記コミット依頼の通知を受信すると、自装置が管理する全ての更新ロググループについてコミット処理を実行するステップと、
コミットに成功した更新ロググループについては、その識別子を前記インダウト状態リストから削除し、コミット完了の応答を調整者に送信するステップと、
コミットに失敗した更新ロググループについては、コミット失敗の応答を調整者に送信するステップを備え、
代表参加者は、
調整者から前記コミット依頼通知を受信すると、そのコミット依頼通知に設定されてい
る全ての識別子を取得するステップと、
該取得した全ての識別子を、グローバル代表ロググループのログ記憶装置に出力するステップと、
自装置の全ての更新ロググループについてコミット処理を実行し、コミットに失敗した更新ロググループの識別子の一覧を、グローバル代表ロググループのログ記憶装置にコミット再送信リストとして記憶するステップと、
グローバル代表ロググループのコミット処理を実行し、そのコミットログをグローバル代表ロググループのログ記憶装置に出力するステップと、
調整者に、コミット完了の応答を送信するステップを備える。
（付記８）
付記６記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
さらに、
調整者がダウンした場合、
一般参加者は、
前記インダウト状態リストに更新ロググループの識別子が登録されている場合には、グローバル代表ロググループの管理権を持つ参加者に対して、トランザクション結果の問合せ通知を送信するステップと、
該トランザクション結果の問合せに対する調整者の応答を受信し、該応答がコミット指示であれば、前記インダウト状態リストに登録されている更新ロググループについてコミット処理と該更新ロググループのログ記憶装置へのコミットログの出力を行い、該応答がロールバック指示であれば、前記インダウト状態リストに登録されている更新ロググループについてロールバック処理該更新ロググループのログ記憶装置へのロールバックログの出力を行うステップと、
を備える。
（付記９）
付記６記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
さらに、
調整者がダウンした場合、
代表参加者は、
グローバル代表ロググループが準備完了ログ後の状態である場合には、更新ロググループの管理権を持つ一般参加者に対してコミット依頼を送信するステップと、
グローバル代表ロググループが準備完了後の状態でない場合には、更新ロググループの管理権を持つ一般参加者にロールバック依頼を送信するステップと、
グローバル代表ロググループが準備完了後の状態であるときは、代表参加者の更新ロググループのコミット処理とコミットログの該更新ロググループのログ記憶装置への出力を行うステップと、
グローバル代表ロググループが準備完了後の状態の状態でないときは、代表参加者の更新ロググループについてロールバック処理とロールバックログの該更新ロググループのログ記憶装置に対する出力を行うステップと、
を備える。
（付記１０）
付記３または６記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
さらに、
グローバル代表ロググループ以外のロググループの管理権を取得したデータベース管理装置は、
前記管理権を取得したロググループのログ記憶装置に準備完了ログだけが記憶されているか判断し、該準備完了ログだけが記憶されていれば、該ロググループを前記インダウト
状態リストに登録するステップと、
前記準備完了ログからグローバル代表ロググループを取得し、該グローバル代表ロググループの管理権を持つデータベース管理装置に対してトランザクション結果の問合せを送信するステップと、
該グローバル代表ロググループの管理権を持つデータベース管理装置から該トランザクション結果の問合せに対する応答を受信し、その応答がコミット指示であれば、前記管理権を取得したロググループについてコミット処理と該ロググループのログ記憶装置へのコミットログの出力を行い、上記応答がロールバック指示であれば、前記管理権を取得したロググループについてロールバック処理と該ロググループのログ記憶装置へのロールバックログの出力を行うステップと、
前記管理権を取得したロググループを前記インダウト状態リストから削除するステップと、
備える。
（付記１１）
付記３また６記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
さらに、
グローバル代表ロググループの管理権を取得したデータベース管理装置は、
該グローバル代表ロググループのログ記憶装置にコミット再送信リストが存在すれば、そのコミット再送信リストをログ記憶装置から読み込み・記憶するステップと、
該グローバル代表ロググループのログ記憶装置にコミット再送信リストが存在せず、かつ、準備完了ログのみが記憶されていれば、該準備完了ログに設定されている識別子を取得して、該識別子の一覧をコミット再送信リストとして記憶するステップと、
インダウト状態リストから削除するステップと、
を備える。
（付記１２）
付記１記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
さらに、
各データベース管理装置は、
他のデータベース管理装置がダウンしたこと旨の通知を受信するステップと、
前記第１のテーブルを参照して、該ダウンしたデータベース管理装置が管理していたロググループの識別子を取得するステップと、
該取得したロググループの識別子と該ロググループの管理権を持つデータ記憶装置の優先順位を基に、該ダウンしたデータ記憶装置は管理していたロググループの中から自装置が引き継ぐべきロググループを特定するステップと、
前記ダウンしたデータ記憶装置が管理していたロググループの管理権を引き継いだ場合には、該ロググループを復旧するステップと、
を備える。
（付記１３）
付記１記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
さらに、
調整者となるデータベース管理装置は、参加者となるデータベース管理装置の識別情報が登録されたリスト（参加者リスト）を備える。
本発明を適用した分散トランザクションシステムの一形態を示す図である。 本発明を適用した分散トランザクションシステムの別の形態を示す図である。 データベース管理装置がダウンした場合のロググループの管理権の移動によるシステム構成の変化を示す図である。 各データベース管理装置の主記憶装置内に記憶されるトランザクション完了ログ出力先の優先順位定義表と、外部記憶装置に記憶されるトランザクション完了ログ出力先の優先順位定義ファイルを示す図である。 分散トランザクションにおける調整者のデータ更新処理を示すフローチャートである。 分散トランザクションにおける参加者のデータ更新処理を示すフローチャートである。 図５及び図６のフローチャートに示す処理による、分散トランザクションシステムにおけるデータ更新処理の一例を示すシステム構成図である。 調整者となるデータベース管理装置がロググループを備えていない場合の分散トランザクションにおける処理を示すシステム構成図である。 本実施形態における２相コミット処理の全体の流れを示すフローチャートである。 調整者で更新が有る場合の調整者の準備処理を示すフローチャートである。 調整者で更新が有る場合の参加者の準備処理を示すフローチャートである。 図４に示す分散トランザクションシステムにおいて、２相コミットのトランザクション準備処理が行われた場合のシステムの構成状態を示す図である。 調整者で更新がある場合の調整者のコミット処理を示すフローチャートである。 調整者で更新が有る場合の参加者のコミット処理を示すフローチャートである。 図１２に示すインダウト状態にある分散トランザクションシステムにおいて、図１３及び図１４のフローチャートに示すコミット処理が行われた場合における、該分散トランザクションシステムの状態の遷移を示すシステム構成図（その１）である。 図１２に示すインダウト状態にある分散トランザクションシステムにおいて、上述した図１３及び図１４のフローチャートに示すコミット処理が行われた場合における、該分散トランザクションシステムの状態の遷移を示すシステム構成図（その２）である。 図１２に示すように、参加者がインダウト状態であるときに、調整者が障害によりダウンした場合の参加者の処理を示すフローチャートである。 グローバル代表ロググループ表以外のロググループの管理権を取得したデータベース管理装置（ＤＢＭＳ）のトランザクション解決処理を示すフローチャートである。 グローバル代表ロググループの管理権を取得したデータベース管理装置のトランザクション解決処理を示すフローチャートである。 調整者で更新が有る場合に、調整者がダウンした場合のシステム状況の一例を示す図である。 調整者で更新が無い場合の調整者の準備処理を示すフローチャートである。 調整者で更新が無い場合の代表参加者の準備処理を示すフローチャートである。 図２１及び図２２のフローチャートの処理が実行された場合の分散トランザクションシステムの状況の一例を示す図である。 調整者で更新が無い場合の調整者のコミット処理を示すフローチャートである。 調整者で更新が無い場合の代表参加者のコミット処理を示すフローチャートである。 調整者で更新が無い分散トランザクションシステムにおいてのコミット処理が行われた場合のシステム状況（その１）を示す図である。 調整者で更新が無い分散トランザクションシステムにおいてのコミット処理が行われた場合のシステム状況（その２）を示す図である。 調整者で更新が無い分散トランザクションにおいて、調整者がダウンした時の一般参加者の処理を示すフローチャートである。 調整者で更新が無い分散トランザクションにおいて、調整者がダウンした時の代表参加者の処理を示すフローチャートである。 調整者で更新が無い場合に、調整者がダウンした場合のシステム状況を示す図である。 クラスタ管理装置がシステム内の、あるデータベース管理装置のダウンを検知した場合の他のデータベース管理装置の動作を示すフローチャートである。 調整者、第１の参加者及び第２の参加者を備える分散トランザクションシステムにおいて、調整者がダウンした場合のシステム復旧処理を説明するシステム構成図である。 グローバル代表ロググループのトランザクション復旧プロセスの処理を示すフローチャートである。 グローバル代表ロググループ以外のロググループのトランザクション復旧プロセスの処理を示すフローチャートである。 インダウト状態復旧プロセスの処理を示すフローチャートである。
符号の説明
１〜５ 分散トランザクションシステム
１００、１００´ データベース管理装置
１１０、１１０´、１１０Ａ ロググループ偏在表
１２０ トランザクション完了ログ出力先の優先順位定義表
１３０ 更新ロググループリスト
１４０ ローカル代表ロググループ記憶表
１５０ 参加者リスト
１７０ インダウト状態リスト
１８０ コミット再送信リスト
１９０ 代表参加者記憶表
１０１０ 代表参加者フラグ
１０２０ 全一般参加者の全更新ロググループリスト
２０１０ トランザクション復旧同期タイム時間
２１１１ インダウト状態復旧プロセス
２１１２ トランザクション復旧プロセス（グローバル代表ロググループのトランザクション復旧プロセス）
２１１３ トランザクション復旧プロセス（グローバル代表ロググループ以外のロググループのトランザクション復旧プロセス）
２００ ロググループ
２０１ ログ記憶装置
２２０ 準備完了ログ
２３０ コミットログ
２０２ データ記憶装置
３００、３００´ 管理権の優先順位定義ファイル
３１０ トランザクション完了ログ出力先の優先順位定義ファイル
３２０ トランザクション復旧同期タイム時間設定ファイル
５０１〜５０３、６０１、６０２ 更新依頼パケット
５５１〜５５３、６５１、６５２ 更新応答パケット
７０１、７０２、１７１１、１７１２、２００１、２００２ コミット依頼パケット
７５１、７５２、１７５１、１７５２、１７６１、２０５１、２０５２ コミット応答パケット
１６０１、１６０２ 準備依頼パケット
１６５１、１６５２ 準備完了応答パケット
１７０１、１８０１、１８０２ トランザクション結果の問合せ依頼パケット
１７５１、１８５１、１８５２ コミット指示の応答パケット
２００２ ＤＢＭＳ１ダウン通知

Claims (7)

  1. データを記憶するデータ記憶装置と該データのログを記憶するログ記憶装置のパッケージであるロググループを備え、該ロググループの管理権がシステム内のデータベース管理装置間で移動可能な分散トランザクションシステムの２相コミットプロトコルにおけるインダウト状態の解決方法であって、
    各ロググループに一意の識別子を付与し、各ロググループの管理権を持つデータベース管理装置に関する情報を第１のテーブルに登録するステップと、
    複数のロググループが参加する分散トランザクションの２相コミットにおいて調整者となるデータベース管理装置が管理するロググループの中で代表となるロググループ（グローバル代表ロググループ）のログ記憶装置に出力される準備完了ログ（第１の準備完了ログ）に、該分散トランザクションの参加者となっているデータベース管理装置が管理するロググループの識別子のリスト（参加ロググループリスト）を記憶するステップと、
    前記２相コミットにおいて参加者となるデータベース管理装置が管理するロググループのログ記憶装置に出力する準備完了ログ（第２の準備完了ログ）に、前記グローバル代表ロググループの識別子を記憶するステップと、
    ２相コミットのインダウト状態期間中に、前記グローバル代表ロググループの管理権が別のデータベース管理装置に移動した場合に、該グローバル代表ロググループの管理権を該別のデータベース管理装置が持つように、前記第１のテーブルを書き換えるステップと、
    ２相コミットのインダウト状態期間中に、前記グローバル代表ロググループ以外のロググループの管理権が別のデータベース管理装置に移動した場合に、該ロググループの管理権を該別のデータベース管理装置が持つように書き換えるステップと、
    インダウト状態となっている参加者は、前記第２の準備完了ログに記憶されているグローバル代表ロググループの識別子と前記第１のテーブルを参照して、該グローバル代表ロググループの管理権を持つデータベース管理装置に、トランザクション結果の問合せを送信するステップと、
    前記調整者は、インダウト状態となっている参加者からトランザクション結果の問合せを受信した場合に、前記第１の準備完了ログに記憶されているロググループの識別子のリストと前記第１のテーブルを参照して、前記参加者に該トランザクション結果を返信するステップと、
    を備えることを特徴とする分散トランザクションの２相コミットにおけるインダウト状態の解決方法。
  2. 請求項１記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
    さらに、
    調整者は、
    前記第１の準備完了ログに記憶されている識別子のリストと前記第１のテーブルを基に、該識別子とコミット指示が設定されたコミット依頼通知、または、前記識別子とロールバック指示が設定されたロールバック依頼通知を、該識別子を有するロググループを管理している参加者に送信し、該参加者に該ロググループのコミットまたはロールバックを依頼するステップと、
    前記コミット依頼通知を受信した参加者がコミットに失敗した場合には、該参加者が管理している全ての更新ロググループの識別子のリスト（コミット再送信リスト）を記憶するステップを備え、
    参加者は、調整者から前記コミット依頼通知または前記ロールバック依頼通知を受信した場合には、前記第１のテーブルを参照して、該依頼に対する処理結果の応答を、該調整者に送信するステップを備える。
  3. 請求項１記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
    さらに、
    調整者が分散トランザクションにおいて自装置のロググループのデータを更新する場合の２相コミットの準備処理において、
    調整者は、
    参加者に対して、前記グローバル代表ロググループの識別子が設定された準備処理依頼の通知を送信するステップと、
    該準備処理依頼通知を送信した参加者から準備処理成功の応答を受信した場合には、該応答から該参加者が更新したロググループの識別子を取得し、該識別子を該参加者に関連付けて記憶するステップと、
    調整者が管理するグローバル代表ロググループ以外のロググループについてトランザクション準備処理を行い、グローバル代表ロググループの識別子が設定された準備完了ログを、該ロググループのログ記憶装置に出力するステップと、
    を備え、
    参加者は、
    調整者から前記準備依頼の通知を受信すると、前記準備依頼通知から前記グローバル代表ロググループを取り出すステップと、
    自装置が管理するロググループの準備処理を行い、該準備処理に成功したロググループのログ記憶装置には、前記取り出したグローバル代表ロググループの識別子を設定した準備完了ログを、自装置が管理しているロググループのログ記憶装置に出力するステップと、
    該準備完了ログを前記ログ記憶装置に出力する処理に成功した場合には、前記準備処理に成功したロググループの識別子をインダウト状態リストに登録し、調整者に準備成功した全ロググループ識別子を送信するステップを備える。
  4. 請求項３記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
    さらに、
    前記準備処理終了後の２相コミットのコミット処理において、
    調整者は、
    参加者にコミット依頼を送信するステップと、
    該コミット依頼を送信した参加者のコミットが失敗したと判断した場合には、該参加者が管理している全ての更新ロググループの識別子を、前記グローバル代表ロググループのログ記憶装置に出力するステップと、
    自装置が管理するグローバル代表ロググループ以外の更新ロググループのコミット処理を実行するステップと、
    コミットに成功した更新ロググループについては、その更新ロググループのログ記憶装置にコミットログを出力し、コミットに失敗した更新ロググループについては、その更新ロググループの識別子をグローバル代表ロググループのログ記憶装置に出力するステップと、
    グローバル代表ロググループのコミット処理を実行するステップと、
    該グローバル代表ロググループのコミットログを、該グローバル代表ロググループのログ記憶装置に出力するステップを備え、
    参加者は、
    調整者から前記コミット依頼をすると、自装置が管理する全ての更新ロググループについてコミット処理を実行するステップと、
    コミットに成功した更新ロググループについては、その識別子を前記インダウト状態リストから削除し、コミット完了の応答を調整者に送信するステップと、
    コミットに失敗した更新ロググループについては、コミット失敗の応答を調整者に送信するステップを備える。
  5. 請求項３記載の分散トランザクションの２相コミットにおけるインダウト状態の解決方法であって、
    さらに、
    調整者がダウンした場合、
    参加者は、
    前記インダウト状態リストに更新ロググループの識別子が登録されている場合には、グローバル代表ロググループの管理権を持つ参加者に対して、トランザクション結果の問合せ通知を送信するステップと、
    該トランザクション結果の問合せに対する調整者の応答を受信し、該応答がコミット指示であれば、前記インダウト状態リストに登録されている更新ロググループについてコミット処理と該更新ロググループのログ記憶装置へのコミットログの出力を行い、該応答がロールバック指示であれば、前記インダウト状態リストに登録されている更新ロググループについてロールバック処理該更新ロググループのログ記憶装置へのロールバックログの出力を行うステップと、
    を備える。
  6. データを記憶するデータ記憶装置と該データのログを記憶するログ記憶装置の組を複数備え、かつ、複数の前記組を管理する管理装置を複数備えた分散トランザクションシステムのインダウト状態の解決方法であって、
    分散トランザクションにおいて、トランザクションの開始要求を受けた管理装置が管理する組の中に含まれる代表の組のログ記憶装置に出力される第１のログに、該分散トランザクションに関与する管理装置それぞれが管理する組を識別する識別情報を対応付けて記憶し、
    関与する前記管理装置のうち、前記要求を受けた管理装置以外の管理装置が管理する組のログ記憶装置に出力する第２のログに、前記代表の組の識別情報を対応付けて記憶し、
    インダウト状態期間中に、前記代表の組を管理する管理装置が前記要求を受けた管理装置と異なる管理装置に変更された場合、複数の前記組それぞれについて当該組を管理する管理装置に関する情報が登録された第１のテーブルを、前記代表の組の管理を前記異なる管理装置が行なう旨に更新し、
    インダウト状態の前記関与する管理装置は、前記第２のログに記憶されている前記代表の組の識別情報と前記第１のテーブルとに基づいて、前記代表の組を管理する前記異なる管理装置に、トランザクション結果の問合せを送信し、
    前記要求受けた管理装置は、前記第１のログに記憶されている識別情報と前記第１のテーブルとに基づいて、トランザクション結果の問合せを送信したインダウト状態の前記関与する管理装置にトランザクション結果を送信する、
    ことを特徴とする解決方法。
  7. 前記解決方法は、
    インダウト状態期間中に、前記代表の組以外の組を管理する管理装置が変更された場合に、前記第１のテーブルを、当該組を管理していた管理装置と異なる管理装置が行なう旨に更新する、
    ことを特徴とする請求項６記載の解決方法。
JP2008134840A 2008-05-22 2008-05-22 分散トランザクションの２相コミットプロトコルにおけるインダウト状態の解決方法 Active JP5223457B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2008134840A JP5223457B2 (ja) 2008-05-22 2008-05-22 分散トランザクションの２相コミットプロトコルにおけるインダウト状態の解決方法
US12/389,979 US8185493B2 (en) 2008-05-22 2009-02-20 Solution method of in-doubt state in two-phase commit protocol of distributed transaction
US13/466,558 US8433676B2 (en) 2008-05-22 2012-05-08 Solution method of in-doubt state in two-phase commit protocol of distributed transaction

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008134840A JP5223457B2 (ja) 2008-05-22 2008-05-22 分散トランザクションの２相コミットプロトコルにおけるインダウト状態の解決方法

Publications (2)

Publication Number Publication Date
JP2009282790A JP2009282790A (ja) 2009-12-03
JP5223457B2 true JP5223457B2 (ja) 2013-06-26

Family

ID=41342855

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008134840A Active JP5223457B2 (ja) 2008-05-22 2008-05-22 分散トランザクションの２相コミットプロトコルにおけるインダウト状態の解決方法

Country Status (2)

Country Link
US (2) US8185493B2 (ja)
JP (1) JP5223457B2 (ja)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8266126B2 (en) * 2010-03-24 2012-09-11 Matrixx Software, Inc. System with multiple conditional commit databases
US9665392B2 (en) 2012-03-16 2017-05-30 Oracle International Corporation System and method for supporting intra-node communication based on a shared memory queue
US9760584B2 (en) 2012-03-16 2017-09-12 Oracle International Corporation Systems and methods for supporting inline delegation of middle-tier transaction logs to database
US9146944B2 (en) * 2012-03-16 2015-09-29 Oracle International Corporation Systems and methods for supporting transaction recovery based on a strict ordering of two-phase commit calls
EP2926252B1 (en) * 2012-11-28 2020-02-26 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for managing distributed transactions
US9384229B2 (en) 2012-11-29 2016-07-05 International Business Machines Corporation Data readiness using initiator region last commit selection
US9473545B2 (en) * 2013-09-13 2016-10-18 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Administering group identifiers of processes in a parallel computer
US10203981B2 (en) * 2014-02-28 2019-02-12 Red Hat, Inc. Systems and methods for prepare list communication to participants in two-phase commit protocol transaction processing
CN105893395B (zh) * 2015-01-26 2019-04-02 阿里巴巴集团控股有限公司 分布式事务的消息回查方法及其系统
US10289444B2 (en) 2015-10-05 2019-05-14 International Business Machines Corporation Client controlled transaction processing involving a plurality of participants
US10795881B2 (en) * 2015-12-18 2020-10-06 Sap Se Table replication in a database environment
US10235440B2 (en) * 2015-12-21 2019-03-19 Sap Se Decentralized transaction commit protocol
US10572510B2 (en) 2015-12-21 2020-02-25 Sap Se Distributed database transaction protocol
CN106302995A (zh) * 2016-07-29 2017-01-04 维沃移动通信有限公司 一种注册信息的获取方法及移动终端
CN107182041A (zh) * 2017-05-09 2017-09-19 王恩惠 通过短信管理手机号绑定与注册过网站或应用方法及装置
US10977227B2 (en) 2017-06-06 2021-04-13 Sap Se Dynamic snapshot isolation protocol selection
US11112970B2 (en) * 2017-06-12 2021-09-07 Sap Se Software system logging based on runtime analysis
US10666495B2 (en) * 2017-08-22 2020-05-26 International Business Machines Corporation Transaction processing
RU2718215C2 (ru) 2018-09-14 2020-03-31 Общество С Ограниченной Ответственностью "Яндекс" Система обработки данных и способ обнаружения затора в системе обработки данных
RU2714219C1 (ru) 2018-09-14 2020-02-13 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для планирования передачи операций ввода/вывода
RU2731321C2 (ru) 2018-09-14 2020-09-01 Общество С Ограниченной Ответственностью "Яндекс" Способ определения потенциальной неисправности запоминающего устройства
RU2714602C1 (ru) 2018-10-09 2020-02-18 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для обработки данных
RU2721235C2 (ru) 2018-10-09 2020-05-18 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для маршрутизации и выполнения транзакций
RU2711348C1 (ru) 2018-10-15 2020-01-16 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для обработки запросов в распределенной базе данных
US11874816B2 (en) * 2018-10-23 2024-01-16 Microsoft Technology Licensing, Llc Lock free distributed transaction coordinator for in-memory database participants
RU2714373C1 (ru) 2018-12-13 2020-02-14 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для планирования выполнения операций ввода/вывода
RU2749649C2 (ru) 2018-12-21 2021-06-16 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для планирования обработки операций ввода/вывода
RU2720951C1 (ru) 2018-12-29 2020-05-15 Общество С Ограниченной Ответственностью "Яндекс" Способ и распределенная компьютерная система для обработки данных
US11314623B2 (en) * 2019-01-23 2022-04-26 Red Hat, Inc. Software tracing in a multitenant environment
RU2746042C1 (ru) 2019-02-06 2021-04-06 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для передачи сообщения
CN111858629B (zh) 2020-07-02 2023-08-22 北京奥星贝斯科技有限公司 二阶段提交分布式事务更新数据库的实现方法和装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS638845A (ja) 1986-06-28 1988-01-14 Fujitsu Ltd 更新処理方式
US5333303A (en) * 1991-03-28 1994-07-26 International Business Machines Corporation Method for providing data availability in a transaction-oriented system during restart after a failure
JP3594248B2 (ja) 1993-03-30 2004-11-24 富士通株式会社 ログデータの分類取得システム
JP3094888B2 (ja) * 1996-01-26 2000-10-03 三菱電機株式会社 採番機構、データ整合性確認機構、トランザクション再実行機構及び分散トランザクション処理システム
US7076508B2 (en) * 2002-08-12 2006-07-11 International Business Machines Corporation Method, system, and program for merging log entries from multiple recovery log files

Also Published As

Publication number Publication date
US8185493B2 (en) 2012-05-22
JP2009282790A (ja) 2009-12-03
US20090292744A1 (en) 2009-11-26
US8433676B2 (en) 2013-04-30
US20120221537A1 (en) 2012-08-30

Similar Documents

Publication Publication Date Title
JP5223457B2 (ja) 分散トランザクションの２相コミットプロトコルにおけるインダウト状態の解決方法
JP6564026B2 (ja) マルチテナントアプリケーションサーバ環境におけるトランザクション回復のためのシステムおよび方法
JP5841177B2 (ja) マルチサーバ予約システムにおける同期化メカニズムのための方法及びシステム
US6934247B2 (en) Recovery following process or system failure
US10942823B2 (en) Transaction processing system, recovery subsystem and method for operating a recovery subsystem
US8055735B2 (en) Method and system for forming a cluster of networked nodes
JP6220851B2 (ja) ２フェーズコミットコールの厳密な順序付けに基づいたトランザクションリカバリをサポートするためのシステムおよび方法
US20170177617A1 (en) Three phase commit for a distributed file system
CN103297268A (zh) 基于p2p技术的分布式数据一致性维护系统和方法
CN108958984B (zh) 基于ceph的双活同步在线热备方法
US20190258646A1 (en) Distributed transactions across multiple consensus groups
US9760529B1 (en) Distributed state manager bootstrapping
CN111538763A (zh) 一种确定集群中主节点的方法、电子设备和存储介质
CN107919977A (zh) 一种基于Paxos协议的分布式一致性系统的在线扩容、在线缩容的方法和装置
WO2022037268A1 (zh) 一种容器管理方法、设备以及介质
CN110825763B (zh) 基于共享存储的MySQL数据库高可用系统及其高可用方法
CN109144748B (zh) 一种服务器、分布式服务器集群及其状态驱动方法
JP2006012004A (ja) ホットスタンバイシステム
JP3846852B2 (ja) 分散コンピューティング環境の処理グループを管理する方法、システム、およびプログラム製品
JP5900094B2 (ja) データ整合システム、データ整合方法およびデータ整合プログラム
JP2005502957A (ja) 厳密に一回のキャッシュフレームワーク
JP5480046B2 (ja) 分散トランザクション処理システム、装置、方法およびプログラム
CN114363350B (zh) 一种服务治理系统及方法
US20220138177A1 (en) Fault tolerance for transaction mirroring
JP2011002970A (ja) 分散データ管理システム、データ管理装置、データ管理方法、およびプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110118

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121113

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130115

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130212

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130225

R150 Certificate of patent or registration of utility model

Ref document number: 5223457

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160322

Year of fee payment: 3