JPH0887436A - 分散ｄｂ処理方式 - Google Patents

Abstract

(57)【要約】 【目的】 確実かつ迅速にＤＢ不整合を発見できるよう
にする。 【構成】 トランザクション処理部２１は、サーバ３お
よび４からのＤＢ更新応答が「正常終了」を示すもので
ある場合にのみＤＢ２３内の更新対象のレコードの更新
を行い、ＤＢ不整合の有無を示す情報を有するＤＢ更新
応答をクライアント１に返却する。バージョン番号制御
部２２は、ＤＢ２３内の更新対象のレコード中のバージ
ョン番号に基づく番号判定情報をサーバ３および４への
ＤＢ更新要求に付加する。トランザクション処理部３１
および４１は、バージョン番号の正当性が認識された場
合にのみＤＢ３３および４３内の更新対象のレコードの
更新を行い、更新前バージョン番号を有するＤＢ更新応
答をサーバ２に返却する。バージョン番号制御部３２お
よび４２は、ＤＢ３３および４３内の更新対象のレコー
ド中のバージョン番号の正当性を番号判定情報に基づい
て判定する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、サーバクライアントモ
デルによって実現される分散ＤＢ（ＤａｔａＢａｓｅ。
データベース）トランザクション処理システムにおける
分散ＤＢ処理方式に関し、特に以下の〜に示すよう
な特徴を有する分散ＤＢ処理方式に関する。 複数のサーバが存在し、各サーバが同一のＤＢを所
有している。ここで、各サーバにおける当該ＤＢ内の各
レコードのデータは同一となっていなければならない。 ＤＢ更新のためのトランザクション要求は１つのサ
ーバに対して与えられる。このサーバはＤＢ更新に関し
てマネージャとして機能するサーバ（以下、「マネージ
ャサーバ」という）に該当し、他のサーバはＤＢ更新に
関してエージェントとして機能するサーバ（以下、「エ
ージェントサーバ」という）に該当する。 ＤＢ更新の確定に際しては、２フェーズコミット処
理（準備フェーズ処理およびコミットフェーズ処理の２
フェーズからなる処理）が実行される。

【０００２】

【従来の技術】図５は、従来のこの種の分散ＤＢ処理方
式の一例の構成を示すブロック図である。

【０００３】この分散ＤＢ処理方式は、クライアント５
１と、サーバ５２〜５４とを含んで構成されている。こ
こで、サーバ５２がＤＢ更新に関するマネージャサーバ
に該当し、サーバ５３および５４がＤＢ更新に関するエ
ージェントサーバに該当する。また、クライアント５１
は、ＤＢ更新のためのトランザクション要求を発行でき
るクライアントである（クライアントはクライアント５
１を含んで複数存在している）。なお、クライアント５
１およびサーバ５２〜５４は、１つのネットワークに接
続されている。

【０００４】サーバ５２は、トランザクション処理部５
２１と、ＤＢ５２２とを含んで構成されている。

【０００５】サーバ５３は、トランザクション処理部５
３１と、ＤＢ５３２とを含んで構成されている。

【０００６】サーバ５４は、トランザクション処理部５
４１と、ＤＢ５４２とを含んで構成されている。

【０００７】ＤＢ５２２，５３２および５４２には、Ｄ
Ｂ更新のためのトランザクション要求に基づいて更新さ
れるレコードが格納されている。ここで、ＤＢ５２２，
５３２および５４２は、それぞれ同一の内容を有してい
る。

【０００８】次に、このように構成された従来の分散Ｄ
Ｂ処理方式の動作について、図６のタイムチャートを参
照して説明する。

【０００９】クライアント５１は、サーバ５２内のトラ
ンザクション処理部５２１に対してＤＢ更新要求（トラ
ンザクション要求の一種）を発行し、そのＤＢ更新要求
に対応するＤＢ更新応答（トランザクション応答の一
種）を待ち合わせる。

【００１０】トランザクション処理部５２１は、クライ
アント５１からのＤＢ更新要求を受け取ると、自己（ト
ランザクション処理部５２１），サーバ５３内のトラン
ザクション処理部５３１，およびサーバ５４内のトラン
ザクション処理部５４１に対してＤＢ更新要求を発行す
る。

