JPH08286964A - 分散トランザクション処理方法 - Google Patents

Abstract

(57)【要約】 【目的】 ２フェーズコミット処理のフェーズ２でのデ
ータ実更新時にエラーが発生した場合の、各データ管理
システム間のデータの不整合を防止する。 【構成】 フェーズ２の各ＲＭのデータ実更新のあと、
すぐには各ＲＭのログバッファ、ロック管理テーブルを
解放せず、一旦ＴＭにおいて各ＲＭの各データ実更新の
成否を確認する（Ｓ４１）。もし、１つでも実更新に失
敗してロールバックしたＲＭがあれば、ＴＭが、実更新
に成功したＲＭに対してロールバックを要求する（Ｓ５
７）。ロールバック要求を受けた各ＲＭは、保持してい
たログバッファ及びロック管理テーブルを用いてロール
バック処理を行う。この結果、データ実更新時に一部の
ＲＭでエラーが発生した場合でも、分散システムのデー
タの一貫性を保つことができる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、分散トランザクショ
ン処理方法に関するものである。

【０００２】

【従来の技術】ネットワーク等に分散する複数のデータ
ベース等のリソースを、１つのトランザクションにおい
て同時に更新する場合に、１つでも更新できないリソー
スがあると、更新に成功したリソースと失敗したリソー
スとでデータに矛盾が生じ、分散システム全体としての
データの一貫性（整合性）が保たれなくなる。このよう
なリソース間のデータの矛盾を防止するためには、すべ
てのリソースの更新が成功した場合に限って分散システ
ム全体の更新を確定し、１つでも更新に失敗したリソー
スがあった場合には、更新されたリソースも含め分散シ
ステム全体を更新前の状態に戻す（ロールバックす
る）、という制御が必要になる。

【０００３】このような複数リソースの同期更新を矛盾
なく行うための分散トランザクション処理方法として、
２フェーズコミット処理がある。

【０００４】２フェーズコミット処理は、２つの段階
（フェーズ）からなっている。すなわち、第１段階（フ
ェーズ１）では、まずアプリケーションプログラム等か
らコミット要求があった際に、トランザクションの処理
を管理するトランザクション・マネージャ（以下、「Ｔ
Ｍ」と略す）が、各リソースを管理するリソース・マネ
ージャ（以下、「ＲＭ」と略す）に対して、コミットが
できるか否か（すなわち、リソースの実更新が保証され
ているか）を確認する要求を行う。なお、コミット(com
mitment)とは、トランザクションが行った共有リソース
の更新を確定する処理をいう。そして、この要求に応じ
て、各ＲＭが、コミット準備がＯＫか否か（すなわち、
コミットができるか否か）の通知をＴＭに対して行う。

【０００５】次に、第２段階（フェーズ２）では、フェ
ーズ１の各ＲＭからの通知において、すべてのＲＭのコ
ミット準備ができているならば、ＴＭは、各ＲＭに対し
てコミット処理（更新の確定）を要求する。一方、１つ
でもコミット準備のできていないＲＭがあるならば、Ｔ
Ｍは、各ＲＭに対し、更新前の状態に戻すロールバック
処理を要求する。なお、各ＲＭに対する各フェーズの処
理要求は、一般的にＴＭにより管理されている。

【０００６】また、２フェーズコミット処理によれば、
システムダウン等の障害時においても、ＴＭ及び各ＲＭ
により採取されるログ情報により、整合性のとれた状態
に回復することができる。

【０００７】以下、このような２フェーズコミット処理
を用いた従来の分散トランザクション処理方法として、
X/Open Companyが出版している "X/Open CAE Specifica
tionDistributed Transaction Processing:The XA Spec
ification" 及び "X/OpenGuide Distributed Transacti
on Processing Reference Model" に基づく処理方法
を、図面を参照して説明する。

【０００８】図１は、例えば分散データベースシステム
等、２フェーズコミット処理を行う対象となるシステム
の構成の一例を示す図である。ここでは、説明を簡略化
するため、２つのＲＭからなるシステムを例として取り
上げている。

【０００９】図１において、ＲＭ１及び２には、それぞ
れＲＭの処理に関するログ情報を一時的に保持するログ
バッファ３及び４と、ＲＭで処理する実データを一時的
に保持するデータバッファ５及び６とが接続されてい
る。ログバッファ３及び４は、ディスク上のログ領域９
及び１０にそれぞれ接続されており、それらログバッフ
ァ上のログ情報は、最終的にはログ領域９及び１０にそ
れぞれ格納される。また、データバッファ５及び６は、
ディスク上のデータ領域１１及び１２に接続されてい
る。さらに、ＲＭ１及びＲＭ２は、データの整合性が失
われないようにするための排他制御の管理情報を格納す
るロック管理テーブル７及び８にそれぞれ接続されてい
る。

【００１０】各ＲＭ１及びＲＭ２のコミット処理の制御
を行うＴＭ１３は、ＴＭログバッファ１４を介してディ
スク上のＴＭログ領域１５に接続されている。これらＴ
Ｍログバッファ１４及びＴＭログ領域１５には、システ
ムダウン等の障害時に各ＲＭ間のデータに矛盾がないよ
うにするために、ＴＭ１３の処理に関するログ情報が保
持・格納される。

【００１１】この分散システムにおいて、アプリケーシ
ョンプログラム１６は、ＴＭ１３に対してトランザクシ
ョンの制御を依頼すると共に、各ＲＭ１及び２を介して
実際のデータアクセスを行う。

【００１２】次に、このシステムにおいて、２フェーズ
コミット処理による従来の分散トランザクション処理方
法を採用した場合の処理の流れについて、図面を参照し
て説明する。

【００１３】図１１、図１２及び図１３は、この従来方
法による正常時（すなわち、障害が発生せずに正常にコ
ミット処理が行われる場合）の各処理段階における各バ
ッファ及びディスク領域内のデータの変化の様子を示す
説明図である。ここで、図１１、図１２及び図１３は、
それぞれＲＭ１、ＲＭ２及びＴＭについての図である。
なお、図１１、図１２及び図１３は、ＲＭ１によってレ
コードｘ１のデータをｘ１１からｘ１２に更新する処理
と、ＲＭ２によってレコードｘ２のデータをｘ２１から
ｘ２２に更新する処理とを同一のトランザクションで行
う場合の例を示している。

【００１４】図１１及び図１２において、ＲＭ１及び２
のログバッファ３及び４に格納されるログ情報は、トラ
ンザクションのＩＤコード１００（以下、ＴＩＤと略
す）、このトランザクションにおける操作履歴情報１０
２、及びコミット処理状態を示すステータス１０４から
構成される。この例では、ＴＩＤを「α」とする。ま
た、ＲＭ１及びＲＭ２のデータバッファ５及び６に格納
されるデータ情報は、レコード番号（リソース名）１２
０とそれに対応するデータ領域１２２から構成される。
また、ＲＭ１及び２のロック管理テーブル７及び８に格
納されるデータは、排他制御を行う対象のリソース名１
３０とそのリソースを用いる使用者（トランザクショ
ン）１３２のＩＤから構成される。

【００１５】また、図１３において、ＴＭ１３のログバ
ッファ１４に格納されるログ情報は、トランザクション
のＩＤ（ＴＩＤ）１６０、このトランザクションに関連
のあるＲＭ名１６２、及びコミット処理の状態を示すス
テータス１６４から構成される。

【００１６】図８は、この図１１、図１２及び図１３に
対応した処理の流れを示すフローチャートである。以
下、このフローチャートと図１１、図１２及び図１３を
参照して正常時のトランザクション処理の流れを説明す
る。なお、図８においては、アプリケーションプログラ
ム（「ＡＰＰ」と略す）１６、ＴＭ１３、ＲＭ１及びＲ
Ｍ２の各要素ごとに、それぞれ処理の流れが示されてい
る。

【００１７】図８のトランザクション処理において、ア
プリケーション（ＡＰＰ）からコミットの要求があると
（Ｓ２０）、ＴＭは、フェーズ１の処理として、各ＲＭ
に対して、コミット処理ができるか否かを確認する要求
を出す（Ｓ２１）。このとき、ログバッファ３及び４に
は、図１１及び図１２に示すように、ビフォアイメージ
データ（更新前のデータ）１０６ａ，１０６ｂと、この
トランザクションにおける各ＲＭに対する操作（アクセ
ス）の履歴１０８ａ，１０８ｂが格納されている。ま
た、更新対象のレコードに対しては、排他制御のためロ
ック１３４ａ，１３４ｂがかけられている。すなわち、
１つのトランザクションが開始されると、ＡＰＰは、Ｒ
Ｍ１及びＲＭ２にアクセスし、各更新対象リソースにつ
いての更新処理命令を伝達する。これを受けてＲＭ１及
びＲＭ２は、排他制御のためにロック管理テーブルによ
ってリソースの確保を行うとともに、更新対象リソース
の更新前のデータを取り込んでビフォアイメージデータ
としてログバッファに格納し、更にその更新処理命令を
操作履歴としてログバッファに格納する。従って、この
時点では、ロック管理テーブルにはロック情報が、また
ログバッファには前記ビフォアイメージデータ及び操作
履歴が、それぞれ格納されている。

