JP2012022379A - 分散トランザクション処理システム、装置、方法およびプログラム - Google Patents

分散トランザクション処理システム、装置、方法およびプログラム Download PDF

Info

Publication number
JP2012022379A
JP2012022379A JP2010157817A JP2010157817A JP2012022379A JP 2012022379 A JP2012022379 A JP 2012022379A JP 2010157817 A JP2010157817 A JP 2010157817A JP 2010157817 A JP2010157817 A JP 2010157817A JP 2012022379 A JP2012022379 A JP 2012022379A
Authority
JP
Japan
Prior art keywords
transaction
data
state
server
progress
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.)
Granted
Application number
JP2010157817A
Other languages
English (en)
Other versions
JP5480046B2 (ja
Inventor
Yu Adachi
悠 安達
Daigoro Yokozeki
大子郎 横関
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.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2010157817A priority Critical patent/JP5480046B2/ja
Publication of JP2012022379A publication Critical patent/JP2012022379A/ja
Application granted granted Critical
Publication of JP5480046B2 publication Critical patent/JP5480046B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】コーディネータ（サーバ）におけるネットワークI/OおよびディスクI/Oの発生を抑制する。
【解決手段】分散トランザクション処理システムは、それぞれがトランザクション要求に応じた処理を実行し、該実行状態を表すトランザクション状態情報を管理する複数のデータサーバ１１1〜１１nと、データサーバ１１1〜１１nに対するトランザクション要求を調停するトランザクション管理サーバ１０を有する。トランザクション管理サーバ１０は、自サーバにて障害が発生した場合に、その障害の復旧後に、自身が調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、データサーバ１１1〜１１nから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該最終状態に基づいて、データサーバ１１1〜１１nのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。
【選択図】図１

Description

本発明は、BASE（Basically Available、Soft state、Eventually consistent）特性を持った分散トランザクション処理技術に関する。
アプリケーションサーバ、コーディネータおよびデータサーバから構成される２相コミットによる分散データ管理システムが知られている。コーディネータは、アプリケーションサーバから各データサーバへのトランザクション要求を調停する。各データサーバは、トランザクションに関わる参照・更新対象のデータを保持する。
上記の分散データ管理システムでは、コーディネータが、各データサーバに対して、データの参照・更新要求を振り分ける。そして、更新要求に関して、コーディネータのみが、トランザクションに対して更新に関わったデータサーバを更新サーバリストとして永続化していた。
最近では、Webコンテンツの処理などの多少整合性を犠牲にすることができる状況下でのトランザクション管理において、コーディネータが、トランザクションに関連するデータサーバへコミット要求を送信し、その後、全データサーバのコミット実行完了の応答を待たずに、アプリケーションサーバに正常応答を返すという方法がとられている。このように、結果的に整合性を確保するような処理をBASE特性と呼ぶ。
上述したBASE特性を持ったトランザクション処理においては、全データサーバからのコミット実行完了通知を待たずに、コーディネータが何らかの障害によりダウンする可能性がある。この場合、BASE特性により、すでにアプリケーションサーバにトランザクション処理完了通知を返しているため、トランザクション処理を完了させる必要がある。しかし、コーディネータだけが仕掛り中のトランザクション状態を永続化しているため、トランザクションを復旧できないという問題がある。
図１６は、上記問題を解決することが可能な手法を説明するための模式図である。
図１６を参照すると、分散データ管理システムは、アプリケーションサーバ１１０、コーディネータ１１０ａ、１１０ｂ、データサーバ１１１ａ〜１１１ｃおよび共有ディスク１１３からなる。共有ディスク１１３は、コーディネータ１１０ａ、１１０ｂに共通のディスクである。
コーディネータ１１０ａは、自身が仕掛り中のトランザクション状態を管理するために、そのトランザクションに対して更新に関わったデータサーバの更新サーバリスト１１３ａを共有ディスク１１３に格納する。コーディネータ１１０ｂも、同様に、自身が仕掛り中のトランザクション状態を示す更新サーバリストを共有ディスク１１３に格納する。このように、共有ディスク１１３には、コーディネータ毎に更新サーバリストが格納される。
以下に、コーディネータ１１０ａに障害が発生した場合に、コーディネータ１１０ｂが、コーディネータ１１０ａに代わってトランザクションを再開させる手順を簡単に説明する。
アプリケーションサーバ１１０が、コミット要求をコーディネータ１１０ａに送信する。コーディネータ１１０ａは、コミット要求を受信すると、データサーバ１１１ａ〜１１１ｃのそれぞれに対して、まず、プリペア要求を送信し、その後、コミット要求を送信する。
データサーバ１１１ａ〜１１１ｃへのコミット要求の送信後に、コーディネータ１１０ａに障害が発生する。この障害発生時点において、共有ディスク１１３には、コーディネータ１１０ａによって更新サーバリスト１１３ａが格納されている。
この更新サーバリスト１１３ａにおいて、「データサーバＡ」および「データサーバＢ」がともに「commit」の状態とされ、「データサーバＣ」が「prepare」の状態とされている。ここで、「データサーバＡ」、「データサーバＢ」、「データサーバＣ」はそれぞれ、データサーバ１１１ａ、１１１ｂ、１１１ｃに対応する。
障害の発生によりコーディネータ１１０ａがダウンすると、コーディネータ１１０ｂがそれを検知し、共有ディスク１１３上で管理されている更新サーバリスト１１３ａに基づいて、ダウンしたコーディネータ１１０ａが管理していたトランザクションを再開させる。
別の手法として、コーディネータのトランザクション状態をメモリやディスクで永続化しておき、代替コーディネータとトランザクション状態の同期をとる方法がある。これと同様な方法として、特許文献１に記載されたデータベースレプリケーション方法がある。このデータベースレプリケーション方法では、マスタサーバとスレーブサーバの間で、トランザクションの更新履歴情報の同期を行う。
ところで、分散トランザクション処理を扱う場合、コーディネータにおいて、複数のアプリケーションサーバや複数のデータサーバとの通信が発生するため、それがトランザクション処理のボトルネックとなり易い。ボトルネックの要因として、主に、ネットワークI/OとディスクI/Oの実行によるコーディネータの高負荷が挙げられる。したがって、トランザクション処理をより高速に実行するためには、コーディネータの処理性能の向上が重要である。
上記のトランザクション処理のボトルネックの問題を解消するには、コーディネータの負荷を低減する必要がある。
しかし、図１６に示したような手法においては、コーディネータがトランザクション状態を共有ディスクで永続化する際に、ネットワークI/OやディスクI/Oが頻繁に発生するため、コーディネータの負荷が増大する。
別の手法として挙げた、コーディネータのトランザクション状態をメモリやディスクで永続化しておき、代替コーディネータとトランザクション状態の同期をとる方法（特許文献１に記載の方法）においても、同期をとるためにネットワークI/OやディスクI/Oが頻繁に発生する。このため、コーディネータの負荷が増大する。
ネットワークI/OやディスクI/Oを実行することにより生じるコーディネータの高負荷の問題は、平常時の動作（コーディネータやデータサーバに障害が発生していない状態での動作）だけでなく、データサーバやコーディネータに障害が発生した場合の動作においても生じる。
例えば、データサーバに障害が発生した場合、コーディネータは、仕掛中のトランザクション状態を管理しているため、そのまま、それ以降のトランザクションを継続することができる。BASE特性を実現するために、コーディネータは、データサーバの障害を無視して、他のデータサーバのコミット実行完了通知を受信すると、アプリケーションサーバに対して、コミット実行完了通知を返答する。
上記の場合、障害の発生したデータサーバが復旧後に再起動すると、コーディネータにトランザクション要求を問い合わせる必要がある。この場合、復旧したデータサーバのトランザクション処理を完了させるために、コーディネータでは、復旧したデータサーバからコミット実行完了通知を受信するまで、トランザクション状態を永続化するため、ディスクI/Oが発生し、さらには、復旧したデータサーバとのネットワークI/Oが発生する。
このようなディスクI/OやネットワークI/Oの発生のために、コーディネータがトランザクション状態を管理するような構成においては、データサーバの復旧時にコーディネータに対して負荷がかかってしまう。
また、コーディネータに障害が発生した場合は、その障害から復旧したコーディネータまたはその代替えであるコーディネータが、共有ディスクにアクセスして、その障害発生時点の仕掛中のトランザクションの最終状態を取得する。この共有ディスクへのアクセスの際に、ディスクI/Oが発生し、コーディネータの負荷が増大する。
なお、コーディネータは、それ以外のトランザクション処理も調停しているため、コーディネータに対して、データサーバ復旧時の特別な処理による負荷をかけることは望ましくない。
特開２００９−２５２１４９号公報
図１６に示した方法や特許文献１に記載されたような方法においては、トランザクション状態情報を管理する上で、ネットワークI/OとディスクI/Oの発生によるコーディネータの高負荷の問題がある。
加えて、データサーバやコーディネータに障害が発生した場合に、コーディネータに負荷をかけずにBASE特性を実現することが困難であるという問題がある。
本発明の目的は、コーディネータにおけるネットワークI/OおよびディスクI/Oの発生を抑制することで、平常動作時におけるコーディネータの高負荷を回避するとともに、データサーバまたはコーディネータに障害が発生した場合に、コーディネータに負荷をかけずにBASE特性を実現することにある。
上記目的を達成するため、本発明の分散オブジェクション処理システムは、それぞれがトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクョン状態情報を管理する複数のデータサーバと、前記複数のデータサーバに対するトランザクション要求を調停する第１のトランザクション管理サーバと、を有する。前記第１のトランザクション管理サーバは、自サーバにて障害が発生した場合に、その障害の復旧後に、自身が調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、前記複数のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。
本発明の別の態様による分散オブジェクション処理システムは、それぞれがトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する複数のデータサーバと、前記複数のデータサーバに対するトランザクション要求を調停するトランザクション管理サーバと、を有する。前記複数のデータサーバのそれぞれは、自データサーバにて障害が発生した場合に、その障害の復旧後に、自データサーバで実行していた仕掛中のトランザクションに係わるトランザクション状態情報を他のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。
本発明の分散トランザクション処理方法は、複数のデータサーバと第１のトランザクション管理サーバとを有するシステムにおいて行われる分散トランザクション処理方法であって、前記複数のデータサーバのそれぞれが、トランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理するステップと、前記第１のトランザクション管理サーバが、前記複数のデータサーバに対するトランザクション要求を調停するステップと、前記第１のトランザクション管理サーバが、自サーバにて障害が発生した場合に、その障害の復旧後に、自身が調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、前記複数のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行うステップと、を有する。
本発明の別の態様による分散トランザクション処理方法は、複数のデータサーバとトランザクション管理サーバとを有するシステムにおいて行われる分散トランザクション処理方法であって、前記複数のデータサーバのそれぞれが、トランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理するステップと、前記トランザクション管理サーバが、前記複数のデータサーバに対するトランザクション要求を調停するステップと、前記複数のデータサーバのそれぞれが、自データサーバにて障害が発生した場合に、その障害の復旧後に、自データサーバで実行していた仕掛中のトランザクションに係わるトランザクション状態情報を他のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行うステップと、を有する。
本発明のトランザクション管理サーバは、それぞれがトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する複数のデータサーバと相互に通信可能なトランザクション管理サーバであって、自サーバにて障害が発生した場合に、その障害の復旧後に、自身が調停していた仕掛中のトランザクションに係わるトランザクション状態情報を前記複数のデータサーバから収集する情報収集部と、前記情報収集部で収集したトランザクション状態情報に基づいて、前記仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行うトランザクション状態決定部と、を有する。
本発明の別の態様によるトランザクション管理サーバは、それぞれがトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する複数のデータサーバと相互に通信可能なトランザクション管理サーバであって、前記複数のデータサーバに対するトランザクション要求を調停する別のトランザクション管理サーバにて障害が発生した場合に、該別のトランザクション管理サーバが調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、前記複数のデータサーバから収集する情報収集部と、前記情報収集部で収集したトランザクション状態情報に基づいて、前記仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、前記仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行うトランザクション状態決定部と、を有する。
本発明のデータサーバは、トランザクション管理サーバによって調停されたトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する他のデータサーバと相互に通信可能なデータサーバであって、前記トランザクション管理サーバによって調停されたトランザクション要求に基づく処理を実行する実行部と、自データサーバにて障害が発生した場合に、その障害の復旧後に、前記実行部で実行されていた仕掛中のトランザクションに係わるトランザクション状態情報を前記他のデータサーバから収集し、該収集した情報に基づいて該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記他のデータサーバとの整合性をとるための処理を行うトランザクション状態決定部と、を有する。
本発明のさらに別の態様による分散トランザクション処理方法は、それぞれがトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する複数のデータサーバと相互に通信可能なトランザクション管理サーバにおいて行われる分散トランザクション処理方法であって、自サーバにて障害が発生した場合に、その障害の復旧後に、自身が調停していた仕掛中のトランザクションに係わるトランザクション状態情報を前記複数のデータサーバから収集するステップと、前記収集したトランザクション状態情報に基づいて、前記仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるステップと、を有する。
本発明のさらに別の態様による分散トランザクション処理方法は、それぞれがトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する複数のデータサーバと相互に通信可能なトランザクション管理サーバであって、前記複数のデータサーバに対するトランザクション要求を調停する別のトランザクション管理サーバにて障害が発生した場合に、該別のトランザクション管理サーバが調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、前記複数のデータサーバから収集するステップと、前記収集したトランザクション状態情報に基づいて、前記仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、前記仕掛中のトランザクション前後におけるデータの整合性をとるステップと、を有する。
本発明のさらに別の態様による分散トランザクション処理方法は、トランザクション管理サーバによって調停されたトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する他のデータサーバと相互に通信可能なデータサーバにて行われる分散トランザクション処理方法であって、前記トランザクション管理サーバによって調停されたトランザクション要求に基づく処理を実行するステップと、自データサーバにて障害が発生した場合に、その障害の復旧後に、前記実行部で実行されていた仕掛中のトランザクションに係わるトランザクション状態情報を前記他のデータサーバから収集し、該収集した情報に基づいて該トランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるステップと、を有する。
本発明のプログラムは、上記のいずれかのトランザクション管理サーバの機能をコンピュータに実行させる。
本発明の別の態様によるプログラムは、上記のデータサーバの機能をコンピュータに実行させるプログラム。
本発明によれば、ネットワークI/OやディスクI/Oによるコーディネータの高負荷を回避することができ、データサーバ異常時やコーディネータ異常時にも、コーディネータに負荷をかけずにBASE特性を実現できる。
本発明の第１の実施形態である分散トランザクション処理システムの主要な構成を示すブロック図である。 図１に示す構成を適用した分散トランザクション処理の動作の一例を説明するための模式図である。 本発明の第２の実施形態である分散トランザクション処理システムの構成を示すブロック図である。 図３に示す分散トランザクション処理システムにおける、コーディネータが調停するトランザクションの状態遷移を説明するための図である。 図３に示す分散トランザクション処理システムにおける、データサーバが調停するトランザクションの状態遷移を説明するための図である。 図３に示す分散トランザクション処理システムを構成するコーディネータ、死活監視サーバおよびデータサーバのそれぞれの機能モジュールを示すブロック図である。 図３に示す分散トランザクション処理システムのトランザクション解析部にて行われるトランザクション解析処理の一手順を示すフローチャートである。 トランザクションリストの一例を説明するための図である。 データサーバ対応表の一例を説明するための図である。 更新対象データリストの一例を説明するための図である。 データサーバの管理情報を説明するための図である。 コーディネータのトランザクションのリカバリの流れを示す模式図である。 収集したワークスペースからトランザクション状態を復元する手順を説明するための図である。 データサーバ中心の管理構造のワークスペースを、トランザクション中心の管理構造のワークスペースに変更する手順を示すフローチャートである。 トランザクション状態の決定手順を示すフローチャートである。 データサーバのトランザクションのリカバリの流れを説明するための図である。 トランザクション状態を共有ディスクで永続化する手法を説明するための模式図である。
次に、本発明の実施形態について図面を参照して説明する。
（第１の実施形態）
図１は、本発明の第１の実施形態である分散トランザクション処理システムの主要な構成を示すブロック図である。
図１を参照すると、本実施形態の分散トランザクション処理システムは、それぞれがトランザクション要求に応じた処理を実行する複数のデータサーバ１１1〜１１nと、これらデータサーバ１１1〜１１nに対するトランザクション要求を調停するトランザクション管理サーバ１０と、を有する。データサーバ１１1〜１１nおよびトランザクション管理サーバ１０のそれぞれは、ネットワーク１２に接続されており、相互通信が可能である。
トランザクション要求は、不図示のアプリケーションサーバからトランザクション管理サーバ１０を介してデータサーバ１１1〜１１nに供給される。トランザクション管理サーバ１０は、コーディネータであって、アプリケーションサーバからのトランザクション要求を、トランザクションに関わるデータを保有するデータサーバ１１1〜１１nに配信する。
データサーバ１１1〜１１nのそれぞれが、トランザクション要求の実行状態を表すトランザクション状態情報を管理し、外部からの収集要求に応じて該トランザクション状態情報をその収集要求元に供給する。
収集要求元は、トランザクション管理サーバ１０や、データサーバ１１1〜１１nのうち、障害が発生し、その障害が復旧したデータサーバ等である。ここでの復旧とは、障害前のメモリ状態以外のディスクなどに記録された、不揮発性の情報は、障害発生前の状態になることである。
トランザクション管理サーバ１０が収集要求元になるシチュエーションとしては、次の２つがある。第１は、トランザクション管理サーバ１０において、障害が発生し、その障害が復旧した場合に、復旧したトランザクション管理サーバ１０が、上記の収集要求元となるケースである。第２は、ネットワーク１２に接続された不図示の別のトランザクション管理サーバに障害が発生した場合で、この別のトランザクション管理サーバに障害が発生し、その代替えとしてトランザクション管理サーバ１０が用いられる場合に、トランザクション管理サーバ１０が上記の収集要求元となるケースである。
第１のケースにおいて、復旧したトランザクション管理サーバ１０は、障害発生時に自身が調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、データサーバ１１1〜１１nから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、データサーバ１１1〜１１nのそれぞれについて、仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。具体的には、最終状態に従ったトランザクション処理要求を、仕掛中のトランザクションに関わるデータサーバに送信することで、データの整合性をとる。
ここで、トランザクション状態情報の収集動作を具体的に説明する。トランザクション管理サーバ１０は、トランザクションに係わるデータを自サーバ内のメモリ上に保持しているため、ダウン後は、トランザクション状態が分からない。データサーバ１１1〜１１nのそれぞれは、トランザクション要求に応じた処理を実行し、その実行状態を示すトランザクション状態情報を、トランザクション要求元のトランザクション管理サーバ１０の識別情報（ＩＤ）と対応付けて管理する。復旧したトランザクション管理サーバ１０は、自身のＩＤを保持しており、そのＩＤを引数として用いた収集要求をデータサーバ１１1〜１１nに配信する。データサーバ１１1〜１１nは、収集要求に応じて、引数としてのＩＤに基づいて該当するトランザクション状態情報をトランザクション管理サーバ１０に返信する。
第２のケースにおいて、トランザクション管理サーバ１０は、別のトランザクション管理サーバにて障害が発生したことを検知する。障害発生を検知すると、トランザクション管理サーバ１０は、その障害が発生したトランザクション管理サーバの識別情報（ID）を引数として用いた収集要求を、そのトランザクション管理サーバが調停していた仕掛中のトランザクションに関わるデータサーバに送信する。データサーバは、その収集要求に応じて、引数としてのＩＤに基づいて該当するトランザクション状態情報をトランザクション管理サーバ１０に返信する。こうして、トランザクション管理サーバ１０は、障害が発生した別のトランザクション管理サーバが調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、そのトランザクションに関わるデータサーバから収集する。そして、トランザクション管理サーバ１０は、収集したトランザクション状態情報に基づいて、仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクションに関わるデータサーバについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。この整合性をとるための処理も、上記の第１のケースと同様、最終状態に従ったトランザクション処理要求を、仕掛中のトランザクションに関わるデータサーバに送信することで実行される。
データサーバ１１1〜１１nのそれぞれは、自データサーバにて障害が発生した場合に、その障害の復旧後に、自データサーバで実行していた仕掛中のトランザクションに係わるトランザクション状態情報を他のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。
本実施形態の分散トランザクション処理システムによれば、データサーバ１１1〜１１nのトランザクション状態を共有ディスクで管理するのではなく、データサーバ１１1〜１１nのそれぞれで個別に管理する。すなわち、データサーバ１１1〜１１nのそれぞれがトランザクション状態を永続化する。また、データサーバ１１1〜１１nのそれぞれは、収集要求に応じて、自データサーバで管理しているトランザクション状態情報をその収集要求元に供給する。
トランザクション管理サーバ１０は、自サーバに障害が発生し、その障害から復旧した場合に、仕掛中のトランザクションに係わるトランザクション状態情報をデータサーバ１１1〜１１nから収集することで、ディスクI/Oの実行なしで、自サーバの最終の状態（障害発生時点または発生直前の状態）を決定することができる。この結果、ディスクI/Oによる高負荷を回避でき、代替えのトランザクション管理サーバに負荷をかけずに、BASE特性を実現できる。
別のトランザクション管理サーバに障害が発生した場合は、トランザクション管理サーバ１０が、その代替えのサーバとして動作する。この場合、トランザクション管理サーバ１０は、別のトランザクション管理サーバにて実行されていた仕掛中のトランザクションに係わるトランザクション状態情報を、そのトランザクションに関わるデータサーバから収集することで、ディスクI/Oの実行なしで、別のトランザクション管理サーバの最終の状態（障害発生時点の状態）を決定することができる。この場合も、ディスクI/Oによる高負荷を回避でき、代替えのトランザクション管理サーバに負荷をかけずに、BASE特性を実現できる。
また、データサーバ１１1〜１１nのいずれかに障害が発生し、その障害が発生したデータサーバが復旧した場合、復旧したデータサーバは、トランザクション管理サーバ１０にアクセスすることなく、他のデータサーバからそれぞれのトランザクション状態情報を収集して自データサーバに関するトランザクションの最終状態を決定することができる。この結果、コーディネータに負荷をかけずに、BASE特性を実現できる。
加えて、トランザクション状態を共有ディスクで永続化する必要がなく、トランザクション管理サーバ１０と別のトランザクション管理サーバとの間で、メモリやディスクで永続化したトランザクション状態の同期をとる必要もない。よって、データサーバ等に障害が発生していない通常動作時において、トランザクション管理サーバにおけるネットワークI/OおよびディスクI/Oの発生を抑制することができる。
トランザクション管理サーバまたはデータサーバにて障害が発生した場合で、その障害の復旧後に、トランザクション管理サーバ側ではトランザクションは完結したにも関わらず、データサーバ側では、それがデータに反映されていないことによる、データの不整合が生じる。第１のケースでは、トランザクション管理サーバ１０が、復旧後に、仕掛中のトランザクションの最終状態に基づいて、データサーバ１１1〜１１nのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。これにより、それぞれのデータサーバに対するトランザクションの一貫性を保つことができる。この結果、全データサーバ間でのトランザクション状態が同じ（完結）（commit/rollback）になる。
第２のケースでは、トランザクション管理サーバ１０が、障害が発生した別のトランザクション管理サーバの仕掛中のトランザクションの最終状態に基づいて、データサーバ１１1〜１１nのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。この場合も、各データサーバに対するトランザクションの一貫性を保つことができる。
データサーバ１１1〜１１nのそれぞれは、障害の復旧後に、自データサーバで実行していた仕掛中のトランザクションの最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。これによっても、各データサーバに対するトランザクションの一貫性を保つことができる。
図２は、図１に示した構成を適用した分散トランザクション処理の動作の一例を説明するための模式図である。
図２に示す分散トランザクション処理システムは、アプリケーションサーバ（ＡＰＳ）２０、コーディネータ２１、２２およびデータサーバ２３〜２５からなる。コーディネータ２２は、コーディネータ２１の代替えとなるサーバであって、図１に示したトランザクション管理サーバ１０に対応する。コーディネータ２１は、前述した第２のケースにおける別のトランザクション管理サーバに対応する。データサーバ２３〜２５は、図１に示したデータサーバ１１1〜１１nに対応する。
コーディネータ２１は、メモリ２１ａを有し、トランザクション状態を更新サーバリスト２１ｂとしてメモリ２１ａに保持する。アプリケーションサーバ２０からコミット要求を受けると、コーディネータ２１は、データサーバ２３〜２５に対してプリペア要求を送信する。このとき、コーディネータ２１は、メモリ２１ａで保持しているトランザクション状態情報（更新サーバリスト２１ｂ）も一緒にデータサーバ２３〜２５に送信する。
データサーバ２３は、ディスク装置または半導体メモリよりなる記憶部２３ａを有し、プリペア要求に応じた処理を実行した後は、自身のトランザクション状態を記憶部２３ａ上で永続化する。データサーバ２４、２５も、データサーバ２３と同様の構成であり、それぞれが記憶部２４ａ、２４ａを有し、プリペア実行後に、自身のトランザクション状態を永続化する。
なお、プリペア要求の前に、コーディネータ２１がダウンした場合は、アプリケーションサーバ２０は、コーディネータ２１のダウンを検知し、そのトランザクションがロールバックされたとみなし、トランザクションは復旧されない。
プリペア要求の送信後、コーディネータ２１は、データサーバ２３〜２５に対してコミット要求を送信する。データサーバ２３は、コミット要求に応じた処理を実行した後は、記憶部２３ａ上で永続化しているトランザクション状態（更新サーバリスト２３ｂ）を更新する。同様に、データサーバ２４、２５も、コミット実行後に、永続化しているトランザクション状態（更新サーバリスト２４ｂ、２５ｂ）を更新する。
データサーバ２３〜２５によるコミット要求に応じた処理が正常に終了した場合、コーディネータ２１は、データサーバ２３〜２５の全てからコミット／ロールバックの実行完了応答を受信する。この実行完了応答の受信後、コーディネータ２１は、メモリ２１ａ上で管理しているコミット／ロールバックの処理がなされたトランザクションに関する情報（更新サーバリスト２１ｂなど）を全て削除する。
データサーバ２３〜２５のいずれかで、コミット要求に応じた処理が異常終了した場合、コーディネータ２１は、障害の発生したデータサーバに対して、コミット／ロールバック要求を再度送信する。図２では、データサーバ２５が異常終了している状態が示されている。
再度のコミット／ロールバック要求の送信を行っても、正常終了せずに、タイムアウトした場合、コーディネータ２１は、該当トランザクション情報を全て削除する。その後、データサーバが復旧した際には、その復旧したデータサーバは、コーディネータ２１を介さずに、他のデータサーバからトランザクション状態情報を収集して自身のトランザクションの最終状態（障害発生時点のトランザクションの状態）を決定し、トランザクション処理を完了させる。この動作は、図１に示したシステムにおける障害から復旧したデータサーバにて行われる動作に対応する。
プリペア要求の送信後にコーディネータ２１がダウンした場合には、その代替えであるコーディネータ２２が、データサーバ２３〜２５に対して、それぞれが保持しているトランザクション状態を更新サーバリストとして返却するように一斉に問い合わせを行う。データサーバ２３〜２５から返却されたトランザクション状態のうち、少なくとも１つがコミット実行完了状態であり、且つ、あるデータサーバから受信したトランザクション状態がプリペア実行完了状態である場合は、コーディネータ２２は、そのデータサーバに対して、コミット要求を送信する。これにより、トランザクションに関わる全データサーバの更新処理の状態がコミット実行完了状態となるため、トランザクション処理を完遂させることができる。この動作は、図１に示したシステムにおけるトランザクション管理サーバ１０が代替えのサーバとして動作した場合の動作（第２のケースの動作）に対応する。
上記のような動作によれば、コーディネータによるトランザクション状態の管理をメモリ上で行うので、コーディネータのディスクI/Oを減らすことができる。
また、データサーバへのプリペア要求の送信時にトランザクション状態も一緒に送信され、データサーバのそれぞれでトランザクション状態の永続化および更新を個別に行う。この場合、図１６に示したシステムにおける共有ディスクへのアクセスや、特許文献１に記載されたような方法における同期をとるために必要とされるネットワークI/Oは不要である。よって、ディスクI/OやネットワークI/Oの発生を抑制することができる。
さらに、コーディネータ異常時に、データサーバからトランザクション状態を収集することで、仕掛り中のトランザクションを復旧し、BASE特性を実現することができる。
一方、データサーバ障害時には、コーディネータを介さず、トランザクションに関わったデータサーバのみで、トランザクション処理を完了させることができる。
例えば、障害が発生し、その障害が復旧したデータサーバは、再起動時に、自身が永続化している更新サーバリストに載っているデータサーバから、更新サーバリストを収集する。そして、得られた更新サーバリストの内容に基づいて、自身の仕掛中トランザクションの最終状態を決定し、トランザクション処理を完遂させる。
このように、各データサーバが個別にトランザクション状態を永続化することで、データサーバ障害時に、コーディネータを介させずに、トランザクション処理を完遂させることができるので、コーディネータのディスクI/OやネットワークI/Oを軽減させることができる。
なお、図２に示した構成において、コーディネータ２２は、自身に障害が発生し、その障害が復旧した場合に、自身が調停していた仕掛中のトランザクションについて、それぞれが保持しているトランザクション状態を更新サーバリストとして返却するように一斉に問い合わせてもよい。この場合も、例えばデータサーバ２３〜２５から返却されたトランザクション状態のうち、少なくとも１つがコミット実行完了状態であり、且つ、あるデータサーバから受信したトランザクション状態がプリペア実行完了状態である場合は、コーディネータ２２は、そのデータサーバに対して、コミット要求を送信する。これにより、トランザクションに関わる全データサーバの更新処理の状態がコミット実行完了状態となるため、トランザクション処理を完遂させることができる。この動作は、図１に示したシステムにおけるトランザクション管理サーバ１０の障害復旧時の動作（第１のケースの動作）に対応する。
（第２の実施形態）
図３は、本発明の第２の実施形態である分散トランザクション処理システムの構成を示すブロック図である。
本実施形態の分散トランザクション処理システムは、アプリケーションサーバ（ＡＰＳ）３０、コーディネータ３１、死活監視サーバ３２および複数のデータサーバ３３からなる。アプリケーションサーバ３０および死活監視サーバ３２は、既存のシステムに用いられているもので実現可能である。
コーディネータ３１は、アプリケーションサーバ３０からのトランザクション要求を、そのトランザクションに関わるデータを保有する複数のデータサーバ３３に配信する。
図４Ａは、コーディネータが調停するトランザクションの状態遷移を説明するための図である。
図４Ａを参照すると、トランザクションの状態は５つに分類され、それぞれ「begin」の状態Ｓ１１、「更新済」の状態Ｓ１２、「prepare実行完了」の状態Ｓ１３、「commit実行完了」の状態Ｓ１４、「rollback実行完了」の状態Ｓ１５とされている。
アプリケーションサーバからトランザクション開始要求を受信すると、コーディネータの状態は「begin」の状態Ｓ１１に遷移し、それをトランザクションの開始とみなす。トランザクションの開始後、アプリケーションサーバからデータ更新要求を受信すると、コーディネータの状態は「更新済」の状態Ｓ１２に遷移する。
「prepare実行完了」の状態Ｓ１３は、commitもしくはrollbackの準備ができたことを表す状態である。「prepare実行完了」の状態Ｓ１３と「commit実行完了」の状態Ｓ１４または「rollback実行完了」の状態Ｓ１５との間に発生した更新要求は無視する。
「commit実行完了」の状態Ｓ１４は、「begin」の状態Ｓ１１から「prepare実行完了」の状態Ｓ１３までのデータ更新を全てデータベースに反映した状態である。「rollback実行完了」の状態Ｓ１５は、「begin」の状態Ｓ１１から「prepare実行完了」の状態Ｓ１３までのデータ更新を全て中止した状態である。
したがって、「begin」の状態Ｓ１１がトランザクションの開始状態であり、「commit実行完了」の状態Ｓ１４と「rollback実行完了」の状態Ｓ１５は、トランザクションの最終状態である。また、トランザクションの途中状態には、「更新済」の状態Ｓ１２と「prepare実行完了」の状態Ｓ１３がある。
図４Ａにおいて、状態遷移の入力は、「入力元サーバ：入力データ」の組で表記する。
図４Ｂは、データサーバが調停するトランザクションの状態遷移を説明するための図である。
図４Ｂを参照すると、トランザクションの状態は４つに分類され、それぞれ「更新済」の状態Ｓ２１、「prepare実行完了」の状態Ｓ２２、「commit実行完了」の状態Ｓ２３、「rollback実行完了」の状態Ｓ２４とされている。
コーディネータからデータ更新要求を受信すると、データサーバの状態は「更新済」の状態Ｓ２１に遷移する。
「prepare実行完了」の状態Ｓ２２は、commitもしくはrollbackの準備ができたことを表す状態である。「prepare実行完了」の状態Ｓ２２と「commit実行完了」の状態Ｓ２３または「rollback実行完了」の状態Ｓ２４との間に発生した更新要求は無視する。
「commit実行完了」の状態Ｓ２３は、「更新済」の状態Ｓ２１から「prepare実行完了」の状態Ｓ２２までのデータ更新を全てデータベースに反映した状態である。「rollback実行完了」の状態Ｓ２４は、「更新済」の状態Ｓ２１から「prepare実行完了」の状態Ｓ２２までのデータ更新を全て中止した状態である。これら「commit実行完了」の状態Ｓ２２と「rollback実行完了」の状態Ｓ２３は、データサーバにおけるトランザクションの最終状態である。
図４Ａおよび図４Ｂに示したトランザクション状態の遷移の契機は、コーディネータがトランザクション要求を受信し、その要求がデータサーバで実行され、正常に実行が完了し、その旨を通知できた場合のみである。
詳細に説明すると、トランザクション要求の発信元サーバがアプリケーションサーバである場合、発信先はコーディネータである。トランザクション要求の発信元サーバがコーディネータである場合、発信先はデータサーバである。一方、トランザクション要求の完了応答の発信元サーバがデータサーバである場合、発信先はコーディネータである。
入力トランザクション要求は、begin要求、データ更新要求、prepare要求、commit要求、rollback要求の５種類に分類される。
図４Ａおよび図４Ｂにおいて、遷移先のない入力については状態遷移が発生せず、異常状態とする。ここでは、異常状態については説明しない。ただし、異常状態以外について、「begin」の状態からprepare要求、rollback要求、commit要求を受信することもあるが、それら要求は無視して処理せず、状態についても、初期化される。
次に、図３に示したアプリケーションサーバ３０、コーディネータ３１、死活監視サーバ３２およびデータサーバ３３のそれぞれの構成や役割について説明する。
図５に、コーディネータ３１、死活監視サーバ３２およびデータサーバ３３のそれぞれの機能モジュールを示す。
アプリケーションサーバ３０は、アプリケーションプログラムから構成され、コーディネータ３１へトランザクション要求（begin、データ更新、prepare、commit、rollback）を送信する。なお、アプリケーションサーバ３０は、本発明の特徴部を構成するものではないので、ここでは、その詳細な説明を省略する。
コーディネータ３１は、ＣＰＵとメモリとディスクを保持する計算機より構成されるものであって、アプリケーションサーバ３０から受信したトランザクション要求を解析し、操作対象のデータを保持する複数のデータサーバにデータ操作要求を送信する。
具体的には、図５に示すように、コーディネータ３１は、トランザクション受信部３１０、トランザクション解析部３１１、データ操作送受信部３１２およびリカバリ部３１３を有する。
コーディネータ３１では、アプリケーションサーバ３０からのトランザクション要求は、トランザクション受信部３１０で受信される。トランザクション受信部３１０にて、アプリケーションサーバからトランザクションを受け付けると、トランザクション解析部３１１が、該当するトランザクションを解析する。
図６に、トランザクション解析部３１１にて行われるトランザクション解析処理の一手順を示す。
まず、アプリケーションサーバから取得したトランザクションの要求として受信したトランザクション要求を、トランザクションリストの「受信トランザクション要求」に退避する（ステップＳ３０）。
次に、トランザクション要求がbeginであるか否かを判定する（ステップＳ３１）。トランザクション要求がbeginである場合は、トランザクションリストに、新規トランザクションを登録して（ステップＳ３２）、処理を終了する。この場合、コーディネータ３１は、begin要求をデータサーバ３３に通知しない。これにより、データサーバ３３とのネットワーク通信が発生しないため、オーバヘッドを削減できる。
ここで、トランザクションリストとは、コーディネータが調停している仕掛中トランザクションをリストとして保持するものである。図７に示すように、トランザクションリスト３４は、トランザクション要求の内容および識別子（ID）からなる。
トランザクションリストへの新規トランザクションの登録は、コーディネータ３１がアプリケーションサーバ３０からのトランザクション開始のbegin要求を受信した際に、トランザクションを一意に識別するためのID（以下、TxID）を生成し、新規トランザクションとしてトランザクションリスト３４に登録する。
トランザクションとして、begin要求を受信したとき、そのトランザクションのIDと、それに関するワークスペースは存在しない。したがって、トランザクションを生成した場合は、ワークスペース３６も同時に生成される。なお、初回の生成時には、ワークスペース内に受信したトランザクション要求を記憶する。また、更新時やcommit/rollbackの要求を受信した際も、ワークスペース内に受信したトランザクション要求を更新する。ワークスペース３６には、トランザクションが受信したトランザクション要求と、更新操作に関連するデータサーバおよびトランザクション状態のリストを示す更新サーバリスト３５とが、更新が発生するごとに追加される。
受信トランザクション要求の利用目的は、主にアプリケーションサーバ３０からcommit/rollback要求を受信した際に、データサーバ３３に送信すべき要求を記憶することである。なぜなら、２相コミットの形態では、データサーバが管理するトランザクションには、prepare実行完了状態がある。このため、受信トランザクション要求と更新サーバリスト内のデータサーバが管理するトランザクション状態が異なる場合がある。
例えば、図７に示した例では、TxID=１の受信トランザクション要求はrollbackであり、更新サーバリスト３５に記載のデータサーバＢ、データサーバＣのトランザクション状態はprepareである（データサーバのトランザクション状態は、コーディネータにprepare実行完了応答が通知されてから更新される）。
再び、図６を参照する。ステップＳ３１で、トランザクション要求がbeginでないと判定された場合は、続いて、トランザクション要求がデータ更新であるか否かの判定を行う（ステップＳ３３）。トランザクション要求がデータ更新である場合は、そのトランザクション要求が登録されていないかを判定する（ステップＳ３４）。
ステップＳ３４で、トランザクション要求が登録されていないと判定された場合は、TxIDで示されるトランザクションにおいて更新されたデータを保有するデータサーバを更新サーバリストに登録する（ステップＳ３５）。なお、データサーバが更新サーバリストにすでに登録されている場合は、そのデータサーバの追加登録は行わない。
ここで、トランザクションのデータ構造について説明する。トランザクションは、１つ以上のステートメント（SQL文などの命令文）から構成され、ステートメントには、操作対象データを識別できる識別情報が含まれている。トランザクション解析部１１１は、SQL文から操作対象のデータを識別する手段として、SQL文の構文解析・意味解析などの既存技術を用いて、データ更新要求受信時に、どのkeyが操作対象なのかを識別することができ、データサーバ対応表を用いて、そのkeyを含むデータIDと、そのkeyを保有するデータサーバを決定することができる。
データサーバ対応表は、図８に示すように、データＩＤ、キーレンジおよびデータサーバＩＤの３つの項目からなる。データサーバ対応表は、トランザクション要求が来るたびに、更新データを保有するデータサーバを決定するために利用される。
データサーバを決定すると、データサーバリストにあるデータサーバごとに、トランザクションにおけるデータ更新後の値を（データID、key、value）の形式で、トランザクションごとにリスト化する（ステップＳ３６）。
図９に、データサーバごとに管理されるトランザクションごとの更新対象データリストの一例を示す。更新対象データリスト３７は、データサーバリスト３６にあるデータサーバごとに生成される。
ここで、トランザクションが扱うデータ型はリレーショナル・データモデルでも適用可能であるが、簡単のため、key-valueストアモデルとする。データIDは、テーブルを構成するレコードの集合を表す一意の識別子である。レコード内の１レコードを表すためにkeyというテーブル内で一意の識別子を利用し、keyに紐づけられたvalueに対して操作を行う。
ステップＳ３３で、トランザクション要求がデータ更新でないと判定された場合は、続いて、トランザクション要求がcommitまたはrollbackであるか否かを判定する（ステップＳ３７）。
ステップＳ３７で、トランザクション要求がcommitまたはrollbackであると判定された場合は、更新サーバリストに記載のデータサーバに対してprepareを送信し、commit/rollbackの準備ができた段階で、commit/rollbackを送信する必要がある。したがって、ステップＳ３８で、トランザクション要求をprepareとする。
トランザクション解析部３１１によって、関連するデータサーバへのデータ操作要求を配信する準備が完了した後、データ操作要求送受信部３１２が、データサーバリスト内の各データサーバに対して、リスト化されているトランザクションごとの更新対象データリストを送信する。
アプリケーションサーバ３０からのトランザクション要求が、commit/rollbackである場合は、２相コミットのため、コーディネータ３１は、ワークスペース内の更新サーバリストに記載されたデータサーバにprepareを送信する。その後、prepareに対する実行完了応答がデータサーバからコーディネータ３１に返却されると、コーディネータ３１は、データサーバごとのトランザクション状態をprepareに変更する。そして、更新サーバリスト内の全データサーバの実行完了応答が返ってきた時点で、コーディネータ３１は、受信トランザクション要求（commit/rollback）を、更新サーバリスト内の全データサーバに送信する。
本実施形態によれば、BASE特性を実現しているため、１つのデータサーバからcommit/rollback実行完了応答が返却された時点で、コーディネータ３１は、アプリケーションサーバ３０に実行完了応答を返却する。この手段によれば、アプリケーションサーバ３０へのレスポンスタイムを短縮できる。
また、コーディネータ３１は、図７〜図９に示した情報を全てメモリ上で管理する。また、リカバリログについては、コーディネータ３１側では記録せず、各データサーバ３３側で、自身が管理するデータの更新に対するリカバリログをとる。この手段によれば、コーディネータ３１のディスクアクセスを回避できる。
再び、図５を参照すると、データサーバ３３は、ＣＰＵとメモリとディスクを保持する計算機よりなり、コーディネータ３１からのデータ操作要求を、自身が保有するデータに反映させる。具体的には、データサーバ３３は、データ操作要求受信部３３０、データ操作要求実行部３３１、ログ管理部３３２、リカバリ部３３３およびデータベース３３４を有する。
データサーバ３３では、データ操作要求受信部３３０が、コーディネータ３１からデータ操作要求を受信し、その後、データ操作要求実行部３３１が、解釈された要求を実行する。解釈された要求がデータ更新要求である場合、データ操作要求実行部３３１は、対象データにロックをかけ、更新後にロックを解除する。これにより、トランザクション間の排他制御を実現する。その後、ログ管理部３３３が、データ操作要求について、メモリ上にリカバリログを作成する。リカバリログに書き込む内容については、後述する。
図１０を参照して、データサーバ３３の管理情報について説明する。図１０に示す例は、データサーバＡの管理情報である。
図１０を参照すると、データサーバ３３は、メモリ３３ａおよびディスク３３ｂを有する。ディスク３３ｂは、図５に示したデータベース３３４を構成するものである。
コーディネータ３１からのデータ操作要求を受信すると、データ操作要求実行部３３１がデータ操作要求を実行した後、ログ管理部３３３が、メモリ３３ａ上に、リカバリログ３３３ａを追加書き込みする（リカバリログは時系列で書き込まれる）。１回の更新操作に対して、（コーディネータID、データID、更新対象のキー、更新後の値）の組の情報が書き込まれる。
コーディネータ３１からprepare 要求を受信するまでは、データサーバ３３において、メモリ３３ａ上でリカバリログ３３３ａを管理する。コーディネータ３１から、あるトランザクションのprepare要求を受信すると、データサーバ３３において、ログ管理部３３３は、２つのファイル３３４ａ、３３４ｂを生成する。
ファイル３３４ａは、図１０に示すprepare対象トランザクションの更新後情報を含むファイルである。更新後情報は、対象のトランザクションのリカバリログだけをメモリ３３ａ上から抽出したものである。ファイル３３４ａは、ディスク３３ｂに格納される。
ファイル３３４ｂは、コーディネータ３１からのprepare要求の引数として受信した、prepare要求対象のトランザクションに対するワークスペース情報であり、コーディネータ３１が保持しているワークスペース情報を、更新サーバリスト内の自身のトランザクション状態のみをprepare実行完了状態に変更した上で、ファイルに書き出すことで生成される。
これらファイル３３４ａ、３３４ｂは、ディスク３３ｂ上で永続化される。その際、更新サーバリスト内の自身が管理するトランザクション状態のみprepare実行完了状態となる。
その後、データサーバ３３は、コーディネータ３１にprepare実行完了応答を行う。コーディネータ３１は、prepare実行完了応答を該当する全データサーバから受信した後に、該当する全データサーバに一斉にcommit/rollback要求を配信する。commit/rollback要求を受信したデータサーバは、更新後情報を実際に、データベース３３４に反映させ、ワークスペース内の自身が管理するトランザクション状態をcommitに更新する。
再び、図５を参照すると、死活監視サーバ３２は、サーバ死活監視部３２０と代替サーバ通知部３２１から構成される。死活監視部３２０は、コーディネータ３１が正常に動作しているかダウンしているかを監視する。代替サーバ通知部３２１は、ダウンしたコーディネータの替わりとなる待機中のコーディネータに、コーディネータがダウンしたことを通知する。この通知において、ダウンしたコーディネータIDが一緒に通知される。通常、代替コーディネータと死活監視サーバは異なるハードウェアで実現される。
以下に、死活監視サーバ３２の管理情報について説明する。
死活監視サーバ３２は、どのコーディネータが起動、もしくはダウンしているかを（コーディネータID、状態：起動/ダウン）の形式で示される情報で管理する。常に複数の代替コーディネータが待機しており、サーバ死活監視部３２０が、コーディネータのダウンを検知すると、代替コーディネータにダウンしたコーディネータIDを通知する。通知を受けた代替コーディネータは、以降のトランザクションを調停する。
本実施形態によるコーディネータ異常時のトランザクション回復保証の範囲は、データサーバでprepare要求の実行完了後、commit要求の実行完了となるまでである。
次に、コーディネータ３１に障害が発生した場合の処理について説明する。
コーディネータ３１に障害が発生した場合、代替コーディネータ、データサーバ、死活監視サーバの３つの間で情報をやり取りすることで、コーディネータ３１が仕掛中のトランザクション処理を完了させる。
図１１を参照して、コーディネータのトランザクションのリカバリの流れについて説明する。
コーディネータ３１に障害が発生すると、死活監視サーバ３２において、サーバ死活監視部３２０がコーディネータ３１の障害発生を検知する。そして、代替サーバ通知部３２１が、待機中の代替コーディネータ３１−１を選択し、その代替コーディネータ３１−１に対して、障害が発生したコーディネータ３１のIDを引数として障害通知を行う。
代替コーディネータ３１−１は、リカバリ部３１３およびデータ操作送受信部３１２を有する。リカバリ部３１３は、障害通知受信部３１３ａ、情報収集部３１３ｂおよびトランザクション状態決定部３１３ｃを有する。
代替コーディネータ３１−１において、障害通知受信部３１３ａが、死活監視サーバ３２からの障害通知を受信すると、情報収集部３１３ｂが、全データサーバ３３に対して、障害発生コーディネータIDを引数として渡し、その引数で指定されたコーディネータが障害前に調停していたトランザクションに対するワークスペースを返信するよう要求する。
各データサーバ３３では、リカバリ部３３３のトランザクション状態通知部３３３ａが代替コーディネータ３１−１からの返信要求を受信する。トランザクション状態通知部３３３ａは、その返信要求に含まれているコーディネータIDに基づいて、図１０に示したディスク３３ｂ上で永続化しているワークスペースから、障害の発生したコーディネータが調停していた、仕掛中のトランザクションに対するワークスペースを抽出し、その抽出したワークスペースを代替コーディネータ３１−１に返信する。
代替コーディネータ３１−１では、情報収集部３１３ｂが各データサーバ３３から収集したワークスペースに基づいて、トランザクション状態決定部３１３ｃが、各データサーバ３３が管理するトランザクション状態を確認し、障害の発生したコーディネータ３１が調停していたトランザクションの最終状態を決定する。
収集した各データサーバ３３のワークスペースに記載されたトランザクション状態から、更新サーバリストを復元する場合、各データサーバ３３の保持するトランザクション状態が異なる場合がある。なぜなら、コーディネータ３１がcommit/rollback要求を送信する際に、障害が発生する場合があるためである。通常は、データサーバ３３は、prepare要求を受信した後は、コーディネータ３１から受信したワークスペースをディスク３３ｂに書き込んで、コーディネータ３１にprepare実行完了応答を返信する。したがって、トランザクション状態決定部３１３ｃにてトランザクションの最終状態を決定する。
図１２は、代替コーディネータ３１−１が、各データサーバ３３からワークスペースを収集し、その収集したワークスペースからトランザクション状態を復元する手順を説明するための模式図である。
図１２に示すように、各データサーバ３３から収集したワークスペース４０は、データサーバ中心の管理構造になっている。このため、データサーバ中心の管理構造のワークスペース４０を、トランザクション中心の管理構造のワークスペース４１に変更する必要がある。
図１３に、データサーバ中心の管理構造のワークスペースを、トランザクション中心の管理構造のワークスペースに変更する手順を示す。以下、図１２および図１３を参照して、データサーバＡ、Ｂ、Ｃから収集したワークスペースから、トランザクションリストを復元する過程について説明する。
代替コーディネータ３１−１が死活監視サーバ３２からの通知を受信した場合は、トランザクションリストは空である。トランザクション状態決定部３１３ｃは、まず、収集したワークスペースのうち１つを取り出し（ステップＳ４０）、その取り出したワークスペースがトランザクションに登録されていないトランザクションＸかを判定する（ステップＳ４１）。ステップＳ４１において、最初はトランザクションリストは空なので、トランザクションＸのための新規ワークスペースは必ず作成される。したがって、トランザクションリストに登録されないまま、ステップＳ４１で「Ｎｏ」という判定になることはない。つまり、ステップＳ４１で「Ｎｏ」に遷移する場合は、トランザクションリストに必ず、トランザクションＸが登録されている。
ステップＳ４１で、取り出したワークスペースがトランザクションに登録されていないトランザクションＸであると判定した場合は、トランザクション状態決定部３１３ｃは、トランザクションＸに対する新規ワークスペースを作成する（ステップＳ４２）。そして、トランザクション状態決定部３１３ｃは、トランザクションＸをトランザクションリストに追加し、受信トランザクション要求として、取り出したワークスペース内の要求をコピーする（ステップＳ４３）。
ステップＳ４１で、取り出したワークスペースがトランザクションに登録されていないトランザクションＸではないと判定した場合、または、ステップＳ４３の処理を実行した場合は、トランザクション状態決定部３１３ｃは、更新サーバリスト内のデータサーバ自身のトランザクション状態が「更新済」であるか否かを判定する（ステップＳ４４）。更新済みと判定したものは、ワークスペース内の形成には必要ないため、無視する。
ステップＳ４４で、「更新済」でないと判定した場合は、トランザクション状態決定部３１３ｃは、更新サーバリストから、データサーバ自身のトランザクション状態を、トランザクションＸの新規ワークスペースの更新サーバリストに追加する（ステップＳ４５）。
ステップＳ４５を実行後、トランザクション状態決定部３１３ｃは、収集したワークスペースを全て取り出したか否かを判定する（ステップＳ４６）。
ステップＳ４４で、「更新済」でないと判定した場合、または、ステップＳ４６で、ワークスペースを全て取り出したと判定した場合は、ステップＳ４０からの処理を繰りかえる。
例えば、図１２に示した収集ワークスペース４０からデータサーバＡから収集したワークスペースを取り出した場合、その取り出したワークスペースでは、TxID=1とされ、受信トランザクション要求がcommitとされているので、トランザクションリスト作成時にその情報を反映する。その後、更新サーバリスト内に記載されたデータサーバのうち、受信したワークスペースを保有するデータサーバのみのトランザクション状態を、トランザクションリスト内の更新サーバリストに、データサーバＩＤとともに追加する。データサーバＡから収集したワークスペースの場合、データサーバＡに関するトランザクション状態がprepareなので、TxID=1におけるワークスペース内の更新サーバリストに「データサーバＡ：prepare」を追加する。
上記の処理を、データサーバＡから受信したワークスペースだけでなく、収集ワークスペース４０の全てに対して行い、トランザクションリストとそれに付随するワークスペースを、コーディネータの障害発生前の状態に復元する。
以上のようにして、データサーバ中心の管理構造のワークスペースがトランザクション中心の管理構造のワークスペースに変更される。トランザクション状態決定部３１３ｃは、その管理構造が変更されたワークスペースに基づいて、各データサーバ３３が管理するトランザクション状態を確認し、障害が発生したコーディネータ３１が調停していたトランザクションの最終状態を決定する。
図１４に、トランザクション状態の決定手順を示す。この決定手順において、基本的な決定方針として、あるトランザクションにかかる、更新サーバリスト内のあるデータサーバで管理しているトランザクション状態の少なくとも1つがcommitもしくはrollbackであれば、最終状態は、その状態と同じ（commitもしくはrollback）となる。
つまり、トランザクションの最終状態を決定する場合の優先順位は、
commit/rollback ＞ prepare
となる。
図１４を参照すると、トランザクション状態決定部３１３ｃは、まず、トランザクションリストからトランザクションを１つ取り出し（ステップＳ５０）、そのトランザクションにかかるワークスペース内の更新サーバリストからトランザクション状態を１つ取り出す（ステップＳ５１）。
次に、トランザクション状態決定部３１３ｃは、取り出したトランザクション状態がcommitまたはrollbackであるか否かを判定する（ステップＳ５２）。
ステップＳ５２で、トランザクション状態がcommitまたはrollbackであると判定した場合は、トランザクション状態決定部３１３ｃは、トランザクションの最終状態をcommitまたはrollbackに決定する（ステップＳ５３）。
ステップＳ５２で、トランザクション状態がcommitおよびrollbackのいずれでもないと判定した場合は、トランザクション状態決定部３１３ｃは、更新サーバリスト内のトランザクション状態を全て取り出したか否かを判定する（ステップＳ５４）。
ステップＳ５４で、トランザクション状態を全て取り出したと判定した場合は、トランザクション状態決定部３１３ｃは、トランザクションの最終状態を決定する（ステップＳ５５）。ここで、トランザクションの最終状態は、commitかrollbackのいずれかに決定される。具体的には、prepare状態に対して、事前のシステム設定がcommitであればprepare状態をcommitにすることで最終状態を決定し、事前のシステム設定がrollbackであればprepare状態をrollbackにすることで最終状態を決定する。
トランザクションの最終状態を決定した後で、このトランザクションの最終状態にするためのトランザクション要求をこのトランザクションに関係するデータサーバに送信し、受信したデータサーバはそのトランザクション要求に対する処理をすることで、システム内のデータサーバの整合性をとることができる。
ステップＳ５４で、未だ取り出されていないトランザクション状態があると判定した場合は、ステップＳ５１からの処理が再び実行される。
ステップＳ５３またはステップＳ５５の処理が実行された後、トランザクション状態決定部３１３ｃは、更新サーバリスト内のトランザクション状態がprepareであるデータサーバに、決定されたトランザクションの最終状態にするための要求をデータサーバリストに追加する（ステップＳ５６）。
次に、トランザクション状態決定部３１３ｃは、トランザクションリスト内のトランザクションを全て取り出したか否かを判定する（ステップＳ５７）。トランザクションを全て取り出したと判定した場合は、トランザクション状態決定部３１３ｃによる決定処理を終了する。未だ取り出されていないトランザクションがあると判定した場合は、ステップＳ５０からの処理が再び実行される。
以上のようにして調停すべきトランザクションの最終状態を決定すると、その後は、代替コーディネータ３１−１は、通常のトランザクション処理と同様に、prepare実行完了状態であるデータサーバのみに対してcommit/rollback要求を送信して、データサーバにトランザクション処理を実行させる。そして、代替コーディネータ３１−１は、データサーバからcommit/rollback実行完了応答を受信し、トランザクション処理を完了させる。
上記のトランザクションの最終状態を決定する手法によれば、コーディネータ３１の障害発生時に、全データサーバからワークスペースを収集することにより、収集時に複数のデータサーバに障害が発生した場合でも、どれか１つのデータサーバが正常であり、かつトランザクションが最終状態である（commit/rollback）場合、代替コーディネータ３１−１は、処理完了すべきトランザクションにどのデータサーバが関わっているかを特定でき、自身の最終状態を、他のデータサーバに反映させるトランザクション要求を配信することで、仕掛中トランザクション処理を完了できる。
次に、データサーバ３３に障害が発生した場合の動作について説明する。
データサーバ３３に障害が発生した場合、図５に示したリカバリ部３３３が、最終状態にないトランザクションの処理を完了させる。
図１５に、各データサーバのトランザクションのリカバリの流れを模式的に示す。データサーバＡ〜Ｃは、図５に示したデータサーバ３３と同じ構成である。データサーバＡ〜Ｃのリカバリ部３３３は、図１１に示したトランザクション状態通知部３３３ａに加えて情報収集部３３３ｂ、トランザクション状態決定部３３ｃおよびデータ操作送受信部３３ｄを有する。なお、図１５においては、便宜上、リカバリの流れを説明するために必要な部分のみが示されている。
図１５には、コーディネータ３１からcommit要求が発信され、そのcommit要求が、データサーバＣに到着する前に、データサーバＣに障害が発生した場合の、リカバリの流れが示されている。
コーディネータ３１は、BASE特性より、データサーバＣからのレスポンスを無視して、アプリケーションサーバ３０にcommit実行完了通知を返信する。したがって、その時点では、データサーバＣにおけるトランザクションはcommitされていないため、データと整合性がとれていない状態が発生する。
しかし、データサーバＣが復旧し、再起動すると、データサーバＣでは、リカバリ部３３３の情報収集部３３３ｂが、障害前に永続化していたワークスペースに存在するprepare実行完了状態のトランザクションを探し、ワークスペース内の更新サーバリスト内に記載されたデータサーバが管理するトランザクションIDを引数として、他のデータサーバＡ、Ｂに対してトランザクションの最終状態を問い合わる。
なお、再起動は一例であり、データサーバＣの代替のデータサーバに切り替えて、代替のデータサーバが、上記を実施してもよい。
データサーバＡ、Ｂでは、リカバリ部３３３のトランザクション状態通知部３３３ａが、データサーバＣからの問い合わせを受けて、該当するトランザクションIDに関して永続化していたワークスペースをデータサーバＣに返信する。このワークスペースは、前述したコーディネータの障害時のリカバリで説明したフォーマットと同じである。
コーディネータの障害時のリカバリでは、代替コーディネータが、コーディネータIDを引数として、関連する全データサーバから、ワークスペースを収集していた。これに対して、データサーバの障害時のリカバリでは、トランザクションIDを引数として、関連する全データサーバから、ワークスペースを収集するようになっており、この点が、コーディネータ障害時と異なる。
また、コーディネータ障害時のリカバリでは、更新後情報に記載のコーディネータIDと引数のトランザクションIDとの比較で一致した場合、該当のトランザクションのワークスペースを選択する。一方、データサーバ障害時のリカバリでは、更新後情報は利用せず、トランザクションIDとワークスペース内のトランザクションIDとの比較で一致した場合、該当のトランザクションのワークスペースを選択する。
データサーバＣでは、リカバリ部３３３のトランザクション状態決定部３３３ｃが、更新サーバリスト内のデータサーバから収集したトランザクション状態から、図１２に示した収集ワークスペース４１のようなトランザクションリストを形成する。その後、トランザクション状態決定部３３３ｃが、図１４に示した手順でトランザクションの最終状態を決定する。
なお、データサーバの場合、図１４において、ステップＳ５６は、「決定された最終状態のための要求をデータ操作要求受信部に送信」する処理となる。この処理では、データ操作送受信部３３３ｄが、トランザクション状態決定部３３３ｃで決定したトランザクションの最終状態にするための要求をデータ操作要求受信部３３０に送信する。
データ操作要求受信部３３０は、データ操作送受信部３３３ｄからの要求をデータ操作要求実行部３３１に供給する。データ操作要求実行部３３１は、データ操作送受信部３３３ｄからの要求に応じた処理を実行する。これにより、トランザクション状態決定部３３３ｃで決定したトランザクションの最終状態の情報がデータベース３３４に反映させる。
以上の処理により、データサーバＣの障害前に永続化していたトランザクションを処理することができ、最新のデータ状態にすることができ、整合性を保つことができる。
なお、上記のデータサーバの障害時のリカバリにおいては、データサーバＣが復旧するまで、データの整合性が保てないとしたが、データサーバ間でのディスク共有や、レプリケーションなどの手法を用いることで、データサーバの障害時でも、即時に復旧することができ、トランザクションを停止させることなく、処理することができる。
また、上記のデータサーバの障害時のリカバリによれば、データサーバに障害が発生した場合、BASE特性によって、アプリケーションサーバへのレスポンスを優先しながら、コーディネータを介すことなく、データサーバ間の通信のみで整合性を保つことができる。
以上説明した各実施形態は、本発明の一例であり、その構成および動作は、発明の趣旨を逸脱しない範囲で当業者が採用し得る変更を適用することができる。
例えば、図１０に示したデータサーバ３３において、リカバリログ３３３ａをディスク３３ｂに格納してもよく、また、ファイル３３４ａ、３３４ｂをメモリ３３ａに格納してもよい。
各実施形態において、データサーバおよびトランザクション管理サーバ（コーディネータ）のそれぞれは、プログラムに従って動作するコンピュータ装置よりなり、それぞれのサーバの機能は、コンピュータがプログラムを実行することにより提供することができる。プログラムは、コンピュータ装置内の記憶部に予め格納されてもよく、また、ＣＤ−ＲＯＭやＤＶＤなどに代表される記録媒体を介してコンピュータ装置に提供されてもよい。さらに、プログラムは、インターネットに代表されるネットワークを介してコンピュータ装置に提供されてもよい。
１０ トランザクション管理サーバ
１１1〜１１n データサーバ
１２ ネットワーク

Claims (16)

  1. それぞれがトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する複数のデータサーバと、
    前記複数のデータサーバに対するトランザクション要求を調停する第１のトランザクション管理サーバと、を有し、
    前記第１のトランザクション管理サーバは、自サーバにて障害が発生した場合に、その障害の復旧後に、自身が調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、前記複数のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う、分散トランザクション処理システム。
  2. それぞれがトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する複数のデータサーバと、
    前記複数のデータサーバに対するトランザクション要求を調停するトランザクション管理サーバと、を有し、
    前記複数のデータサーバのそれぞれは、自データサーバにて障害が発生した場合に、その障害の復旧後に、自データサーバで実行していた仕掛中のトランザクションに係わるトランザクション状態情報を他のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う、分散トランザクション処理システム。
  3. 前記複数のデータサーバのそれぞれは、自データサーバにて障害が発生した場合に、その障害の復旧後に、自データサーバで実行していた仕掛中のトランザクションに係わるトランザクション状態情報を他のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う、請求項１に記載の分散トランザクション処理システム。
  4. 前記複数のデータサーバに対するトランザクション要求を調停する第２のトランザクション管理サーバを、さらに有し、
    前記第１のトランザクション管理サーバは、前記第２のトランザクション管理サーバにて障害が発生した場合に、前記第２のトランザクション管理サーバが調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、前記複数のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う、請求項１または３に記載の分散トランザクション処理システム。
  5. 複数のデータサーバと第１のトランザクション管理サーバとを有するシステムにおいて行われる分散トランザクション処理方法であって、
    前記複数のデータサーバのそれぞれが、トランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理するステップと、
    前記第１のトランザクション管理サーバが、前記複数のデータサーバに対するトランザクション要求を調停するステップと、
    前記第１のトランザクション管理サーバが、自サーバにて障害が発生した場合に、その障害の復旧後に、自身が調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、前記複数のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行うステップと、を有する、分散トランザクション処理方法。
  6. 複数のデータサーバとトランザクション管理サーバとを有するシステムにおいて行われる分散トランザクション処理方法であって、
    前記複数のデータサーバのそれぞれが、トランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理するステップと、
    前記トランザクション管理サーバが、前記複数のデータサーバに対するトランザクション要求を調停するステップと、
    前記複数のデータサーバのそれぞれが、自データサーバにて障害が発生した場合に、その障害の復旧後に、自データサーバで実行していた仕掛中のトランザクションに係わるトランザクション状態情報を他のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行うステップと、を有する、分散トランザクション処理方法。
  7. 前記複数のデータサーバのそれぞれが、自データサーバにて障害が発生した場合に、その障害の復旧後に、自データサーバで実行していた仕掛中のトランザクションに係わるトランザクション状態情報を他のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行うステップを、さらに有する、請求項５に記載の分散トランザクション処理方法。
  8. 前記システムは、前記複数のデータサーバに対するトランザクション要求を調停する第２のトランザクション管理サーバを、さらに有しており、
    前記第１のトランザクション管理サーバが、前記第２のトランザクション管理サーバにて障害が発生した場合に、前記第２のトランザクション管理サーバが調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、前記複数のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行うステップを、さらに有する、請求項５または７に記載の分散トランザクション処理方法。
  9. それぞれがトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する複数のデータサーバと相互に通信可能なトランザクション管理サーバであって、
    自サーバにて障害が発生した場合に、その障害の復旧後に、自身が調停していた仕掛中のトランザクションに係わるトランザクション状態情報を前記複数のデータサーバから収集する情報収集部と、
    前記情報収集部で収集したトランザクション状態情報に基づいて、前記仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、前記仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行うトランザクション状態決定部と、を有する、トランザクション管理サーバ。
  10. それぞれがトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する複数のデータサーバと相互に通信可能なトランザクション管理サーバであって、
    前記複数のデータサーバに対するトランザクション要求を調停する別のトランザクション管理サーバにて障害が発生した場合に、該別のトランザクション管理サーバが調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、前記複数のデータサーバから収集する情報収集部と、
    前記情報収集部で収集したトランザクション状態情報に基づいて、前記仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、前記仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行うトランザクション状態決定部と、を有する、トランザクション管理サーバ。
  11. トランザクション管理サーバによって調停されたトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する他のデータサーバと相互に通信可能なデータサーバであって、
    前記トランザクション管理サーバによって調停されたトランザクション要求に基づく処理を実行する実行部と、
    自データサーバにて障害が発生した場合に、その障害の復旧後に、前記実行部で実行されていた仕掛中のトランザクションに係わるトランザクション状態情報を前記他のデータサーバから収集し、該収集した情報に基づいて該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行うトランザクション状態決定部と、を有する、データサーバ。
  12. それぞれがトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する複数のデータサーバと相互に通信可能なトランザクション管理サーバにおいて行われる分散トランザクション処理方法であって、
    自サーバにて障害が発生した場合に、その障害の復旧後に、自身が調停していた仕掛中のトランザクションに係わるトランザクション状態情報を前記複数のデータサーバから収集するステップと、
    前記収集したトランザクション状態情報に基づいて、前記仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、前記仕掛中のトランザクション前後におけるデータの整合性をとるステップと、を有する、分散トランザクション処理方法。
  13. それぞれがトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する複数のデータサーバと相互に通信可能なトランザクション管理サーバにおいて行われる分散トランザクション処理方法であって、
    前記複数のデータサーバに対するトランザクション要求を調停する別のトランザクション管理サーバにて障害が発生した場合に、該別のトランザクション管理サーバが調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、前記複数のデータサーバから収集するステップと、
    前記収集したトランザクション状態情報に基づいて、前記仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、前記複数のデータサーバのそれぞれについて、前記仕掛中のトランザクション前後におけるデータの整合性をとるステップと、を有する、分散トランザクション処理方法。
  14. トランザクション管理サーバによって調停されたトランザクション要求に応じた処理を実行し、該トランザクションの実行状態を表すトランザクション状態情報を管理する他のデータサーバと相互に通信可能なデータサーバにて行われる分散トランザクション処理方法であって、
    前記トランザクション管理サーバによって調停されたトランザクション要求に基づく処理を実行するステップと、
    自データサーバにて障害が発生した場合に、その障害の復旧後に、前記実行部で実行されていた仕掛中のトランザクションに係わるトランザクション状態情報を前記他のデータサーバから収集し、該収集した情報に基づいて該トランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるステップと、を有する、分散トランザクション処理方法。
  15. 請求項９または１０に記載のトランザクション管理サーバの機能をコンピュータに実行させることを特徴とするプログラム。
  16. 請求項１１に記載のデータサーバの機能をコンピュータに実行させることを特徴とするプログラム。
JP2010157817A 2010-07-12 2010-07-12 分散トランザクション処理システム、装置、方法およびプログラム Active JP5480046B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010157817A JP5480046B2 (ja) 2010-07-12 2010-07-12 分散トランザクション処理システム、装置、方法およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010157817A JP5480046B2 (ja) 2010-07-12 2010-07-12 分散トランザクション処理システム、装置、方法およびプログラム

Publications (2)

Publication Number Publication Date
JP2012022379A true JP2012022379A (ja) 2012-02-02
JP5480046B2 JP5480046B2 (ja) 2014-04-23

Family

ID=45776650

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010157817A Active JP5480046B2 (ja) 2010-07-12 2010-07-12 分散トランザクション処理システム、装置、方法およびプログラム

Country Status (1)

Country Link
JP (1) JP5480046B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016538631A (ja) * 2013-10-29 2016-12-08 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． トランザクション処理方法および装置
CN106997305A (zh) * 2013-10-29 2017-08-01 华为技术有限公司 一种事务处理方法与装置
JP2022550536A (ja) * 2019-10-11 2022-12-02 中興通訊股▲ふん▼有限公司 トランザクション管理方法、システム、ネットワーク機器及び読み取り可能な記憶媒体

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0581111A (ja) * 1991-09-25 1993-04-02 Toshiba Corp データリカバリ方式
JP2004145827A (ja) * 2002-10-28 2004-05-20 Nikon Corp 拠点データベース装置、データベース連携システム、データベースプログラム、データ同期方法、およびデータ復旧方法
WO2004055674A1 (ja) * 2002-12-18 2004-07-01 Fujitsu Limited 分散トランザクション処理装置、分散トランザクション処理プログラム、分散トランザクション処理方法および分散トランザクション処理システム
WO2006057061A1 (ja) * 2004-11-29 2006-06-01 Fujitsu Limited 分散トランザクション処理方法、装置、及びプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0581111A (ja) * 1991-09-25 1993-04-02 Toshiba Corp データリカバリ方式
JP2004145827A (ja) * 2002-10-28 2004-05-20 Nikon Corp 拠点データベース装置、データベース連携システム、データベースプログラム、データ同期方法、およびデータ復旧方法
WO2004055674A1 (ja) * 2002-12-18 2004-07-01 Fujitsu Limited 分散トランザクション処理装置、分散トランザクション処理プログラム、分散トランザクション処理方法および分散トランザクション処理システム
WO2006057061A1 (ja) * 2004-11-29 2006-06-01 Fujitsu Limited 分散トランザクション処理方法、装置、及びプログラム

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016538631A (ja) * 2013-10-29 2016-12-08 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． トランザクション処理方法および装置
CN106997305A (zh) * 2013-10-29 2017-08-01 华为技术有限公司 一种事务处理方法与装置
JP2018049635A (ja) * 2013-10-29 2018-03-29 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． トランザクション処理方法および装置
US10055445B2 (en) 2013-10-29 2018-08-21 Huawei Technologies Co., Ltd. Transaction processing method and apparatus
CN106997305B (zh) * 2013-10-29 2020-09-29 华为技术有限公司 一种事务处理方法与装置
JP2022550536A (ja) * 2019-10-11 2022-12-02 中興通訊股▲ふん▼有限公司 トランザクション管理方法、システム、ネットワーク機器及び読み取り可能な記憶媒体

Also Published As

Publication number Publication date
JP5480046B2 (ja) 2014-04-23

Similar Documents

Publication Publication Date Title
EP3694148B1 (en) Configuration modification method for storage cluster, storage cluster and computer system
US11899684B2 (en) System and method for maintaining a master replica for reads and writes in a data store
US11388043B2 (en) System and method for data replication using a single master failover protocol
US10664495B2 (en) System and method for supporting data grid snapshot and federation
US7743036B2 (en) High performance support for XA protocols in a clustered shared database
US20180181470A1 (en) System and method for adjusting membership of a data replication group
US10248704B2 (en) System and method for log conflict detection and resolution in a data store
JP4637842B2 (ja) クラスタ化されたコンピューティングシステムにおける高速なアプリケーション通知
US7653668B1 (en) Fault tolerant multi-stage data replication with relaxed coherency guarantees
US20150120658A1 (en) System and method for splitting a replicated data partition
US20070061379A1 (en) Method and apparatus for sequencing transactions globally in a distributed database cluster
US20090049054A1 (en) Method and apparatus for sequencing transactions globally in distributed database cluster
US20120278429A1 (en) Cluster system, synchronization controlling method, server, and synchronization controlling program
US20180314749A1 (en) System and method for partition-scoped snapshot creation in a distributed data computing environment
US20230110826A1 (en) Log execution method and apparatus, computer device and storage medium
CN110830582B (zh) 一种基于服务器集群选主方法和装置
JP5480046B2 (ja) 分散トランザクション処理システム、装置、方法およびプログラム
WO2023103340A1 (zh) 一种区块数据提交的方法及装置
CA2619778C (en) Method and apparatus for sequencing transactions globally in a distributed database cluster with collision monitoring
Pankowski Consistency and availability of Data in replicated NoSQL databases
JP2024037585A (ja) トランザクション管理方法及びトランザクション管理装置
JP2000112801A (ja) データベースバックアップシステム及びバックアップ方法
Zhang et al. ZooKeeper+: The Optimization of Election Algorithm in Complex Network Circumstance
Chen et al. RAFT based Key-Value Store with Transaction Support

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120523

RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7426

Effective date: 20130304

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130815

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130820

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131007

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: 20140210

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140213

R150 Certificate of patent or registration of utility model

Ref document number: 5480046

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150