【００１１】トランザクション処理部５２１，５３１お
よび５４１は、トランザクション処理部５２１からのＤ
Ｂ更新要求に基づいて、それぞれＤＢ５２２，５３２お
よび５４２内のレコード（当該ＤＢ更新要求に係る更新
対象のレコード）を更新し、更新が正常に終了した場合
には「正常終了」を示すＤＢ更新応答をトランザクショ
ン処理部５２１に返却する。

【００１２】トランザクション処理部５２１は、トラン
ザクション処理部５２１，５３１および５４１からのＤ
Ｂ更新応答が全て「正常終了」を示すものであるか否か
を判定する。この判定で全て「正常終了」を示すＤＢ更
新応答である場合には、クライアント５１に対して「正
常終了」を示すＤＢ更新応答を返却する。また、いずれ
かのＤＢ更新応答が「異常終了」を示すものである場合
には、クライアント５１に対して「異常終了」を示すＤ
Ｂ更新応答を返却する。

【００１３】クライアント５１は、トランザクション処
理部５２１から「異常終了」を示すＤＢ更新応答を受け
取ると、トランザクション処理部５２１に対してロール
バック要求（トランザクション要求の一種）を発行す
る。

【００１４】トランザクション処理部５２１は、このロ
ールバック要求に基づいて、自己（トランザクション処
理部５２１），サーバ５３内のトランザクション処理部
５３１，およびサーバ５４内のトランザクション処理部
５４１に対してロールバック要求を発行する。

【００１５】トランザクション処理部５２１，５３１お
よび５４１は、このロールバック要求に基づいてＤＢ５
２２，５３２および５４２に対するロールバック処理を
行う。

【００１６】一方、クライアント５１は、トランザクシ
ョン処理部５２１から「正常終了」を示すＤＢ更新応答
を受け取ると、トランザクション処理部５２１に対して
２フェーズコミット要求（トランザクション要求の一
種）を発行する。

【００１７】トランザクション処理部５２１は、この２
フェーズコミット要求に基づいて、２フェーズコミット
処理（準備フェーズ処理とコミットフェーズ処理との２
フェーズの処理からなるコミット処理）を制御する。

【００１８】すなわち、まず、トランザクション処理部
５２１は、自己（トランザクション処理部５２１），サ
ーバ５３内のトランザクション処理部５３１，およびサ
ーバ５４内のトランザクション処理部５４１に対して準
備フェーズ処理要求を発行する。

【００１９】トランザクション処理部５２１，５３１お
よび５４１は、トランザクション処理部５２１からの準
備フェーズ処理要求に基づいて、ＤＢ５２２，５３２お
よび５４２内の当該レコード（更新対象のレコード）に
対する準備フェーズ処理を行う。準備フェーズ処理が正
常に終了した場合にはトランザクション処理部５２１に
対して「正常終了」を示す準備フェーズ処理応答（トラ
ンザクション応答の一種）を返却し、準備フェーズ処理
が正常に終了しなかった場合にはトランザクション処理
部５２１に対して「異常終了」を示す準備フェーズ処理
応答を返却する。

【００２０】トランザクション処理部５２１は、トラン
ザクション処理部５２１，５３１および５４１からの準
備フェーズ処理応答が全て「正常終了」を示すものであ
るか否かを判定する。

【００２１】トランザクション処理部５２１は、全ての
準備フェーズ処理応答が「正常終了」を示すものである
と判定した場合には、コミットフェーズ処理要求（トラ
ンザクション要求の一種）を自己（トランザクション処
理部５２１），サーバ５３内のトランザクション処理部
５３１，およびサーバ５４内のトランザクション処理部
５４１に対して発行する。また、クライアント５１に対
して、「正常終了」を示す２フェーズコミット応答（ト
ランザクション応答の一種）を返却する。

【００２２】トランザクション処理部５２１，５３１お
よび５４１は、トランザクション処理部５２１からのコ
ミットフェーズ処理要求に基づいて、ＤＢ５２２，５３
２および５４２内の当該レコードに対するコミットフェ
ーズ処理を行う（これによって、このＤＢ更新が確定し
たことになる）。

【００２３】一方、トランザクション処理部５２１は、
いずれかの準備フェーズ処理応答が「異常終了」を示す
ものであると判定した場合には、自己（トランザクショ
ン処理部５２１），サーバ５３内のトランザクション処
理部５３１およびサーバ５４内のトランザクション処理
部５４１に対してロールバック要求を発行する。また、
クライアント５１に対して、「異常終了」を示す２フェ
ーズコミット応答を返す。