【００１８】さて、ＴＭからコミット可否確認の要求を
受けとった各ＲＭは、コミット処理が行えるかどうか確
認を行う（Ｓ２２，Ｓ２５）。すなわち、コミットに必
要なログ等の情報を記録してコミットの準備を行い、こ
のコミット準備が成功したか失敗したかを確認する。こ
のケース（正常時）ではＲＭ１、ＲＭ２共にコミット可
能なので、ログバッファ３及び４上にコミット準備がＯ
Ｋである旨を示したログ１１０ａ，１１０ｂを作成し、
このログをディスクのログ領域９及び１０のジャーナル
に書き込む（Ｓ２３，Ｓ２６）。なお、ログ１１０ａ，
１１０ｂにおいてはステータス「Ｐ」がコミット可能の
状態を示している。

【００１９】次に、各ＲＭは、コミット準備がＯＫであ
ることをＴＭに対して通知する（Ｓ２４，Ｓ２７）。そ
の結果を受けてＴＭでは、すべてのＲＭが準備ＯＫかの
チェックを行う（Ｓ２８）。このケースでは、すべての
ＲＭがＯＫなので、ＴＭはその旨を記録したログをＴＭ
ログバッファ１４上に作成し、さらにＴＭログ領域１５
に格納する（Ｓ２９）。すなわち、図１３に示すよう
に、ＴＭは、ＴＭログバッファ上にログデータ１６６を
作成し、これをさらにＴＭログ領域に書き込む。このケ
ースでは、すべてのＲＭがコミット準備ＯＫなので、ロ
グデータ１６６には、その旨を示すステータス「Ｐ」が
含まれる。

【００２０】以上のごとくフェーズ１の処理が正常に終
了すると、次にＴＭは、フェーズ２として、実際のコミ
ット処理の要求を各ＲＭに対して行う（Ｓ３０）。各Ｒ
Ｍは、その要求を受けとるとログ情報の更新（ＵＰＤＡ
ＴＥ）を行う（Ｓ３１，Ｓ３６）。すなわち、各ＲＭ１
及び２は、図１１及び図１２に示すように、ログバッフ
ァ３及び４に、コミット処理の確定を示すログ１１２
ａ，１１２ｂを作成する。ログ１１２ａ，１１２ｂにお
いては、ステータス「Ｃ」がコミット処理の確定状態を
示している。なお、このログ１１２ａ，１１２ｂは、デ
ィスクのログ領域９及び１０のジャーナルに書き込まれ
る。

【００２１】ログ情報の更新が終わると、各ＲＭは、デ
ータ部の更新処理を行い、ディスクのデータ領域に対し
てその結果を反映させる（Ｓ３２，Ｓ３７）。すなわ
ち、各ＲＭは、図１１及び図１２に示すように、更新対
象リソースのレコード番号及び更新処理内容からなる更
新処理データ１２４ａ，１２４ｂをデータバッファ５及
び６に書き込むと共に、ディスクのデータ領域の更新対
象リソースのデータを新しい値１５０ａ，１５０ｂに書
き換える。

【００２２】そして、その処理が終了した後、各ＲＭ
は、対応するＴＩＤ（α）のトランザクションに対する
ログバッファの解放処理（Ｓ３３，Ｓ３８）とロックの
解放処理（Ｓ３４，Ｓ３９）を行う。すなわち、ログバ
ッファは、そのトランザクション（α）に関する情報を
なくしてもよい状態となり、また各ロック管理テーブル
は、更新対象リソースについての使用者がない状態（図
１１の１３６ａ，図１２の１３６ｂ）となる。

【００２３】以上の処理が無事に終了すると、各ＲＭ
は、処理結果（このケースでは、正常に処理したことを
示す値（ＯＫ））をＴＭに通知する（Ｓ３５，Ｓ４
０）。

【００２４】各ＲＭのフェーズ２の処理結果を受けとっ
たＴＭは、すべてのＲＭの処理結果がＯＫか確認するが
（Ｓ４１）、このケース（正常時）ではすべてＯＫなの
で、その旨を記録したログをＴＭログバッファ１４上に
作成し、さらにＴＭログ領域１５に格納する（Ｓ４
２）。すなわち、図１３に示すように、ＴＭは、ＴＭロ
グバッファの内容をクリアし（この結果、ＴＭログバッ
ファの内容はログデータ１６８となる）、さらにこれを
ＴＭログ領域に書き込む。この後、ＴＭは、正常終了を
示す値をアプリケーション（ＡＰＰ）に返す（Ｓ４
３）。これによってアプリケーションによるＲＭ１及び
２のコミット処理が正常終了する。この時、図１１及び
図１２における最終的なログ領域及びデータ領域のイメ
ージは、それぞれログ１４０ａ，１４０ｂ，及びデータ
１５０ａ，１５０ｂに示すようになっている。

【００２５】また、以上説明したケースにおいて、シス
テムダウンが起こった場合には、以下のようにして回復
処理が行われる。

【００２６】すなわち、フェーズ１においてＴＭのログ
書込処理（Ｓ２９）が行われる前にシステムダウンが起
こった場合には、ＴＭのログにはそのトランザクション
に関する情報がない一方、各ＲＭにはコミット準備ＯＫ
の状態を示すログが残っている。従って、システム回復
時には、各ＲＭは、ＴＭに対してそのトランザクション
に関して問い合わせを行い、ＴＭからそのトランザクシ
ョンに関して確定したログがないとの情報を受ける。す
ると、各ＲＭは、そのトランザクションの確定処理を行
わず、ロールバック処理を行って回復する。従って、こ
の場合、両方のＲＭがロールバックして更新前の状態に
戻るので、データの矛盾は発生しない。

【００２７】また、ＴＭのログ書込処理（Ｓ２９）の
後、ＲＭ１及びＲＭ２のログ情報の更新（Ｓ３１，Ｓ３
６）の前にシステムダウンした場合は、ＴＭのログには
そのトランザクションに関するログ（図１３のログ１６
６）が存在しており、各ＲＭにはコミット準備ＯＫの状
態を示すログが残っている。従って、システム回復時に
は、各ＲＭは、ＴＭに対してそのトランザクションに関
して問い合わせを行い、ＴＭからログ情報が存在する旨
の情報を受ける。すると、各ＲＭは、そのトランザクシ
ョンに関して確定処理（フェーズ２）を行って回復す
る。従ってこの場合は、両方のＲＭが確定処理により更
新されるので、データの矛盾は発生しない。

【００２８】また、ＲＭの一方がコミット処理確定済み
を示すログ（図１１又は図１２のログ１１２ａ又は１１
２ｂ）を有し、他方がコミット準備ＯＫのログ（図１１
又は図１２のログ１１０ａ又は１１０ｂ）を有する場合
には、システム回復時に、前者のＲＭについてはそのま
ま確定処理が行われ、後者のＲＭについては、ＴＭに問
い合わせればＴＭにはトランザクションに関するログが
存在するので、これもまた確定処理が行われる。従っ
て、この場合も、両方のコミット処理が確定されるの
で、各ＲＭ間にデータの矛盾が発生しない。

【００２９】このように、このトランザクション処理方
法によれば、システムダウン等の障害からの回復時に
も、各ＲＭのデータの一貫性を維持できる。

【００３０】次にフェーズ１処理時にエラーが発生した
際の処理の流れについて図９のフローチャートと図１４
のデータの流れ図とを用いて説明する。この例では、Ｒ
Ｍ１は正常で、ＲＭ２でエラーが発生したものとする。
その他前提条件等は、前述の正常時の場合と同様であ
る。

【００３１】図９のトランザクション処理において、ア
プリケーション（ＡＰＰ）からのコミット処理の要求が
あると（Ｓ２０）、ＴＭは、フェーズ１として、各ＲＭ
に対して、コミット準備の状態を確認する要求を行う
（Ｓ２１）。すると、ＲＭ１については、図２と同様の
処理が行われる（Ｓ２２，２３，２４）。従って、ＲＭ
１については、前述の正常時と同様、図１４に示すよう
に、ログバッファにコミット準備がＯＫである旨を示し
たログ１１０ａが作成される。一方、ＲＭ２は、何らか
のエラーによりコミット処理が行えない（コミット処理
ＮＧ）ため（Ｓ４４）、そのトランザクションに対して
のロールバック処理を行い（Ｓ４５）、コミット準備が
できない旨（ＮＧ）をＴＭに対して通知する（Ｓ４
６）。