【００２４】トランザクション処理部５２１，５３１お
よび５４１は、このロールバック要求に基づいてＤＢ５
２２，５３２および５４２に対するロールバック処理を
行う。

【００２５】一般に、分散ＤＢ処理方式では、各サーバ
におけるＤＢ更新に際して、以上のような一連のトラン
ザクション要求およびトランザクション応答の交換がネ
ットワークを介して行われている。このことは、従来の
分散ＤＢ処理方式に限らず、本発明の分散ＤＢ処理方式
においても基本的には同様である。

【００２６】ここで、図６中の☆で示す時点で、ネット
ワークやいずれかのサーバに障害が生じた場合には、あ
るサーバについてはＤＢ更新がコミットされているが、
他のサーバについては当該ＤＢ更新がコミットされずに
更新前の状態にロールバックされているという状況が生
じうる。

【００２７】例えば、図６中の☆で示す時点でサーバ５
３に障害が生じた場合には、サーバ５３においては、Ｄ
Ｂ５３２に対するコミットフェーズ処理が行われること
なく再立上げが行われ、その後にロールバック処理が行
われる。これに対して、当該障害の発生にもかかわら
ず、サーバ５２および５４においては、ＤＢ５２２およ
び５４２に対するコミットフェーズ処理が行われる。

【００２８】また、例えば、図６中の☆で示す時点で生
じたネットワーク障害によってコミットフェーズ処理要
求がサーバ５３にだけ届かなかった場合には、サーバ５
３においてだけタイムアウト機能に基づくＤＢ５３２に
対するロールバック処理が行われる。

【００２９】このように、分散ＤＢ処理方式（従来技術
はもちろん本発明においても）では、以上のようなタイ
ミングで、各サーバ内のＤＢ間の不整合（レコード内の
データの不一致）が生じるおそれがある。

【００３０】従来の分散ＤＢ処理方式では、このように
して各サーバ内のＤＢ間の不整合（以下、「ＤＢ不整
合」という）が生じた場合に、レコード内のデータその
ものの相違でしかそのＤＢ不整合を検出することができ
なかった。すなわち、ＤＢ内のレコード中にはＤＢ不整
合を検出するための情報（本発明における「バージョン
番号」のような情報）が存在しなかった。

【００３１】

【発明が解決しようとする課題】上述した従来の分散Ｄ
Ｂ処理方式では、ＤＢ不整合が生じた場合に、そのＤＢ
不整合をレコード内のデータそのものの相違でしか検出
できなかったので、以下の〜に示すような問題点が
あった。

【００３２】 ＤＢが参照される際には１つのサーバ
内のＤＢだけが参照され、ＤＢ更新要求がクライアント
から操作者によって与えられる場合には１つのＤＢの参
照に基づいて全てのＤＢに対するＤＢ更新要求が与えら
れる。したがって、ＤＢ不整合が生じた後に当該ＤＢ不
整合を発見することは困難である。また、ＤＢ不整合が
生じた後に、不一致のレコードに対する更新処理が行わ
れ、誤った内容で整合性が回復される場合が生じうる。
この場合には、レコードのデータそのものの不一致によ
ってＤＢ不整合の発生を検出することは不可能となる。

【００３３】 レコードのデータそのものの相違によ
って後にＤＢ不整合が検出されたとしても、どの時点の
ＤＢ更新によってそのＤＢ不整合が生じたかを特定する
ことができない。また、どのＤＢ内のレコードが正しい
データを有しているかを特定することが困難である。

【００３４】 以上のおよびの問題点に起因し
て、分散ＤＢトランザクション処理システムの運用に支
障が生じるおそれがある。すなわち、ＤＢ不整合に起因
して、ＤＢ更新に関する大幅な処理の再実行が必要にな
って当該分散ＤＢトランザクション処理システムの運用
効率が悪くなることや、各サーバ内のＤＢにおけるデー
タの信頼性が低下すること等が生じうる。

【００３５】本発明の目的は、上述の点に鑑み、バージ
ョン番号を各ＤＢ内のレコードに付加すること等によ
り、ある更新によって不一致が生じたレコードの次の更
新時に当該ＤＢ不整合（そのレコードの不一致によるＤ
Ｂ不整合）を検出できるようにし、ＤＢ不整合が生じて
も確実かつ迅速に当該ＤＢ不整合を発見することができ
る分散ＤＢ処理方式を提供することにある。