【００３２】その結果を受けてＴＭは、すべてのＲＭが
準備ＯＫかチェックを行う（Ｓ２８）。このケースでは
ＲＭ２がＮＧなので、ＴＭは、フェーズ２としてロール
バック要求をＲＭ１に対して行う（Ｓ４７）。ＲＭ１
は、その要求を受けとると、まずログ情報の更新を行う
（Ｓ４８）。すなわち、図１４に示すように、ＲＭ１
は、対応するログバッファ上に、コミット処理のキャン
セルを示すログ１１４ａを作成し、このログをディスク
のログ領域に書込む。その後、ＲＭ１は、そのトランザ
クションのロールバック処理を行い（Ｓ４９）、その旨
をＴＭに通知する。その通知を受けてＴＭは、ＡＰＰに
対してエラーリターンを行う（Ｓ５０）。このように、
フェーズ１において、ＲＭの一つにエラーが起こった場
合は、すべてのＲＭについてロールバック処理が行わ
れ、データの整合性が保たれる。なお、このときＲＭ１
のログ領域には、図１４に示すログ１４２ａが記録され
ている。

【００３３】次に、フェーズ２における実際のコミット
処理時にエラーが発生した場合の処理の流れについて図
１０のフローチャートと図１１及び図１５のデータの流
れ図とを用いて説明する。この例では、ＲＭ１は正常
で、ＲＭ２でエラーが発生したものとする。その他前提
条件等は、前述の正常時の場合と同様である。

【００３４】図１０のトランザクション処理において、
アプリケーション（ＡＰＰ）のコミット要求（Ｓ２０）
からフェーズ２におけるＴＭからＲＭへのコミット要求
（Ｓ３０）までの処理は、前述の正常時（図８）の処理
と同じである。従って、Ｓ３０までの処理についての説
明は省略し、以下ではそれより後の処理について説明す
る。

【００３５】ＴＭからコミット処理の要求を受けとった
ＲＭ１では、前述の正常時と同様の処理が行われる（Ｓ
３１〜３５）。従って、ＲＭ１についてのログバッファ
やデータバッファの状態変化は、前述の正常時と同様、
図１１に示したようになる。一方、ＲＭ２では、ＴＭか
らコミット要求うけると、正常時と同様にログ情報の更
新を行う（Ｓ３６）。従って、ＲＭ２のログバッファに
は、図１５に示すごとく、コミット処理の確定（ステー
タス「Ｃ」）を示すログ１１２ｂが作成され、そのログ
はログ領域に格納される。

【００３６】さて、ここでデータ部の更新処理をおいて
エラーが発生し（Ｓ５１）、ここからコミット準備ＯＫ
の状態に戻ることができなくなったとすると、ＲＭ２
は、再びログ情報の更新を行う（Ｓ５２）。すなわち、
図１５に示すように、ＲＭ２は、対応するログバッファ
上にコミット処理のキャンセルを示すログ１１４ｂを作
成し、さらにこのログをディスクの対応ログ領域へ書き
込む。

【００３７】その後、ＲＭ２は、そのトランザクション
のロールバック処理を行う（Ｓ５３）。このとき、ＲＭ
２のデータバッファは、図１５に示すように、更新対象
リソースの値をそのトランザクションが行われる前に戻
す処理を示すデータ１２６ｂに書き換えられる。そし
て、ＲＭ２は、ＴＭに対しロールバックを行った結果を
通知する（Ｓ５４）。

【００３８】各ＲＭからの処理結果通知を受け取ったＴ
Ｍでは、すべてのＲＭのコミット処理が正常終了したか
チェックを行う（Ｓ４１）。このケースでは、ＲＭ２で
ロールバック処理を行ったため、このチェックの結果は
ＮＯとなる。従って、両ＲＭ間でデータに矛盾が生じて
いることになり、ＴＭはこの旨をＡＰＰに対して通知す
る（Ｓ５５）。そして、ＴＭは、ＡＰＰに対してエラー
を示す値を返して終了する（Ｓ５０）。なお、このとき
のＲＭ１及びＲＭ２の最終的なログ領域の内容は、それ
ぞれ図１１のログ１４０ａ、図１５のログ１４２ｂに示
すようになっており、またＲＭ１及びＲＭ２の最終的な
データ領域の内容は、それぞれ図１１のデータ１５０
ａ、図１５のデータ１５２ｂに示すようになっている。

【００３９】このように、フェーズ２の実際のコミット
処理時に一つのＲＭにおいてエラーが発生すると、各Ｒ
Ｍ間でデータの一貫性がとれていない状態となる。

【００４０】

【発明が解決しようとする課題】以上説明したように、
従来の分散トランザクション処理方法では、システムダ
ウンが起こった場合や、フェーズ１でエラーがあった場
合等には、適切な回復処理を行って各リソース間のデー
タの矛盾を回避することができるが、フェーズ２におけ
る実際のコミット処理時、すなわちデータの実更新処理
時に１つのＲＭにおいてエラーが発生してそのＲＭがロ
ールバック処理を行うと、各ＲＭ間のデータの一貫性が
保てなくなるという問題があった。従って、従来は、フ
ェーズ２でエラーが発生すると、ＴＭの処理ではデータ
の一貫性が回復できず、いったんＡＰＰの処理を止め、
ユーザ自身がデータの照合を行うの障害回復処理が必要
であった。

【００４１】この発明は、上記のような問題点を解消す
るためになされたものであり、フェーズ２のデータ実更
新処理時にエラーが発生した場合でも、自動的に各ＲＭ
間のデータの一貫性を保つことが可能な分散トランザク
ション処理方法を提供することを目的とする。

【００４２】

【課題を解決するための手段】上記問題を解決するため
に、本発明に係る分散トランザクション処理方法は、デ
ータの記憶及び更新を行う複数のデータ記憶部と、各デ
ータ記憶部のロールバックに必要な情報を保持するロー
ルバック情報保持部と、前記複数のデータ記憶部と通信
を行ってトランザクション処理の管理を行うトランザク
ション管理部と、このトランザクション管理部の処理に
関するログを保持するトランザクションログ保持部と、
を有する分散システムにおいて、トランザクション処理
の終了時に、各データ記憶部についてコミット処理が可
能か否かの確認を行い、すべてのデータ記憶部がコミッ
ト処理可能な場合にのみ各データ記憶部のデータの実更
新を行うことにより、複数のデータ記憶部のデータの同
期更新を保証する分散トランザクション処理方法であっ
て、各データ記憶部のデータ実更新処理の後に、トラン
ザクション管理部にてすべてのデータ記憶部の実更新が
成功したか否かを判定し、判定の結果すべてのデータ記
憶部の実更新が成功であった場合には、前記ロールバッ
ク情報保持部を解放してトランザクションを終了し、判
定の結果一つでも実更新が失敗したデータ記憶部があっ
た場合には、当該実更新の失敗したデータ記憶部以外の
データ記憶部において前記ロールバック情報保持部及び
トランザクションログ保持部の情報を用いてロールバッ
ク処理を行い、このロールバック処理の後に前記ロール
バック情報保持部を解放してトランザクションを終了す
ることを特徴とする。

【００４３】また、本発明に係る分散トランザクション
処理方法は、各データ記憶部についてのコミット処理の
可否の確認の前にコミット処理の開始を示すログを前記
トランザクションログ保持部に記憶し、すべてのデータ
記憶部の実更新が成功したか否かの判定の結果すべての
データ記憶部の実更新が成功であったら、実更新が成功
した旨を示すログをトランザクションログ保持部に記憶
し、分散システムに障害が発生した場合においてその障
害から回復したときには、各データ記憶部はトランザク
ションログ保持部を参照し、トランザクションログ保持
部に前記実更新が成功した旨を示すログが存在する場合
には各データ記憶部はコミット処理を続行して前記ロー
ルバック情報保持部を解放し、前記実更新が成功した旨
を示すログが存在せず前記コミット処理の開始を示すロ
グが存在する場合には各データ記憶部はロールバック処
理を行ったのち前記ロールバック情報保持部を解放する
ことを特徴とする。

【００４４】また、本発明に係る分散トランザクション
処理方法は、各データ記憶部のデータ実更新処理の後
に、トランザクション管理部にてすべてのデータ記憶部
の実更新が成功したか否かを判定し、判定の結果一つで
も実更新が失敗したデータ記憶部があった場合には、当
該実更新の失敗したデータ記憶部以外のデータ記憶部に
おいて前記ロールバック情報保持部の情報を用いてロー
ルバック処理を行い、このロールバック処理の後に前記
ロールバック情報保持部を解放してトランザクションを
終了し、判定の結果すべてのデータ記憶部の実更新が成
功であった場合には、このトランザクションに関する前
記ロールバック情報保持部の情報を保持したままトラン
ザクションを終了し、次のトランザクションの開始時に
おけるトランザクション管理部からデータ記憶部へのト
ランザクション開始指示と同時に当該ロールバック情報
保持部の解放指示を行い、この解放指示に従って前記ロ
ールバック情報保持部を解放することを特徴とする。

【００４５】更に、本発明に係る分散トランザクション
処理方法は、各データ記憶部についてのコミット処理の
可否の確認の前に、コミット処理の開始を示すログを前
記トランザクションログ保持部に記憶し、すべてのデー
タ記憶部の実更新が成功したか否かの判定の結果、すべ
てのデータ記憶部の実更新が成功であったら、実更新が
成功した旨を示すログをトランザクションログ保持部に
記憶し、分散システムに障害が発生した場合においてそ
の障害から回復したときに、各データ記憶部がトランザ
クションログ保持部を参照し、トランザクションログ保
持部に前記実更新が成功した旨を示すログが存在せず前
記コミット処理の開始を示すログが存在する場合には各
データ記憶部はロールバック処理を行ったのち前記ロー
ルバック情報保持部を解放し、前記実更新が成功した旨
を示すログが存在する場合には各データ記憶部はコミッ
ト処理を続行して前記ロールバック情報保持部を解放せ
ずにトランザクションを終了し次のトランザクションの
開始時に前記ロールバック情報保持部を解放することを
特徴とする。

【００４６】

【作用】エラー発生時や障害回復時の各データ記憶部の
ロールバック処理は、ロールバック情報保持部及びトラ
ンザクションログ保持部に保持されているログ等のデー
タに基づいて行われる。本発明の第１の構成では、デー
タ記憶部におけるデータの実更新処理の後すぐにはロー
ルバック情報保持部及びトランザクションログ保持部を
解放せず、全データ記憶部における実更新が成功したこ
とを確認して初めてそれらログ保持部の解放を行う。従
って、データの実更新処理においてエラーが発生した場
合にも、解放していないロールバック情報保持部及びト
ランザクションログ保持部の情報を用いて、各データ記
憶部についてロールバック処理を行うことができる。よ
って、データ実更新処理時に一部のデータ記憶部におい
てエラーが生じた場合でも、分散システム全体のデータ
の一貫性を保つことができる。なお、本発明に構成にお
けるデータ記憶部は、図１の構成では各ＲＭ１，２及び
データ領域１１，１２に相当し、ロールバック情報保持
部は、図１ではログバッファ３，４及びロック管理テー
ブル７，８に相当する。また、トランザクション管理部
は、図１ではＴＭ１３に相当し、トランザクションログ
保持部は、図１ではＴＭログバッファ１４に相当する。

【００４７】また、本発明の第２の構成によれば、前記
第１の構成において、各データ記憶部についてのコミッ
ト処理の可否の確認の前にコミット処理の開始を示すロ
グをトランザクションログ保持部に記憶し、すべてのデ
ータ記憶部の実更新が成功したか否かの判定の結果、全
データ記憶部の実更新が成功であったら実更新が成功し
た旨を示すログをトランザクションログ保持部に記憶す
る。そして、分散システムに障害が発生した場合におい
てその障害から回復したときには、各データ記憶部は、
トランザクションログ保持部を参照し、最新のログがコ
ミット処理開始のログと実更新成功のログのいずれであ
るかによって、障害回復処理においてコミット処理の続
行を行うかロールバック処理を行うかの判断を行う。こ
のような手順により、障害回復時においても分散システ
ムにおけるデータの一貫性を保つことができる。更に
は、従来は、各データ記憶部において障害回復処理判断
のための情報、すなわち「コミット準備ＯＫ」を示すロ
グを生成し、ロールバック情報保持部に保持していた
が、本発明によれば、各データ記憶部についてのコミッ
ト処理の可否の確認の前にコミット処理の開始を示すロ
グをトランザクションログ保持部に登録し、このログを
障害回復処理判断の情報として用いることにより、各デ
ータ記憶部について障害回復処理判断のための情報を生
成及び保持する必要がなくなり、各データ記憶部におけ
る処理ステップ（Ｉ／Ｏ回数）を削減することができ
る。

【００４８】また、本発明の第３の構成によれば、デー
タの実更新処理の後すぐにはロールバック情報保持部の
解放を行わず、次のトランザクションの開始時における
トランザクション管理部からデータ記憶部へのトランザ
クション開始指示と同時に当該ロールバック情報保持部
の解放指示を行うことにより、トランザクションが正常
に行われる場合におけるトランザクション管理部とデー
タ記憶部との間の通信回数を低減し、処理効率を向上さ
せることができる。

【００４９】また、本発明の第４の構成によれば、前記
第３の構成において、各データ記憶部についてのコミッ
ト処理の可否の確認の前にコミット処理の開始を示すロ
グをトランザクションログ保持部に登録し、このログを
障害回復処理判断の情報として用いることにより、上記
第２の構成と同様、各データ記憶部について障害回復処
理判断のための情報を生成及び保持する必要がなくな
り、各データ記憶部における処理ステップ（Ｉ／Ｏ回
数）を削減することができる。

【００５０】

【実施例】以下、図面に基づき、本発明の好適な実施例
について説明する。なお、実施例の方法が適用される分
散システムの構成は、従来技術と同様、図１に示す構成
である。また、以下の実施例の説明におけるトランザク
ションで行われる処理操作は、前記従来技術の説明にお
ける処理操作（ＲＭ１によってレコードｘ１のデータを
ｘ１１からｘ１２に更新する処理と、ＲＭ２によってレ
コードｘ２のデータをｘ２１からｘ２２に更新する処理
とを同一のトランザクションで行う）と同じものであ
る。

【００５１】第１実施例 まず、本発明の第１の実施例について説明する。

【００５２】この第１実施例は、従来方法においてはフ
ェーズ２で一連の処理として行われていたＲＭのデータ
部への書込み（データの実更新）処理及びＲＭのログバ
ッファ、ロックの解放処理を２つの段階に分けたもので
ある。すなわち、データ部の実更新のフェーズの後に、
この実更新時にエラーが起こっていないかどうかを判断
するステップを設け、この判断ステップの後にログバッ
ファ等の解放を行うフェーズを設けたことにより、一部
のＲＭにおいてデータ部の実更新時にエラーが起こった
場合でも、他のデータの実更新に成功したＲＭのログバ
ッファ等はその時点ではまだ解放されていないため、ロ
ールバック処理を行うことができる。

【００５３】以下、この第１実施例の方法において、正
常に処理が行われた場合、及びデータ部の更新処理時に
エラーが起こった場合について、それぞれフローチャー
トを参照しつつ説明する。

【００５４】図２は、この第１実施例の処理方法を用い
た場合において、トランザクションの処理がすべて正常
に行われた場合の処理の流れを示すフローチャートであ
る。なお、このケースにおけるログバッファ及びディス
ク内におけるデータの流れの様子は、従来方法の正常時
の場合とほぼ同様であり、図１１、図１２及び図１３に
示すごとくになる。

【００５５】図２のトランザクション処理において、ア
プリケーション（ＡＰＰ）のコミット要求（Ｓ２０）か
らフェーズ２におけるデータ部の実更新処理（Ｓ３２，
Ｓ３７）までの処理は、従来方法における正常時（図
８）の処理と同じである。従って、Ｓ３２及びＳ３７ま
での処理についての説明は省略し、以下ではそれより後
の処理について説明する。

【００５６】本実施例が、従来方法と異なるのは、フェ
ーズ２で各ＲＭについてデータバッファ及びデータ領域
に書込みを行った後、すぐにはログバッファ及びロック
管理テーブルの解放を行わない点である。すなわち、本
実施例の方法では、データ部の実更新処理（Ｓ３２，Ｓ
３７）が終わると、各ＲＭは、ログバッファ及びロック
管理テーブルの解放を行わずに、これまでの処理が成功
した旨（ＯＫ）のみをＴＭに通知する（Ｓ３５ａ，Ｓ４
０ａ）。

【００５７】各ＲＭのフェーズ２の処理結果を受けとっ
たＴＭは、すべてのＲＭの処理結果がＯＫか否か確認す
る（Ｓ４１ａ）。このケース（正常時）ではすべてＯＫ
なので、ＴＭは、フェーズ３として、ログバッファ及び
ロックの解放を要求するためのリソース解放要求を各Ｒ
Ｍに通知する（Ｓ５６）。また、ＴＭは、この通知と同
時にＴＭログ情報の更新を行う（Ｓ４２ａ）。すなわ
ち、ＴＭは、Ｓ２９で書込んだＴＭログバッファの内容
をクリアし、さらにこのクリアしたログをＴＭログ領域
に書込む（図１３のログ１６８、１７２参照）。この
後、ＴＭは、正常終了を示す値をアプリケーション（Ａ
ＰＰ）に返す（Ｓ４３ａ）。