【００３６】なお、分散ＤＢシステムにおけるバージョ
ン管理に関する従来技術としては、「特開平３−９１０
７６号公報（分散データベースシステムにおける辞書管
理方式）」が開示されている。しかし、この公報に係る
従来技術は、「データベースのアクセス先を特定する辞
書管理情報を分散管理した場合の同期制御にバージョン
情報を利用する事を目的としており」（当該公報中の第
６３０頁左上欄第１３〜１５行参照）、ＤＢ不整合の検
出にバージョン番号を使用して当該不整合の検出を容易
にすること等を目的とする本発明とは構成等を異にする
ものである。

【００３７】

【課題を解決するための手段】本発明の分散ＤＢ処理方
式は、サーバクライアントモデルによって実現される分
散ＤＢトランザクション処理システムにおける分散ＤＢ
処理方式において、データの更新の世代を示すバージョ
ン番号とデータとからなるレコードを格納する各サーバ
内のＤＢと、クライアントからのＤＢ更新要求に基づい
て自ＤＢから更新対象のレコードを取得し、全エージェ
ントサーバからのＤＢ更新応答が「正常終了」を示すも
のである場合にのみ当該レコードの更新を行い、ＤＢ不
整合の有無を示す情報を有するＤＢ更新応答をクライア
ントに返却するマネージャトランザクション処理部と、
このマネージャトランザクション処理部によって取得さ
れたレコード中のバージョン番号を抽出し、そのバージ
ョン番号に基づく番号判定情報をエージェントサーバへ
のＤＢ更新要求に付加するマネージャバージョン番号制
御部と、マネージャサーバからのＤＢ更新要求に基づい
て自ＤＢから更新対象のレコードを取得し、バージョン
番号の正当性が認識された場合にのみ当該ＤＢ更新要求
に基づく当該レコードの更新を行い、更新前バージョン
番号を有するＤＢ更新応答をマネージャサーバに返却す
るエージェントトランザクション処理部と、このエージ
ェントトランザクション処理部によって取得されたレコ
ード中のバージョン番号の正当性をマネージャサーバか
らのＤＢ更新要求に付加された番号判定情報に基づいて
判定するエージェントバージョン番号制御部とを有す
る。

【００３８】

【作用】本発明の分散ＤＢ処理方式では、各サーバ内の
ＤＢがデータの更新の世代を示すバージョン番号とデー
タとからなるレコードを格納し、マネージャトランザク
ション処理部がクライアントからのＤＢ更新要求に基づ
いて自ＤＢから更新対象のレコードを取得し全エージェ
ントサーバからのＤＢ更新応答が「正常終了」を示すも
のである場合にのみ当該レコードの更新を行いＤＢ不整
合の有無を示す情報を有するＤＢ更新応答をクライアン
トに返却し、マネージャバージョン番号制御部がマネー
ジャトランザクション処理部によって取得されたレコー
ド中のバージョン番号を抽出しそのバージョン番号に基
づく番号判定情報をエージェントサーバへのＤＢ更新要
求に付加し、エージェントトランザクション処理部がマ
ネージャサーバからのＤＢ更新要求に基づいて自ＤＢか
ら更新対象のレコードを取得しバージョン番号の正当性
が認識された場合にのみ当該ＤＢ更新要求に基づく当該
レコードの更新を行い更新前バージョン番号を有するＤ
Ｂ更新応答をマネージャサーバに返却し、エージェント
バージョン番号制御部がエージェントトランザクション
処理部によって取得されたレコード中のバージョン番号
の正当性をマネージャサーバからのＤＢ更新要求に付加
された番号判定情報に基づいて判定する。

【００３９】

【実施例】次に、本発明について図面を参照して詳細に
説明する。

【００４０】図１は、本発明の一実施例に係る分散ＤＢ
処理方式の構成を示すブロック図である。

【００４１】本実施例の分散ＤＢ処理方式は、クライア
ント１と、サーバ２〜４とを含んで構成されている。こ
こで、サーバ２がＤＢ更新に関するマネージャサーバに
該当し、サーバ３および４がＤＢ更新に関するエージェ
ントサーバに該当する（エージェントサーバの数が２に
限られものでないことはいうまでもない）。また、クラ
イアント１は、ＤＢ更新のためのトランザクション要求
を発行できるクライアントである（クライアントはクラ
イアント１を含んで複数存在している）。なお、クライ
アント１およびサーバ２〜４は、１つのネットワークに
接続されている。