【００５８】一方、ＴＭから確定要求を受けとった各Ｒ
Ｍでは、ログバッファの解放（Ｓ３３ａ，Ｓ３８ａ）と
ロックの解放（Ｓ３４ａ，Ｓ３９ａ）を行う。すなわ
ち、各ログバッファは、トランザクション（ＴＩＤ：
α）に関する情報をなくしてもよい状態となり、また各
ロック管理テーブルは、更新対象リソースについての使
用者がないことを示す内容（図１１のデータ１３６ａ，
図１２のデータ１３６ｂ）に変更される。

【００５９】上述した正常時の処理における最終的なロ
グ領域及びデータ領域のイメージは、従来方法の場合と
同様に、図１１及び図１２のそれぞれ、ログ１４０ａ，
１４０ｂ及びデータ１５０ａ，１５０ｂに示したごとく
になる。

【００６０】なお、本実施例の方法において、フェーズ
１でエラーが発生した場合は、従来方法と全く同様の処
理（図９参照）によってロールバックがなされ、各リソ
ース（データベース等）間のデータの矛盾が解消され
る。

【００６１】また、各リソースのデータ部の実更新処理
の前にシステムダウンが起こった場合も、従来方法と同
様の流れで回復処理がなされるため、各リソース（デー
タベース等）間のデータの一貫性が保たれる。

【００６２】次に、フェーズ２のコミット処理時、すな
わちデータ部の実更新処理時、にエラーが発生した場合
における本実施例の方法の処理の流れについて、図３の
フローチャートを参照して説明する。この例では、ＲＭ
１は正常で、ＲＭ２でエラーが発生したものとする。な
お、このケースにおけるＲＭ１及びＲＭ２の各バッファ
及びディスクの各記憶領域内のデータの変化の様子は、
それぞれ図１６及び図１５に示される。

【００６３】図３のトランザクション処理において、ア
プリケーションからのコミット要求（Ｓ２０）からフェ
ーズ２におけるログ情報の更新処理（Ｓ３１，Ｓ３６）
までの処理は、前述の正常ケース（図２）と同じであ
る。従って、Ｓ３１、Ｓ３６までの処理についての説明
は省略し、以下ではそれより後の処理について説明す
る。

【００６４】まず、ＲＭ１では、前述の正常時と同様、
データ部の更新処理（Ｓ３２）を行い、処理結果（コミ
ットＯＫ）をＴＭに通知する（Ｓ３５ａ）。このとき、
ＲＭ１のログバッファには、図１６に示すように、コミ
ット処理が確定した旨を示すログ１１２ａが作成されて
いる。

【００６５】一方、ＲＭ２では、ＴＭからコミット要求
うけると、正常時と同様にログ情報の更新を行う（Ｓ３
６）。従って、ＲＭ２のログバッファには、図１５に示
すごとく、コミット処理の確定を示すログ１１２ｂが作
成され、そのログはログ領域に格納される。

【００６６】さて、ここでデータ部の更新処理をおいて
エラーが発生し（Ｓ５１）、ここからコミット準備ＯＫ
の状態に戻ることができなくなったとすると、ＲＭ２
は、再びログ情報の更新を行う（Ｓ５２）。すなわち、
図１５に示すように、ＲＭ２は、対応するログバッファ
上にコミット処理のキャンセルを示すログ１１４ｂを作
成し、さらにこのログをディスクの対応ログ領域へ書き
込む。

【００６７】その後、ＲＭ２は、そのトランザクション
のロールバック処理を行う。すなわち、データ部を更新
前の状態に戻し（Ｓ５６）、ログバッファとロックの解
放を行う（Ｓ３８ａ，Ｓ３９ａ）。このとき、ＲＭ２の
データバッファは、図１５に示すように、更新対象リソ
ースの値をそのトランザクションが行われる前の状態に
戻す処理を示すデータ１２６ｂに書き換えられる。そし
て、ＲＭ２は、ＴＭに対しロールバックを行った結果
（コミットＮＧ）を通知する（Ｓ５４ａ）。

【００６８】ＴＭでは、すべてＲＭの処理結果がＯＫか
否かチェックを行い（Ｓ４１ａ）、このケースではＲＭ
２でロールバック処理を行ったため、このチェックの結
果はＮＯとなる。すると、ＴＭは、フェーズ２の実更新
処理が失敗したＲＭ以外の各ＲＭ（このケースではＲＭ
１）に対して、既に行われたデータの実更新を取り消す
ためのロールバック要求を通知する（Ｓ５７）。また、
ＴＭは、このロールバック要求の発信と同時に、ＴＭロ
グ情報の更新（クリア）を行う（Ｓ４２ａ）。そして、
ＴＭは、アプリケーション（ＡＰＰ）に対してエラーリ
ターンを行う（Ｓ５０ａ）。

【００６９】一方、ＴＭからロールバック要求を受けと
ったＲＭ１では、まずログ情報の更新を行う（Ｓ５
８）。すなわち、図１６に示すように、ＲＭ１のログバ
ッファ上のキャンセルを示すログ１１４ａを作成し、こ
れをディスクへ書込む。

【００７０】この後、ＲＭ１は、データ部を元に戻す
（Ｓ５９）。すなわち、ＲＭ１のデータバッファは、図
１６に示すように、更新対象リソースの値をそのトラン
ザクションが行われる前の状態に戻す処理を示すデータ
１２６ａに書き換えられ、またディスクのデータ領域も
更新前の状態（ｘ１１）に戻される。従って、ＲＭ１と
ＲＭ２の最終的なログ及びデータのイメージは、それぞ
れ図１６及び図１５のログ１４２ａ，１４２ｂ及びデー
タ１５２ａ，１５２ｂに示すごとくになり、各ＲＭ間で
データの一貫性がとれている状態となる。

【００７１】そして、データ部の回復処理が終わると、
ＲＭ１は、ログバッファとロックの解放を行う（Ｓ３３
ａ，Ｓ３４ａ）。すなわち、ＲＭ１のログバッファは、
トランザクション（ＴＩＤ：α）に関する情報をなくし
てもよい状態となり、またロック管理テーブルは、更新
対象リソースについての使用者がないことを示す内容
（図１６のデータ１３６ａ）に変更される。

【００７２】このように、本実施例では、ログバッファ
及びロック管理テーブルの解放処理を各ＲＭのデータ実
更新処理の成否を判定した後に行うようにしたため、フ
ェーズ２のコミット処理時、すなわちデータの実更新時
に一部のＲＭがエラーによりロールバックを行った場合
でも、既にデータの実更新が終了したＲＭのログバッフ
ァ等はその時点ではまだ解放されずに保持されている。
従って、本実施例では、フェーズ２を正常処理したＲＭ
は、保持されているログバッファ及びロック管理テーブ
ルに基づきロールバックすることができるので、システ
ム全体のデータの一貫性を維持することができる。

【００７３】第２実施例 本発明の第２実施例は、前記第１実施例の変形であり、
前記第１実施例のフェーズ３で行っていたＲＭのログバ
ッファ及びロック管理テーブルの解放処理を次のトラン
ザクションに移したものである。

【００７４】図４のフローチャートは、この第２実施例
の方法を用いた場合の正常時の処理の流れを示すフロー
チャートである。

【００７５】図４のトランザクション処理において、ア
プリケーション（ＡＰＰ）のコミット要求（Ｓ２０）か
らフェーズ２のコミット（データ実更新）処理の結果の
判定（Ｓ４１ａ）までは、前述の第１実施例（図２のフ
ローチャート）と同じ処理である。

【００７６】本実施例が前記第１実施例と異なるのは、
Ｓ４１ａの判定の結果がすべてＯＫの場合には、フェー
ズ３（ログバッファ及びロックの解放）の処理を行わず
にＡＰＰにリターンしてしまう点である。すなわち、本
実施例の処理では、Ｓ４１ａの判定においてすべてＲＭ
の通知がＯＫである場合には、ＴＭは、まずＴＭログバ
ッファ上のログ情報（Ｓ２９で書き込まれたもの）をメ
モリ（例えばメインメモリ）上の所定領域にいったんセ
ーブ（保存）し（Ｓ６０）、その後、ＴＭログバッファ
及びディスクのＴＭログ領域のログ情報のクリアを行う
（Ｓ４２ｂ）。そして、ＴＭは、正常終了を示す値をア
プリケーション（ＡＰＰ）に返し（Ｓ４３ｂ）、これに
より一つのトランザクションを終了する。

【００７７】そして、その後ＡＰＰにおいて、別のトラ
ンザクションが発生したとき（Ｓ６１）には、まずＴＭ
において、前記メモリ上の所定領域に前回トランザクシ
ョンの際にセーブされたＴＭログ情報が存在するかチェ
ックを行う（Ｓ６２）。このケースでは、前回トランザ
クションのＴＭログ情報が存在するので、ＴＭは、この
ＴＭログ情報を各ＲＭに対するトランザクションの開始
要求の際に送信する通知情報に付加する（Ｓ６３）。そ
の後、ＴＭは、メインメモリ等にセーブしておいた前回
トランザクションのＴＭログ情報をクリアし（Ｓ６
４）、トランザクションの開始要求を各ＲＭに通知する
（Ｓ６５）。

【００７８】トランザクションの開始要求を受けとった
各ＲＭでは、通知情報を調べてＴＭログ情報の有無をチ
ェックし（Ｓ６６，Ｓ６８）、ＴＭログ情報が存在して
いた場合には、保持していたログバッファの解放（Ｓ３
３ｂ，Ｓ３８ｂ）とロックの解放（Ｓ３４ｂ，Ｓ３９
ｂ）を行う。各ＲＭは、以上の処理によりログバッファ
及びロック管理テーブルを初期化した後で、通常どおり
のトランザクションの開始処理を行う（Ｓ６７，Ｓ６
９）。

【００７９】以上説明したように、本実施例では、正常
処理の場合は、ログバッファ等の解放のための通信を次
回トランザクションの開始時の通信に含めてしまうこと
によりフェーズ３の通信を行う必要がなくなるので、Ｔ
Ｍと各ＲＭとの間の通信量を減らすことが可能である。

【００８０】なお、この第２実施例において、フェーズ
１又はフェーズ２で一部のＲＭにエラーが起こった場
合、及びシステムダウンが起こった場合は、前述の第１
実施例と同様の処理の処理の流れにより、それぞれ正常
に回復処理がなされ、各リソース間のデータの一貫性が
維持される。

【００８１】第３実施例 前述の第１実施例は、コミット処理（データの実更新処
理）の後に各ＲＭのコミット処理の成否を確認するステ
ップを設け、各ＲＭのログバッファやロックの解除をそ
のステップの後に行うという構成としたことにより、コ
ミット処理後の各ＲＭのロールバック処理を可能にした
ものであった。これに対し、第３実施例は、このコミッ
ト処理後にも各ＲＭのロールバック処理が可能な点に注
目して、第１実施例ではフェーズ２で行われていたデー
タの実更新処理をフェーズ１に移し、フェーズ１におい
てコミット確認とデータの実更新の両方を行うようにし
た方法である。この方法では、フェーズ１（コミット確
認及びデータの実更新）ではログバッファ及びロック管
理テーブルを解放せずに保持したままにし、フェーズ２
でのロールバックを可能とする。

【００８２】図５のフローチャートは、この第３実施例
の処理方法における正常時の処理の流れを示すフローチ
ャートである。このケースにおけるＲＭ１、ＲＭ２の各
バッファ及びディスクの各記憶領域内のデータの変化の
様子は、それぞれ図１７、図１８に示すごとくになる。
また、ＴＭのログバッファ及びディスクのログ領域内の
データの変化の様子は図１９に示される。

【００８３】図５に示すように、本実施例では、ＡＰＰ
からコミット要求（Ｓ２０）があると，ＴＭは、まずそ
の要求があったことを示すＴＭログ情報を作成し、ＴＭ
ログ領域に書き込む（Ｓ７０）。すなわち、図１９に示
すように、ＴＭは、ＴＭログバッファ上にログ１７０
（ステータス「Ｓ」）を作成し、このログをディスクの
ＴＭログ領域に書き込む。その後、ＴＭは、フェーズ１
として、各ＲＭに対して、コミット処理の要求を出す
（Ｓ７１）。

【００８４】各ＲＭは、その要求を受けとると、まずコ
ミット処理が行えるかどうか確認を行う（Ｓ７２，Ｓ７
７）。従来方法や前記第１実施例では、この後コミット
準備ＯＫの状態（ステータス「Ｐ」）を示したログをロ
グバッファを作成していたが、本実施例の方法では、図
１７及び図１８に示すように、この段階でコミット確定
（ステータス「Ｃ」）を示すログ１１２ａ，１１２ｂを
ログバッファに作成し、ディスクのログ領域に書き込
む。

【００８５】この後、各ＲＭは、データバッファ及びデ
ィスクのデータ領域の更新処理を行う（Ｓ７３，Ｓ７
７）。すなわち、各ＲＭは、図１７及び図１８に示すよ
うに、更新対象リソースのレコード番号及び更新処理内
容からなる更新処理データを１２４ａ，１２４ｂをデー
タバッファに書き込むと共に、ディスクのデータ領域の
更新対象リソースのデータを新しい値１５０ａ，１５０
ｂに書き換える。そして、各ＲＭは、コミット処理が正
常終了した旨をＴＭに対して通知する（Ｓ７５，Ｓ７
９）。

【００８６】その通知を受けてＴＭでは、各ＲＭのコミ
ット処理が正常かチェックを行う（Ｓ８０）。このケー
スではすべてＲＭのコミット処理が正常なので、ＴＭ
は、ＴＭログ情報の更新を行う（Ｓ８２）と同時に、フ
ェーズ２として、ログバッファ及びロックの解放を要求
するためのリソース解放要求を各ＲＭに通知する（Ｓ８
１）。このログの更新においては、ＴＭは、Ｓ７０で書
込んだＴＭログバッファの内容をクリアし、さらにこの
クリアしたログをＴＭログ領域に書込む（図１９のログ
１６８，１７２参照）。この後、ＴＭは、正常終了を示
す値をアプリケーション（ＡＰＰ）に返す（Ｓ８３）。

【００８７】一方、そのリソース解放要求を受けとった
各ＲＭでは、フェーズ１で解放せずに保持していたログ
バッファ及びロック管理テーブルの解放処理（Ｓ８４，
Ｓ８５，Ｓ８６，Ｓ８７）を行う。すなわち、各ログバ
ッファは、トランザクション（ＴＩＤ：α）に関する情
報をなくしてもよい状態となり、また各ロック管理テー
ブルは、更新対象リソースについての使用者がないこと
を示す内容（図１７のデータ１３６ａ，図１８のデータ
１３６ｂ）に変更される。

【００８８】上述した正常時の処理における最終的なロ
グ及びデータのイメージは、従来方法の場合と同様に、
図１７及び図１８のそれぞれ、ログ１４０ａ，１４０ｂ
及びデータ１５０ａ，１５０ｂに示したごとくになる。

【００８９】次に、データの実更新処理時にエラーが発
生した場合における本実施例の方法の処理の流れについ
て、図６のフローチャートを参照して説明する。この例
では、ＲＭ１は正常で、ＲＭ２でエラーが発生したもの
とする。なお、このケースにおけるＲＭ１及びＲＭ２の
各バッファ及びディスクの各記憶領域内のデータの変化
の様子は、それぞれ図２０及び図２１に示される。ま
た、ＴＭのログバッファ及びディスクのログ領域内のデ
ータの変化の様子は図１９に示される。

【００９０】図６のトランザクション処理において、Ａ
ＰＰのコミット要求（Ｓ２０）からフェーズ１のＴＭの
コミット要求（Ｓ７１）までの処理の流れは、前記正常
ケースと同じである。また、ＴＭからのコミット要求を
受けとったＲＭ１の処理も、前記正常ケースと同様であ
る（Ｓ７２〜７５）。

【００９１】一方、ＲＭ２では、ＴＭからのコミット要
求を受けると、コミット処理の確認（Ｓ７６）及びログ
情報の書込み（Ｓ７７）までは、前記正常ケースと同様
に行われる。従って、この時点では、ＲＭ１及びＲＭ２
のログバッファには、それぞれ図２０及び図２１に示す
ように、コミット処理が確定した旨（ステータス
「Ｃ」）を示すログ１１２ａ，１１２ｂが作成され、さ
らにそれらログは各ログ領域に格納されている。

【００９２】さて、ここでＲＭ２のデータ部の実更新処
理においてエラーが発生した（Ｓ８８）場合、本実施例
ではまずログ情報の更新を行う（Ｓ８９）。すなわち、
図２１に示すように、ＲＭ２は、ログバッファ上にコミ
ット処理のキャンセルを示すログ１１４ｂを作成し、さ
らにこのログをディスクのログ領域へ書き込む。

【００９３】その後、ＲＭ２は、そのトランザクション
のロールバック処理を行う（Ｓ９０）。すなわち、デー
タ部を更新前の状態に戻し、更にログバッファとロック
の解放を行う。このとき、ＲＭ２のデータバッファは、
図２１に示すように、更新対象リソースの値をそのトラ
ンザクションが行われる前の状態に戻す処理を示すデー
タ１２６ｂに書き換えられる。そして、ＲＭ２は、ＴＭ
に対しロールバックを行った結果（コミット処理ＮＧ）
を通知する（Ｓ９１）。