【００４２】サーバ２は、トランザクション処理部２１
（マネージャトランザクション処理部）と、バージョン
番号制御部２２（マネージャバージョン番号制御部）
と、ＤＢ２３とを含んで構成されている。

【００４３】サーバ３は、トランザクション処理部３１
（エージェントトランザクション処理部）と、バージョ
ン番号制御部３２（エージェントバージョン番号制御
部）と、ＤＢ３３とを含んで構成されている。

【００４４】サーバ４は、トランザクション処理部４１
（エージェントトランザクション処理部）と、バージョ
ン番号制御部４２（エージェントバージョン番号制御
部）と、ＤＢ４３とを含んで構成されている。

【００４５】ＤＢ２３，３３および４３には、ＤＢ更新
のためのトランザクション要求に基づいて更新されるレ
コードが格納されている。ここで、ＤＢ２３，３３およ
び４３は、それぞれ同一の内容を有している。

【００４６】図２は、ＤＢ２３，３３および４３内のレ
コードの構成を示す図である。このレコードは、バージ
ョン番号とデータとからなる。バージョン番号は、トラ
ンザクション処理におけるデータの更新の世代を示す情
報である（ＤＢ不整合が生じていないとすると、各ＤＢ
２３，３３および４３内の同一レコード中のバージョン
番号は等しい）。本実施例の分散ＤＢ処理方式では、バ
ージョン番号の初期値が１であり、データが更新される
毎にその値に１が加算され、それによってデータの更新
の世代が示される。

【００４７】図３は、本実施例の分散ＤＢ処理方式にお
けるマネージャサーバ（サーバ２）の処理を示す流れ図
である。この処理は、ＤＢ更新要求受取りステップ３０
１と、更新対象レコード取得ステップ３０２と、バージ
ョン番号抽出ステップ３０３と、バージョン番号加算ス
テップ３０４と、ＤＢ更新要求番号判定情報付加ステッ
プ３０５と、ＤＢ更新要求発行ステップ３０６と、ＤＢ
更新応答受取りステップ３０７と、ＤＢ更新応答判定ス
テップ３０８と、更新対象レコード更新ステップ３０９
と、ＤＢ更新応答返却ステップ３１０と、ＤＢ更新応答
返却ステップ３１１とからなる。

【００４８】図４は、本実施例の分散ＤＢ処理方式にお
けるエージェントサーバ（サーバ３および４）の処理を
示す流れ図である。この処理は、ＤＢ更新要求受取りス
テップ４０１と、更新対象レコード取得ステップ４０２
と、バージョン番号抽出ステップ４０３と、バージョン
番号比較判定ステップ４０４と、リターン値「正常」設
定ステップ４０５と、リターン値「異常」設定ステップ
４０６と、リターン値判定ステップ４０７と、レコード
更新ステップ４０８と、ＤＢ更新応答返却ステップ４０
９と、ＤＢ更新応答返却ステップ４１０とからなる。

【００４９】図７は、本実施例の分散ＤＢ処理方式にお
けるトランザクション要求およびトランザクション応答
の交換の態様を、図６に示す従来技術におけるトランザ
クション要求およびトランザクション応答の交換の態様
と対比して示す図（タイムチャート）である。

【００５０】次に、このように構成された本実施例の分
散ＤＢ処理方式の動作について説明する。

【００５１】第１に、本実施例の分散ＤＢ処理方式にお
けるマネージャサーバ（サーバ２）の動作（関連するク
ライアント１の動作を含む）について説明する（図３中
のステップ３０１〜３０６および図７参照）。

【００５２】クライアント１は、ネットワークで接続さ
れたサーバ２内のトランザクション処理部２１に対して
ＤＢ更新要求を発行し、そのＤＢ更新要求に対応するＤ
Ｂ更新応答を待ち合わせる。

【００５３】トランザクション処理部２１は、クライア
ント１からのＤＢ更新要求を受け取ると（ステップ３０
１）、自ＤＢ（ＤＢ２３）から所望のレコード（当該Ｄ
Ｂ更新要求に係るトランザクションメッセージ（電文）
によって示されている更新対象のレコード）を取得する
（ステップ３０２）。

【００５４】バージョン番号制御部２２は、そのレコー
ド中のバージョン番号の値（ここでは、ｎとする）を抽
出し（ステップ３０３）、そのバージョン番号の値
（ｎ）に１を加算し（ステップ３０４）、その値（ｎ＋
１）をクライアント１からのＤＢ更新要求に係るトラン
ザクションメッセージに付加する（ステップ３０５）。
この値（ｎ＋１）が、番号判定情報に該当する。

【００５５】トランザクション処理部２１は、サーバ３
内のトランザクション処理部３１，およびサーバ４内の
トランザクション処理部４１に対して、そのトランザク
ションメッセージを有するＤＢ更新要求を発行し（ステ
ップ３０６）、サーバ３および４からのＤＢ更新応答を
待ち合わせる。

【００５６】第２に、本実施例の分散ＤＢ処理方式にお
けるエージェントサーバ（サーバ３および４）の動作
（関連するクライアント１の動作を含む）について説明
する（図４および図７参照）。ここでは、サーバ３の動
作について説明するが、サーバ４の動作についてもこの
動作と同様の動作が行われる。

【００５７】サーバ３内のトランザクション処理部３１
は、トランザクション処理部２１からのＤＢ更新要求を
受け取ると（ステップ４０１）、自ＤＢ（ＤＢ３３）か
ら所望のレコード（当該ＤＢ更新要求に係るトランザク
ションメッセージによって示されている更新対象のレコ
ード）を取得する（ステップ４０２）。

【００５８】バージョン番号制御部３２は、そのレコー
ド中のバージョン番号の値を抽出し（ステップ４０
３）、その値に１を加算した値とＤＢ更新要求に係るト
ランザクションメッセージに付加された番号判定情報の
値（この場合にはｎ＋１）とを比較して、「ＤＢ更新要
求に係るトランザクションメッセージに付加された番号
判定情報の値＝ＤＢ３３内の当該レコード中のバージョ
ン番号の値＋１」であるか否かを判定する（バージョン
番号の正当性を判定する）（ステップ４０４）。

【００５９】バージョン番号制御部３２は、ステップ４
０４の比較で「番号判定情報の値＝ＤＢ３３内の当該レ
コード中のバージョン番号の値＋１」であると判定した
場合には、バージョン番号の正当性を認識し、リターン
値に「正常」を設定してトランザクション処理部３１に
制御を戻す（ステップ４０５）。

【００６０】一方、バージョン番号制御部３２は、ステ
ップ４０４の比較で「番号判定情報の値≠ＤＢ３３内の
当該レコード中のバージョン番号の値＋１」であると判
定した場合には、バージョン番号が正当でないことを認
識し、リターン値に「異常」を設定してトランザクショ
ン処理部３１に制御を戻す（ステップ４０６）。

【００６１】トランザクション処理部３１は、バージョ
ン番号制御部３２から戻されたリターン値が「正常」で
あるか「異常」であるかを判定する（ステップ４０
７）。

【００６２】トランザクション処理部３１は、ステップ
４０７で「リターン値が「正常」である」と判定した場
合には、当該レコード（更新対象のレコード）の更新
（当該レコード中のバージョン番号の値に「ｎ＋１」を
設定し、当該レコード中のデータをＤＢ更新要求に基づ
いて更新すること）を行う（ステップ４０８）。その上
で、その更新の結果に応じて、トランザクション処理部
２１に対してＤＢ更新応答（その更新が正常に行われた
場合には「正常終了」を示し、その更新が正常に行われ
なかった場合には「異常終了」を示すＤＢ更新応答）を
返却する（ステップ４０９）。なお、このＤＢ更新応答
には、ＤＢ３３内の更新前の当該レコード中のバージョ
ン番号（更新前バージョン番号）が付加される。

【００６３】また、トランザクション処理部３１は、ス
テップ４０７で「リターン値が「異常」である」と判定
した場合には、当該レコードの更新を行わずにトランザ
クション処理部２１に「異常終了」を示すＤＢ更新応答
（更新前バージョン番号が付加されたＤＢ更新応答）を
返却する（ステップ４１０）。

【００６４】第３に、再び、マネージャサーバ（サーバ
２）の動作（関連するクライアント１の動作を含む）に
ついて説明する（図３中のステップ３０７〜３１１およ
び図７参照）。

【００６５】サーバ２内のトランザクション処理部２１
は、サーバ３および４からのＤＢ更新応答を受け取ると
（ステップ３０７）、トランザクション処理部３１から
のＤＢ更新応答およびトランザクション処理部４１から
のＤＢ更新応答が全て「正常終了」を示すものであるか
否かを判定する（ステップ３０８）。