【００９４】ＴＭでは、すべてのＲＭの処理結果がＯＫ
かどうかチェックを行う（Ｓ８０）が、このケースでは
ＲＭ２でロールバック処理を行ったため、このチェック
の結果はＮＯとなる。すると、ＴＭは、ＴＭログ情報の
更新（クリア）を行う（Ｓ８１）と同時に、フェーズ２
の実更新処理が失敗したＲＭ以外の各ＲＭ（このケース
ではＲＭ１）に対して、既に行われたデータの実更新を
取り消すためのロールバック要求を通知する（Ｓ９
２）。その後、ＴＭは、ＡＰＰに対してエラーリターン
を行う（Ｓ９３）。

【００９５】一方、ロールバック要求を受けとったＲＭ
１では、まずログ情報の更新を行う（Ｓ９４）。すなわ
ち、図２０において、ＲＭ１のログバッファ上にキャン
セルを示すログ１１４ａを作成し、これをディスクへ書
込む。すなわち、ＲＭ１は、データバッファの内容を、
図２０のデータ１２６ａに示すように、更新対象リソー
スの値をそのトランザクションが行われる前の状態に戻
す処理を示すデータに書き換え、またディスクのデータ
領域内の更新対象リソースも更新前の状態（ｘ１１）に
書き換える。

【００９６】従って、本実施例では、ログバッファ及び
ロック管理テーブルの解放処理を各ＲＭのデータ実更新
処理の成否を判定した後に行うようにしたため、あるＲ
Ｍにおけるデータの実更新処理時にエラーが発生したと
しても、既にデータ実更新が終了したＲＭのロールバッ
クを行うことことができ、システムのデータの一貫性を
維持することができる。

【００９７】なお、本実施例において、各ＲＭのコミッ
ト可否の確認処理（Ｓ７２，Ｓ７６）において、一部の
ＲＭでコミットが不可能であると判定された場合には、
従来方法と同様の処理（図９参照）によってロールバッ
クがなされ、各リソース（データベース等）間のデータ
の矛盾が解消される。

【００９８】また、システムダウンが起こった場合、本
実施例の方法では、回復処理時に各ＲＭがＴＭに対して
問い合わせを行い、ＴＭのログ情報における最新のログ
が対応トランザクションの開始要求のログ（図１９のロ
グ１７０）である場合は全ＲＭについてロールバッグ処
理を行い、そうでない場合（図１９のログ１６８の状
態）には、すべてのＲＭについて確定処理を行う。この
ような操作によれば、いずれの場合でも各ＲＭ間でデー
タの矛盾が生じることがなく、システムの信頼性は損な
われない。このように、本実施例は、システムダウンが
発生した場合でも、各リソース間のデータの一貫性を維
持したまま回復処理を行うことができる。

【００９９】以上説明したように、本実施例は、前記第
１実施例に比べてＴＭ・ＲＭ間の通信回数を減らすこと
ができる。また、トランザクションの正常処理時におい
て、各ＲＭがコミット準備ＯＫの作成及び格納を行わな
くてもよいため、各ＲＭにおける処理時間を短縮するこ
とができる。また、本実施例によれば、正常処理時の総
処理ステップ数が前記第１実施例より少なくなるため、
正常処理時の全体的な処理時間を短縮することができ
る。通常、エラーの起こる確率は低いので、正常処理時
の処理時間を短縮することは、システム全体としての処
理効率の向上に大きく貢献する。

【０１００】第４実施例 本発明の第４実施例は、前記第３実施例と同様にフェー
ズ１でデータの実更新を行うが、すべてのＲＭのフェー
ズ１の処理が成功した場合には、そのままそのトランザ
クションを終了し、ＲＭのログバッファ等の解放処理は
次回のトランザクションの開始時に行う。

【０１０１】図７は、この発明の第４実施例の正常時の
処理の流れを示すフローチャートである。

【０１０２】図７のトランザクション処理において、Ａ
ＰＰのコミット要求（Ｓ２０）からフェーズ１の結果を
判断する処理（Ｓ８０）までは、前記第３実施例（図
６）と同じ処理である。

【０１０３】その後、本実施例では、前記第３実施例と
異なり、ＴＭは、ＲＭのログバッファ及びロック管理テ
ーブルの解放を行わずにＡＰＰに制御を返し、トランザ
クションを終了する。すなわち、本実施例では、ＴＭ
は、Ｓ８０の判定の結果がすべてのＲＭについてＯＫの
ときには、ＴＭログバッファ上のログ情報（Ｓ７０で書
き込まれたもの）をメインメモリ等のメモリ上にいった
んセーブ（保存）する（Ｓ９６）。その後、ＴＭログバ
ッファ及びディスクのＴＭログ領域のログ情報のクリア
を行う（Ｓ８１）。そして、ＴＭは、正常終了を示す値
をアプリケーション（ＡＰＰ）に返し（Ｓ８３）、これ
により一つのトランザクションを終了する。

【０１０４】そして、その後ＡＰＰにおいて別のトラン
ザクションが発生したとき（Ｓ６１ｄ）には、まずＴＭ
において、前記メモリ上の所定領域に前回トランザクシ
ョンの際にセーブされたＴＭログ情報が存在するかチェ
ックを行う（Ｓ６２ｄ）。このケースでは、前回トラン
ザクションのＴＭログ情報が存在するので、ＴＭは、こ
のＴＭログ情報を各ＲＭに対するトランザクションの開
始要求の際に送信する通知情報に付加する（Ｓ６３
ｄ）。その後、ＴＭは、前回トランザクションのＴＭロ
グ情報をクリアし（Ｓ６４ｄ）、ＴＭログ情報の付加さ
れた通知情報を含んだトランザクション開始要求を各Ｒ
Ｍに通知する（Ｓ６５ｄ）。

【０１０５】トランザクションの開始要求を受けとった
各ＲＭでは、通知情報を調べてＴＭログ情報の有無をチ
ェックし（Ｓ６６ｄ，Ｓ６８ｄ）、ＴＭログ情報が存在
していた場合には、保持していたログバッファの解放
（Ｓ３３ｄ，Ｓ３８ｄ）とロックの解放（Ｓ３４ｄ，Ｓ
３９ｄ）を行う。各ＲＭは、以上の処理によりログバッ
ファ及びロック管理テーブルを初期化した後で、通常ど
おりのトランザクションの開始処理を行う（Ｓ６７ｄ，
Ｓ６９ｄ）。

【０１０６】以上の処理を行うことにより、本実施例で
は、正常処理の場合は、ログバッファ等の解放のための
通信を次回トランザクションの開始時の通信に含めてし
まうことにより、ログバッファ等の解放処理のためのＴ
ＭからＲＭへの通信を行う必要がなくなるので、ＴＭと
各ＲＭとの間の通信量を減らすことが可能である。

【０１０７】なお、本実施例において、コミット可否確
認時（Ｓ７２，Ｓ７６）に一部のＲＭがコミット処理不
可となった場合、及びシステムダウンが起こった場合
は、前述の第３実施例と同様の処理の流れにより、それ
ぞれ正常に回復処理がなされ、各リソース間のデータの
一貫性が維持される。

【０１０８】また、本実施例において、データ部の実更
新処理時にエラーが起こった場合は、前記第３実施例の
場合と同様にしてロールバック処理が行われる（図６参
照）。

【０１０９】以上説明したように、本発明の上記各実施
例は、データの実更新のフェーズの後に、この実更新時
にエラーが起こっていないかどうかを判断するステップ
を設け、ログバッファやロック管理テーブルの解放処理
をこの判断ステップの後に行う方式としたことにより、
一部のＲＭにおいてデータ部の実更新時にエラーが起こ
った場合でも、他のデータの実更新を終了したＲＭのロ
グバッファ等はその時点ではまだ保持されているため、
それらログバッファ等のデータを用いることにより、実
更新が終了したＲＭのロールバック処理を行うことがで
きる。従って、上記各実施例によれば、トランザクショ
ンの一連のコミット処理において、データの実更新処理
時にエラーが生じた場合でも、各リソース間のデータの
一貫性を維持することができる。

【０１１０】なお、以上の各実施例の説明では、説明を
簡略化するためＲＭの個数を２つとして説明したが、本
実施例は、このような場合に限らず、更に多数のＲＭが
存在する場合においても同様の効果が得られる。

【０１１１】

【発明の効果】以上説明したように、本発明によれば、
一部のＲＭにおいてデータ部の実更新時にエラーが起こ
り、そのＲＭがロールバックした場合でも、他のデータ
の実更新を終了したＲＭのログバッファやロック管理テ
ーブル等のロールバック情報保持用リソースはその時点
ではまだ解放されずに保持されているため、そのロール
バック情報保持用リソースのデータを用いることによ
り、実更新が終了したＲＭのロールバック処理を行うこ
とができる。従って、本発明によれば、トランザクショ
ンの一連のコミット処理において、データの実更新処理
時にエラーが生じた場合でも、各リソース間のデータの
一貫性を維持することができ、システムの信頼性を向上
させることができる。