【００６６】トランザクション処理部２１は、ステップ
３０８で「全てのＤＢ更新応答が「正常終了」を示すも
のである」と判定した場合には、自己（トランザクショ
ン処理部２１）に対してＤＢ更新要求を発行し、そのＤ
Ｂ更新要求に基づいて自ＤＢ（ＤＢ２３）内の当該レコ
ードの更新（当該レコード中のバージョン番号の値に
「ｎ＋１」を設定し、当該レコード中のデータをＤＢ更
新要求に基づいて更新すること）を行う（ステップ３０
９）。その上で、その更新の結果に応じて、クライアン
ト１に対してＤＢ更新応答（その更新が正常に行われた
場合には「正常終了」を示し、その更新が正常に行われ
なかった場合には「異常終了」を示すＤＢ更新応答）を
返却する（ステップ３１０）。なお、このＤＢ更新応答
においては、何らかの情報によって（ＤＢ不整合の発生
を示す情報が付加されていないという形式の情報でもよ
い）、「ＤＢ不整合が生じていないこと」が示される。

【００６７】一方、トランザクション処理部２１は、ス
テップ３０７で「トランザクション処理部３１からのＤ
Ｂ更新応答およびトランザクション処理部４１からのＤ
Ｂ更新応答の少なくとも１つが「異常終了」を示すもの
である」と判定した場合には、自ＤＢ（ＤＢ２３）の更
新を行わず、クライアント１に「異常終了」を示すＤＢ
更新応答を返却する（ステップ３１１）。なお、この際
に、サーバ３および４からのＤＢ更新応答に付加されて
いた更新前バージョン番号とＤＢ２３内の当該レコード
中の更新前のバージョン番号とが全て同一か否かによっ
て、その「異常終了」がＤＢ不整合に基づくものでない
かどうかが判定され、「ＤＢ不整合に基づくものであ
る」と判定された場合（いずれかのバージョン番号が異
なる場合）には「ＤＢ不整合が生じていること」を示す
情報がクライアント１に対するＤＢ更新応答に付加され
る。

【００６８】また、ステップ３１１においては、必要に
応じて、次の処理が行われる（請求項３記載の発明参
照）。すなわち、バージョン番号制御部２２によって抽
出された更新対象のレコード中のバージョン番号とサー
バ３および４からのＤＢ更新応答に付加されていた更新
前バージョン番号とに基づき、どのＤＢ（ＤＢ２３，３
３または４３）内のレコードが誤っているかが特定され
（バージョン番号の値が他よりも小さいレコードが検出
され、そのレコードのデータが誤っていることが特定さ
れる）、その情報（どのＤＢ内のレコードが誤っている
かを示す情報）が当該ＤＢ更新応答に付加される。

【００６９】クライアント１は、トランザクション処理
部２１から「正常終了」を示すＤＢ更新応答を受け取る
と、トランザクション処理部２１に対して２フェーズコ
ミット要求を発行する。また、トランザクション処理部
２１から「異常終了」を示すＤＢ更新応答を受け取る
と、トランザクション処理部２１に対してロールバック
要求を発行する。

【００７０】このようにして、本実施例（ひいては本発
明）では、ＤＢ更新の更新対象のレコードが不一致であ
ってＤＢ不整合が生じている場合には、ＤＢ更新要求に
基づく処理の段階で当該ＤＢ不整合の検出が可能とな
る。なお、上述の２フェーズコミット要求またはロール
バック要求の発行以降の処理については、図７に示して
いるように、図６に示す従来の分散ＤＢ処理方式におけ
ると同様の態様でトランザクション要求およびトランザ
クション応答の交換が行われる。

【００７１】

【発明の効果】以上説明したように本発明は、ＤＢ内に
格納されているレコードにバージョン番号を設定（付
加）し、各サーバにバージョン番号制御部を設けること
により、ある更新によって各サーバ内のＤＢ中のレコー
ドの不一致が生じた場合（ＤＢ不整合が生じた場合）
に、当該レコードの次の更新の際に当該ＤＢ不整合を確
実に検出することができ、当該ＤＢ不整合に基づく分散
ＤＢトランザクション処理システムにおける支障（当該
分散ＤＢトランザクション処理システムの運用効率が悪
くなることや各サーバ内のＤＢにおけるデータの信頼性
が低下すること等）を未然に防止することができるとい
う効果を有する。

【図面の簡単な説明】