【０１１２】また、本発明によれば、ＴＭ・ＲＭ間の通
信回数を減らすことができ、ネットワーク通信によるオ
ーバーヘッドの影響を少なくするという効果が得られ
る。

【図面の簡単な説明】

【図１】 本発明に係る分散トランザクション処理方法
が適用される分散システムの構成の一例を示す図であ
る。

【図２】 本発明の第１実施例の正常処理時の処理の流
れを示すフローチャートである。

【図３】 本発明の第１実施例においてデータ実更新時
にエラーが発生した場合の処理の流れを示すフローチャ
ートである。

【図４】 本発明の第２実施例の正常処理時の処理の流
れを示すフローチャートである。

【図５】 本発明の第３実施例の正常処理時の処理の流
れを示すフローチャートである。

【図６】 本発明の第３実施例においてデータ実更新時
にエラーが発生した場合の処理の流れを示すフローチャ
ートである。

【図７】 本発明の第４実施例の正常処理時の処理の流
れを示すフローチャートである。

【図８】 従来の２フェーズコミット処理における正常
処理の処理の流れを示すフローチャートである。

【図９】 従来の２フェーズコミット処理において、フ
ェーズ１でエラーが発生した場合の処理の流れを示すフ
ローチャートである。

【図１０】 従来の２フェーズコミット処理において、
フェーズ２のデータ実更新処理時にエラーが発生した場
合の処理の流れを示すフローチャートである。

【図１１】 従来例及び第１実施例における正常処理時
のＲＭ１についてのデータの変化の様子を示す図であ
る。

【図１２】 従来例及び第１実施例における正常処理時
のＲＭ２についてのデータの変化の様子を示す図であ
る。

【図１３】 従来例及び第１実施例における正常処理時
のＴＭについてのデータの変化の様子を示す図である。

【図１４】 従来例においてフェーズ１でエラーが発生
した場合のＲＭ１についてのデータの変化の様子を示す
図である。

【図１５】 従来例及び第１実施例において、データ実
更新時にエラーが発生した場合のＲＭ２についてのデー
タの変化の様子を示す図である。

【図１６】 第１実施例の処理においてデータ実更新時
にエラーが発生した場合のＲＭ１についてのデータの変
化の様子を示す図である。

【図１７】 第３実施例の正常処理時のＲＭ１について
のデータの変化の様子を示す図である。

【図１８】 第３実施例の正常処理時のＲＭ２について
のデータの変化の様子を示す図である。

【図１９】 第３実施例におけるＴＭについてのデータ
の変化の様子を示す図である。

【図２０】 第３実施例のデータ実更新時にエラーが発
生した場合のＲＭ１についてのデータの変化の様子を示
す図である。

【図２１】 第３実施例のデータ実更新時にエラーが発
生した場合のＲＭ２についてのデータの変化の様子を示
す図である。

【符号の説明】

１，２ データベース管理システム（ＲＭ）、３，４
ログバッファ、５，６データバッファ、７，８ ロック
管理テーブル、９，１０ ログ領域、１１，１２ デー
タ領域、１３ トランザクションマネージャ（ＴＭ）、
１４ ＴＭログバッファ、１５ ＴＭログ領域、１６
アプリケーションプログラム（ＡＰＰ）。

Claims (4)

【特許請求の範囲】
1. 【請求項１】 データの記憶及び更新を行う複数のデー
   タ記憶部と、各データ記憶部のロールバックに必要な情
   報を保持するロールバック情報保持部と、前記複数のデ
   ータ記憶部と通信を行ってトランザクション処理の管理
   を行うトランザクション管理部と、このトランザクショ
   ン管理部の処理に関するログを保持するトランザクショ
   ンログ保持部と、を有する分散システムにおいて、トラ
   ンザクション処理の終了時に、各データ記憶部について
   コミット処理が可能か否かの確認を行い、すべてのデー
   タ記憶部がコミット処理可能な場合にのみ各データ記憶
   部のデータの実更新を行うことにより、複数のデータ記
   憶部のデータの同期更新を保証する分散トランザクショ
   ン処理方法であって、 各データ記憶部のデータ実更新処理の後に、トランザク
   ション管理部にてすべてのデータ記憶部の実更新が成功
   したか否かを判定し、 判定の結果すべてのデータ記憶部の実更新が成功であっ
   た場合には、前記ロールバック情報保持部を解放してト
   ランザクションを終了し、 判定の結果一つでも実更新が失敗したデータ記憶部があ
   った場合には、当該実更新の失敗したデータ記憶部以外
   のデータ記憶部において前記ロールバック情報保持部及
   びトランザクションログ保持部の情報を用いてロールバ
   ック処理を行い、このロールバック処理の後に前記ロー
   ルバック情報保持部を解放してトランザクションを終了
   することを特徴とする分散トランザクション処理方法。
2. 【請求項２】 請求項１に記載の分散トランザクション
   処理方法であって、 各データ記憶部についてのコミット処理の可否の確認の
   前に、コミット処理の開始を示すログを前記トランザク
   ションログ保持部に記憶し、 すべてのデータ記憶部の実更新が成功したか否かの判定
   の結果、すべてのデータ記憶部の実更新が成功であった
   ら、実更新が成功した旨を示すログをトランザクション
   ログ保持部に記憶し、 分散システムに障害が発生した場合においてその障害か
   ら回復したときには、各データ記憶部はトランザクショ
   ンログ保持部を参照し、トランザクションログ保持部に
   前記実更新が成功した旨を示すログが存在する場合には
   各データ記憶部はコミット処理を続行して前記ロールバ
   ック情報保持部を解放し、前記実更新が成功した旨を示
   すログが存在せず前記コミット処理の開始を示すログが
   存在する場合には各データ記憶部はロールバック処理を
   行ったのち前記ロールバック情報保持部を解放すること
   を特徴とする分散トランザクション処理方法。
3. 【請求項３】 データの記憶及び更新を行う複数のデー
   タ記憶部と、各データ記憶部が行った処理に関するログ
   を保持するロールバック情報保持部と、前記複数のデー
   タ記憶部と通信を行ってトランザクション処理の管理を
   行うトランザクション管理部と、このトランザクション
   管理部の処理に関するログを保持するトランザクション
   ログ保持部と、を有する分散システムにおいて、トラン
   ザクション処理の終了時に、各データ記憶部についてコ
   ミット処理が可能か否かの確認を行い、すべてのデータ
   記憶部がコミット処理可能な場合にのみ各データ記憶部
   のデータの実更新を行うことにより、複数のデータ記憶
   部のデータの同期更新を保証する分散トランザクション
   処理方法であって、 各データ記憶部のデータ実更新処理の後に、トランザク
   ション管理部にてすべてのデータ記憶部の実更新が成功
   したか否かを判定し、 判定の結果一つでも実更新が失敗したデータ記憶部があ
   った場合には、当該実更新の失敗したデータ記憶部以外
   のデータ記憶部において前記ロールバック情報保持部の
   情報を用いてロールバック処理を行い、このロールバッ
   ク処理の後に前記ロールバック情報保持部を解放してト
   ランザクションを終了し、 判定の結果すべてのデータ記憶部の実更新が成功であっ
   た場合には、このトランザクションに関する前記ロール
   バック情報保持部の情報を保持したままトランザクショ
   ンを終了し、次のトランザクションの開始時におけるト
   ランザクション管理部からデータ記憶部へのトランザク
   ション開始指示と同時に当該ロールバック情報保持部の
   解放指示を行い、この解放指示に従って前記ロールバッ
   ク情報保持部を解放することを特徴とする分散トランザ
   クション処理方法。
4. 【請求項４】 請求項３に記載の分散トランザクション
   処理方法であって、 各データ記憶部についてのコミット処理の可否の確認の
   前に、コミット処理の開始を示すログを前記トランザク
   ションログ保持部に記憶し、 すべてのデータ記憶部の実更新が成功したか否かの判定
   の結果、すべてのデータ記憶部の実更新が成功であった
   ら、実更新が成功した旨を示すログをトランザクション
   ログ保持部に記憶し、 分散システムに障害が発生した場合においてその障害か
   ら回復したときに、各データ記憶部は、トランザクショ
   ンログ保持部を参照し、トランザクションログ保持部に
   前記実更新が成功した旨を示すログが存在せず前記コミ
   ット処理の開始を示すログが存在する場合には各データ
   記憶部はロールバック処理を行ったのち前記ロールバッ
   ク情報保持部を解放し、前記実更新が成功した旨を示す
   ログが存在する場合には各データ記憶部はコミット処理
   を続行して前記ロールバック情報保持部を解放せずにト
   ランザクションを終了し次のトランザクションの開始時
   に前記ロールバック情報保持部を解放することを特徴と
   する分散トランザクション処理方法。