【図１】本発明の一実施例に係る分散ＤＢ処理方式の構
成を示すブロック図である。

【図２】図１中のＤＢに格納されているレコードの構成
を示す図である。

【図３】図１に示す分散ＤＢ処理方式におけるマネージ
ャサーバにおける処理を示す流れ図である。

【図４】図１に示す分散ＤＢ処理方式におけるエージェ
ントサーバにおける処理を示す流れ図である。

【図５】従来の分散ＤＢ処理方式の一例の構成を示すブ
ロック図である。

【図６】図５に示す従来の分散ＤＢ処理方式におけるト
ランザクション要求およびトランザクション応答の交換
の態様を示す図（タイムチャート）である。

【図７】図１に示す分散ＤＢ処理方式におけるトランザ
クション要求およびトランザクション応答の交換の態様
を、図６に示す従来技術におけるトランザクション要求
およびトランザクション応答の交換の態様と対比して示
す図（タイムチャート）である。

【符号の説明】

１ クライアント ２ サーバ（マネージャサーバ） ３，４ サーバ（エージェントサーバ） ２１ トランザクション処理部（マネージャトランザク
ション処理部） ３１，４１ トランザクション処理部（エージェントト
ランザクション処理部） ２２ バージョン番号制御部（マネージャバージョン番
号制御部） ３２，４２ バージョン番号制御部（エージェントバー
ジョン番号制御部） ２３，３３，４３ ＤＢ

Claims (3)

【特許請求の範囲】
1. 【請求項１】 サーバクライアントモデルによって実現
   される分散ＤＢトランザクション処理システムにおける
   分散ＤＢ処理方式において、 データの更新の世代を示すバージョン番号とデータとか
   らなるレコードを格納する各サーバ内のＤＢと、 クライアントからのＤＢ更新要求に基づいて自ＤＢから
   更新対象のレコードを取得し、全エージェントサーバか
   らのＤＢ更新応答が「正常終了」を示すものである場合
   にのみ当該レコードの更新を行い、ＤＢ不整合の有無を
   示す情報を有するＤＢ更新応答をクライアントに返却す
   るマネージャトランザクション処理部と、 このマネージャトランザクション処理部によって取得さ
   れたレコード中のバージョン番号を抽出し、そのバージ
   ョン番号に基づく番号判定情報をエージェントサーバへ
   のＤＢ更新要求に付加するマネージャバージョン番号制
   御部と、 マネージャサーバからのＤＢ更新要求に基づいて自ＤＢ
   から更新対象のレコードを取得し、バージョン番号の正
   当性が認識された場合にのみ当該ＤＢ更新要求に基づく
   当該レコードの更新を行い、更新前バージョン番号を有
   するＤＢ更新応答をマネージャサーバに返却するエージ
   ェントトランザクション処理部と、 このエージェントトランザクション処理部によって取得
   されたレコード中のバージョン番号の正当性をマネージ
   ャサーバからのＤＢ更新要求に付加された番号判定情報
   に基づいて判定するエージェントバージョン番号制御部
   とを有することを特徴とする分散ＤＢ処理方式。
2. 【請求項２】 初期値が１でありデータが更新される毎
   に１が加算されるバージョン番号とデータとからなるレ
   コードを格納する各サーバ内のＤＢと、 マネージャトランザクション処理部によって取得された
   レコード中のバージョン番号を抽出し、そのバージョン
   番号に１を加算した値である番号判定情報をエージェン
   トサーバへのＤＢ更新要求に付加するマネージャバージ
   ョン番号制御部と、 エージェントトランザクション処理部によって取得され
   たレコード中のバージョン番号に１を加算した値とマネ
   ージャサーバからのＤＢ更新要求に付加された番号判定
   情報とが等しいか否かによってバージョン番号の正当性
   を判定するエージェントバージョン番号制御部とを有す
   ることを特徴とする請求項１記載の分散ＤＢ処理方式。
3. 【請求項３】 マネージャバージョン番号制御部によっ
   て抽出された更新対象のレコード中のバージョン番号と
   エージェントサーバからのＤＢ更新応答に付加された更
   新前バージョン番号とに基づき、どのＤＢ内のレコード
   が誤っているかを特定し、その特定内容を示す情報を有
   するＤＢ更新応答をクライアントに返却するマネージャ
   トランザクション処理部を有することを特徴とする請求
   項１または請求項２記載の分散ＤＢ処理方式。