JPWO2013046883A1 - トランザクション処理システム、方法及びプログラム - Google Patents

Abstract

分散ＫＶＳシステムにおいて、他のグローバル・トランザクションがロック中のマップ・エントリを、ローカル・トランザクションが照会・更新する際、そのローカル・トランザクションをグローバル・トランザクションに昇格させるため、クライアント・コンピュータにおいて、トランザクションＩＤを確定してグローバル・トランザクションを開始するステップと、複数のサーバのうちローカル・トランザクションを処理しているサーバで、照会用ローカル・トランザクションを開始するステップと、前記ローカル・トランザクションで照会中の全ての値を前記照会用ローカル・トランザクションで照会するステップと、前記ローカル・トランザクションで更新中の全ての値を、前記データ・テーブルにおいて、更新前の値と更新中の値と、前記トランザクションＩＤを値とするロック値の組み合わせに更新するステップと、前記ローカル・トランザクションをコミットするステップとを実行する。

Description

この発明は、分散処理システム、特に分散データベース・システム上でのトランザクションの処理に関し、より詳しくは、キー・バリュー・ストア(Key Value Store、以下ＫＶＳと称する）方式におけるトランザクションの処理に関するものである。

分散データベース・システムは周知であり、例えば、特開２００７−１８８５１８号公報は、オーナーシップグループを用いる分散データベース・システムに関し、データ項目のオーナーシップを示すデータを変更するステップを、不可分(atomic、アトミック)の動作とすることを開示する。

分散データベース・システムは一般に、リレーショナル・データベースを実装し、問い合わせにＳＱＬのような構文を用いる。

最近になって、キー(key)とバリュー(value)の組を書き込み、キーを指定することでバリューを読み出すことができる、キー・バリュー・ストア（ＫＶＳ）と呼ばれるデータベース管理ソフトウェアが使われるようになってきた。ＫＶＳの特徴は、問い合わせがシンプルであるため検索が高速であり、使用するサーバの台数が増えるほど性能を高めることができるというケーラビリティに優れる。そこで、複数台のサーバにデータを分散させることができる分散ＫＶＳも実装されている。

さて、一般に分散データベース・システムでは、2フェーズ・コミットを利用した分散トランザクションが処理される。各リソース・マネージャとトランザクション・モニターがトランザクションの状態を管理し、複数の分散されたリソースに跨ったトランザクションが実現される。しかしながら、ＫＶＳでこのような機構を導入する場合、ＫＶＳ本来が持っているシンプルな属性が失われるため、管理の利便性、スケーラビリティが損なわれることになる。よって、特表２００９−５２５５３６号公報に開示されているように、分散ロック・マネジャを使用して、グローバル・トランザクションを実現する技法を分散ＫＶＳに適用することは好ましくない。そのため、一般的な分散ＫＶＳでは、各サーバ内でのトランザクション（ローカル・トランザクション）のみをクライアントが要求可能であり、複数のサーバが管理するデータに関するトランザクション処理に関しては、ローカル・トランザクションを組み合わせて分散トランザクション（グローバル・トランザクション）を実現することが求められる。

しかし、素朴に実装されたトランザクション分散ＫＶＳでは、グローバル・トランザクションを実現することができなかった。というのは、１台のクライアント・コンピュータが２台のサーバに対して2つのローカル・トランザクションを要求し、1つのグローバル・トランザクションを行っているとき、コミット処理において、第１のサーバのローカル・トランザクションがコミットを終了した後、クライアント・コンピュータに障害が発生すると、第２のサーバのローカル・トランザクションがコミットしてよいのかどうか判断できなくなるためである。

そこで、「オープンソース徹底活用 Slim3 on Google App Engine for Java」ひがやすお・小川信一著、秀和システム、p.241-251には、Google App Engineでグローバル・トランザクションを実現する方法が開示されている。この方法では、ＫＶＳ上の特別のマップとして管理用マップを用意し、実際にデータを格納するマップ（データ・マップ）の値に、コミット済みの値、更新中の値、更新中のトランザクションIDを含ませ、管理用のマップにトランザクションの状態を管理させることで、2フェーズ・コミットと同機能を、ローカル・トランザクションのみをサポートする分散ＫＶＳ上で実現する。データ操作に対する排他制御は、データ・マップの値に含まれる更新中のトランザクションIDを利用して行われ、ＫＶＳが提供するローカル・トランザクション用の排他制御機構（ローカル排他制御機構）は利用しない。

このように従来知られている技術で、分散ＫＶＳ上のグローバル・トランザクションを実現しようとすると、ローカル・トランザクションの排他制御機構と、グローバル・トランザクションの排他制御機構が連動していないため、グローバル・トランザクションとローカル・トランザクションを混在させることができなかった。例えば、第１のクライアント・コンピュータが２台のサーバが管理する値に対して更新を行っているとき、第１のクライアント・コンピュータはグローバル・トランザクションにより、第１のサーバ上の値と第２のサーバ上の値をアトミックに更新可能であるが、第１のクライアント・コンピュータは第１のサーバ上で更新中のデータのロックをローカル排他制御機構より獲得していないため、第２のクライアント・コンピュータがローカル・トランザクションにより、第１のサーバ上の値を更新できてしまうからである。

よって、従来知られている技術ではローカル・トランザクションで間に合うような処理でも、グローバル・トランザクションにより実行する必要があり、グローバル・トランザクションはローカル・トランザクションよりもオーバーヘッドが大きいので、処理速度が低下するという問題があった。

特開２００７−１８８５１８号公報 特表２００９−５２５５３６号公報

「オープンソース徹底活用 Slim3 on Google App Engine for Java」ひがやすお・小川信一著、秀和システム、p.241-251

この発明の目的は、ローカル・トランザクションの排他制御機構と、グローバル・トランザクションの排他制御機構を連動させ、ローカル・トランザクションのみをサポートする分散ＫＶＳシステムにおいて、複数のサーバ上のマップ・エントリを更新・照会する分散トランザクション（グローバル・トランザクション）を実現しつつ、１台のサーバ上のマップ・エントリを更新・照会するローカル・トランザクションを高速に実現することにある。

本発明は、ローカル・トランザクションとしてローカル排他制御機構により許可されたマップ・エントリの照会・更新処理の際に、照会・更新するマップ・エントリが他グローバル・トランザクションとして更新中か否かを確認し、更新中の場合は、処理中のローカル・トランザクションをグローバル・トランザクションに昇格させ、以降の処理をグローバル・トランザクション上の排他制御（グローバル排他制御機構）を利用する処理に切り替えることによって、ローカル・トランザクションとグローバル・トランザクション間の排他制御を実現することにより、上記課題を解決する。

すなわち、本発明のシステムは、ローカル・トランザクションの処理中にローカル排他制御機構より獲得した共有ロックを別ローカル・トランザクションで再取得し、獲得したマップ・エントリの排他ロックを、既存のローカル・トランザクションでグローバル・トランザクション用にマップ・エントリを修正することによって、グローバル排他制御機構の排他ロックに切り替え、グローバル・トランザクションに昇格させる。

この目的のため、本発明のシステムは、グローバル・トランザクションの状態を管理するため、各サーバに、グローバル・トランザクションのトランザクションＩＤとその状態を対でもつ、管理用マップを、KVS上のマップとして、分散配置する。こうして管理用マップを配置しておくことで、ローカル・トランザクション同士及びグローバル・トランザクション同士及びローカル・トランザクションとグローバル・トランザクションの共有・排他ロック衝突はローカル排他制御機構が解決し、グローバル・トランザクション同士の排他・排他ロック衝突は管理用マップを用いて解決し、ローカル・トランザクションとグローバル・トランザクションの排他・排他ロック衝突はローカル排他制御機構が解決し、グローバル・トランザクションとローカル・トランザクションの排他・共有ロック衝突及び排他・排他ロック衝突は、ローカル・トランザクションをグローバル・トランザクションに昇格後に管理用マップを利用して解決する。

本発明によれば、マップ・エントリ毎に、ＫＶＳのトランザクション機構を利用して、S(グローバル・トランザクションまたはローカル・トランザクションの照会中に獲得する共有ロック）、Init（アクセスなし）、LX（ローカル・トランザクションの更新中に獲得する排他ロック）、GX（グローバル・トランザクションの更新中に獲得する排他ロック）という４つのロック状態が管理される。

そして本発明によれば、あるマップ・エントリに対するSロック（LXロック）獲得試行時、他のグローバル・トランザクションによってそのマップ・エントリに対するロックがGXであることが認識された場合、ローカル・トランザクションからグローバル・トランザクションへの昇格処理が開始される。

最初のステップは、グローバル・トランザクションの開始処理を行うことで、先ずトランザクションＩＤを確定する。
次に、現在LXロックを獲得中の全マップ・エントリに対して、更新前の値CURRENTと更新中の値 DIRTYと、生成したトランザクションＩＤを値として挿入する。
次に、現在Sロックを獲得中の全マップ・エントリに対し、別のローカル・トランザクションを起動し、重複してSロックを獲得する。このとき、元のローカル・トランザクションでSロックを獲得済みのため、これは必ず成功する。
次に、元のローカル・トランザクションをコミットする。すると、獲得していたLXロックは、GXロックに昇格する。
次に、GXを獲得しているグローバル・トランザクションの終了を待機する。
待機対象のグローバル・トランザクションの終了後、グローバル・トランザクションとしてSロック（GXロック）の獲得を試行する。

この発明によれば、分散ＫＶＳシステムにおいて、ローカル・トランザクションを場合に応じてグローバル・トランザクションに昇格させる機能を提供することによって、１台のサーバ上のマップ・エントリを更新・照会するローカル・トランザクションを高速に実現しつつ、複数のサーバ上のマップ・エントリを更新・照会するグローバル・トランザクションが実現される。

本発明の実施するためのシステム全体の概要図である。 クライアント・コンピュータのハードウェアの概要ブロック図である。 サーバのハードウェアの概要ブロック図である。 クライアント・コンピュータとサーバにおける機能ブロック図である。 従来のＫＶＳシステムの概要を示す図である。 従来のＫＶＳシステムの処理の例を示す図である。 グローバル・トランザクションを実行する従来のＫＶＳシステムの処理の例を示す図である。 本発明のＫＶＳシステムの概要を示す図である。 ロックの状態遷移を示す図である。 トランザクションの最初の照会・更新時の処理のフローチャートを示す図である。 トランザクションの２回目以降の照会・更新時の処理のフローチャートを示す図である。 グローバル・トランザクションの開始処理のフローチャートを示す図である。 ローカル・トランザクションからグローバル・トランザクションに昇格させる処理のフローチャートを示す図である。 グローバル・トランザクションの照会処理のフローチャートを示す図である。 グローバル・トランザクションの更新処理のフローチャートを示す図である。 グローバル・トランザクションのコミット処理のフローチャートを示す図である。 グローバル・トランザクションの待機処理のフローチャートを示す図である。 グローバル・トランザクションの終了処理のフローチャートを示す図である。 本発明のＫＶＳシステムの動作の例を示す図である。

以下、図面を参照して、本発明の実施例を説明する。特に断わらない限り、同一の参照番号は、図面を通して、同一の対象を指すものとする。また、以下で説明するのは、本発明の一実施形態であり、この発明を、この実施例で説明する内容に限定する意図はないことに留意されたい。

図１は、本発明の実施するためのシステムの全体を示す概要図である。図１において、複数のクライアント・コンピュータ１０２ａ、１０２ｂ・・・１０２ｚは、インターネット１０４を介して、ＨＴＴＰなどのプロトコルにより、分散処理システム１０６にアクセスする。

分散処理システム１０６は、ＬＡＮまたはＷＡＮなどの仕組みにより相互接続された複数のサーバ１０６ａ、１０６ｂ、・・・、１０６ｚをもつ。分散サーバ・システム１０６は、キー・バリュー・ストア（ＫＶＳ）の仕組みで、分散データベースを構築するシステムである。すなわち、各サーバ１０６ａ、１０６ｂ、・・・、１０６ｚにはＩＤが付与され、この方式には限定されないが、好適には、キーのハッシュ値のmodを計算することで、そのキーを保持するサーバが一意的に決まる。

従って、クライアント・コンピュータ１０２ａ、１０２ｂ・・・１０２ｚは、照会するキーで、アクセスするサーバ１０６ａ、１０６ｂ、・・・、１０６ｚが決定される。好適には、サーバ１０６ａ、１０６ｂ、・・・、１０６ｚのうちの一台がカタログ・サーバと呼ばれるサーバで、そこには、他のサーバに格納されているキーその他の情報が格納され、クライアント・コンピュータ１０２ａ、１０２ｂ・・・１０２ｚは、カタログ・サーバに一旦アクセスして、サーバ１０６ａ、１０６ｂ、・・・、１０６ｚのうちのどのサーバにアクセスするかの情報を取得してから、指示されたサーバとの接続を確立する。あるいは、クライアント・コンピュータがアクセスした任意のサーバが他の複数のサーバにブロードキャストして、情報を取得する方式も使用できる。以下での説明では便宜上、クライアント・コンピュータが、目的とするサーバを見つけて接続を確立したところから説明する。

クライアント・コンピュータ１０２ａ、１０２ｂ・・・１０２ｚは、分散処理システム１０６にアクセスするために、一意的なグローバル・トランザクションＩＤを生成して、その後の分散処理システム１０６とのトランザクションに、そのグローバル・トランザクションＩＤを使用する。

次に、図２を参照して、図１で参照番号１０２ａ、１０２ｂ・・・１０２ｚのように示されているクライアント・コンピュータのハードウェア構成について、説明する。図２において、クライアント・コンピュータは、主記憶２０６、ＣＰＵ２０４、ＩＤＥコントローラ２０８をもち、これらは、バス２０２に接続されている。バス２０２には更に、ディスプレイ・コントローラ２１４と、通信インターフェース２１８と、ＵＳＢインターフェース２２０と、オーディオ・インターフェース２２２と、キーボード・マウス・コントローラ２２８が接続されている。ＩＤＥコントローラ２０８には、ハードディスク・ドライブ（ＨＤＤ）２１０と、ＤＶＤドライブ２１２が接続されている。ＤＶＤドライブ２１２は、必要に応じて、ＣＤ−ＲＯＭやＤＶＤから、プログラムを導入するために使用する。ディスプレイ・コントローラ２１４には、好適には、ＬＣＤ画面をもつディスプレイ装置２１６が接続されている。ディスプレイ装置２１６には、Ｗｅｂブラウザを通じて、アプリケーションの画面が表示される。

ＵＳＢインターフェース２２０には、必要に応じて、拡張ハードディスクなどのデバイスを接続をすることができる。

キーボード・マウス・コントローラ２２８には、キーボード２３０と、マウス２３２が接続されている。キーボード２３０は、検索のためのキーデータや、パスワードなどを打ち込むために使用される。

ＣＰＵ２０４は、例えば、３２ビット・アーキテクチャまたは６４ビット・アーキテクチャに基づく任意のものでよく、インテル社のＰｅｎｔｉｕｍ（インテル・コーポレーションの商標）４、Ｃｏｒｅ（商標）２ Ｄｕｏ、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。

ハードディスク・ドライブ２１０には、少なくとも、オペレーティング・システムと、、分散処理システム１０６にアクセスするためのクライアント側のアプリケーション・プログラム４０２ａ（図４）が格納されており、システムの起動時に、オペレーティング・システムは、メインメモリ２０６にロードされる。オペレーティング・システムは、Ｗｉｎｄｏｗｓ ＸＰ（マイクロソフト・コーポレーションの商標）、Ｗｉｎｄｏｗｓ Ｖｉｓｔａ（マイクロソフト・コーポレーションの商標）、Ｗｉｎｄｏｗｓ（マイクロソフト・コーポレーションの商標） ７、Ｌｉｎｕｘ（Linus Torvaldsの商標）などを使用することができる。クライアント側のアプリケーション・プログラム４０２ａは、図４のブロック図や、図９〜図１４のフローチャートを参照して、後で詳細に説明する。

通信インターフェース２１８は、オペレーティング・システムが提供するＴＣＰ／ＩＰ通信機能を利用して、イーサネット（商標）・プロトコルなどにより、インターネット１０４を介して、分散処理システム１０６と通信する。

図３は、分散処理システム１０６における、サーバ１０６ａなどのハードウェア構成の概要ブロック図である。図示されているように、インターネット１０４を介して、サーバ１０６ａ、１０６ａ、・・・１０６ｚが接続されている。サーバ１０６ａ、１０６ａ、・・・１０６ｚは基本的に同一の構成なので、ここでは代表的にサーバ１０６ａを示す。図３に示すように、クライアント・コンピュータ１０２ａ、１０２ｂ・・・１０２ｚは、インターネット１０４を経由して、サーバ１０６ａの通信インターフェース３０２に接続される。通信インターフェース３０２はさらに、バス３０４に接続され、バス３０４には、ＣＰＵ３０６、主記憶（ＲＡＭ）３０８、及びハードディスク・ドライブ（ＨＤＤ）３１０が接続されている。

図示しないが、サーバ１０６ａにはさらに、キーボード、マウス、及びディスプレイが接続され、これらによって、保守担当者が、サーバ１０６全体の管理やメンテナンス作業を行うようにしてもよい。

サーバ１０６ａのハードディスク・ドライブ３１０には、オペレーティング・システムが保存されている。

ハードディスク・ドライブ３１０にはさらに、サーバ１０６ａをＷｅｂサーバとして機能させるためのＡｐａｃｈｅなどのソフトウェア、及びＪａｖａ仮想環境を実現するＪａｖａ ＥＥ、及びＪａｖａ仮想環境上で動作する本発明に係る後述するアプリケーション・プログラム４０２ａが保存され、サーバ１０６ａの立ち上げ時に、主記憶３０８にロードされて、動作する。これによって、クライアント・コンピュータ１０２ａ、１０２ｂ・・・１０２ｚが、ＴＣＰ／ＩＰのプロトコルで、サーバ１０６にアクセスすることが可能となる。

サーバ１０６ａのハードディスク・ドライブ３１０にはさらに、IBM(R) WebSphere eXtreme ScaleなどのＫＶＳを実現するためのソフトウェアが保存されている。ハードディスク・ドライブ３１０にはまた、本発明に従う、ＫＶＳ用のトランザクション処理プログラム４０６ａ（図４）が保存されている。このトランザクション処理プログラム４０６ａの機能については、図４のブロック図や、図９〜図１４のフローチャートを参照して、後で詳細に説明する。

尚、上記サーバ１０６ａとして、インターナョナル・ビジネス・マシーンズ・コーポレーションから購入可能な、ＩＢＭ（インターナョナル・ビジネス・マシーンズ・コーポレーションの商標）System X、System i、System pなどの機種のサーバを使うことができる。その際、使用可能なオペレーティング・システムは、AIX（インターナョナル・ビジネス・マシーンズ・コーポレーションの商標）、UNIX(The Open Groupの商標)、Linux(商標)、Windows(商標)2003 Serverなどがある。

図４は、クライアント・コンピュータ１０２ａ、１０２ｂ・・・１０２ｚと、サーバ１０６ａ、１０６ｂ、・・・１０６ｚの各々における、処理プログラムの概要ブロック図を示す。なおここでは代表的に、クライアント・コンピュータ１０２ａとサーバ１０６ａを示す。

クライアント・コンピュータ側のアプリケーション・プログラム４０２ａは、ハードティスク・ドライブ２１０に保存されており、クライアント・コンピュータのユーザーの所定の操作で主記憶２０２にロードされて実行され、クライアント・コンピュータから、サーバ上にあるＫＶＳシステムに対して、トランザクションの開始、データの照会、データの更新、コミット、トランザクションの終了などの処理を指示する機能をもつ。

アプリケーション・プログラム４０２ａは、システム全体で一意的なグローバル・トランザクションＩＤ(TxID)を生成する機能４０４ａをもつ。グローバル・トランザクションＩＤの生成方法の１つの例は、クライアント・コンピュータ１０２ａ、１０２ｂ・・・１０２ｚと、サーバ１０６ａ、１０６ｂ、・・・１０６ｚの各々に固有のＩＤを付与しておき、各クライアント・コンピュータでトランザクションを開始する度に、そのクライアント・コンピュータのＩＤ＋クライアント・コンピュータ内の増分される通し番号をグローバル・トランザクションＩＤとすることであるが、システム全体で一意的なグローバル・トランザクションＩＤになるようにする任意の方法を使用してもよい。

アプリケーション・プログラム４０２ａは、グローバル・トランザクションＩＤを生成してサーバ１０６ａにアクセスすることができるが、別グローバル・トランザクションＩＤを生成することにより、同時に複数のサーバにアクセスし、複数のグローバル・トランザクションを処理することができる。

サーバ１０６ａのハードティスク・ドライブ３１０には、トランザクション処理プログラム４０６ａと、例えばIBM(R) WebSphere eXtreme ScaleであるＫＶＳプログラム４０８ａと、ＫＶＳプログラム４０８ａによって参照される、キー(KEY)とバリュー(VALUE)のペアが保存され、トランザクション処理プログラム４０６ａとＫＶＳプログラム４０８ａは、サーバ１０６ａのスタートアップ時に、主記憶３０８にロードされて動作する。

トランザクション処理プログラム４０６ａは、クライアント・コンピュータ１０２ａからの、グローバル・トランザクションのトランザクションＩＤを伴うリクエストに応答して、マップ・エントリのロック獲得を伴う処理、コミット・ロールバックの処理などの動作を行うようにＫＶＳプログラム４０８ａを制御するとともに、好適には主記憶３０８に、グローバル・トランザクションＩＤと、状態と、待ちグローバル・トランザクションＩＤを含むエントリをもつ管理用マップ４１２ａを作成して、サーバ毎に維持する。

さて、本発明に従うＫＶＳシステムの構成と動作を説明する前に、従来の典型的ないくつかのＫＶＳシステムの構成と動作を説明する。これらを参照することにより、本発明に従うシステムの特徴がより明らかになるものと思量する。

図５は、従来の典型的なＫＶＳの構成を示す図である。ここで改めてＫＶＳについて説明すると、図示されているように、データはデータ５０２ａ、５０２ｂ、５０２ｃ、５０２ｄのように分割され、複数のサーバ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄに分散して配置される。クライアント・コンピュータ１０２ｂは、１台のサーバに対して、トランザクション処理を要求するが、クライアント・コンピュータ１０２ａのように、２台のサーバに対してトランザクション処理を要求することもできる。このとき、互いに素(disjoint)になるように、データは分散配置されている。データを配置するサーバは、好適には、キーのハッシュ値のmodを計算することで決定される。

クライアント・コンピュータ１０２ａ、１０２ｂは、begin（トランザクションを開始する）、put（キーとバリューを対応付ける）、get（キーに対応するバリューを取得する）、commit（コミット、すなわち更新を確定する）などのコマンドを、キーによって一意的に決まるサーバに送って処理を要求する。

図６は、従来の典型的なＫＶＳシステムにおける、クライアント・コンピュータ１０２ａ、クライアント・コンピュータ１０２ｂと、サーバ１０６ａ、サーバ１０６ｂの間のトランザクション処理の例を示す図である。Tx1、Tx2、Tx3はそれぞれ、ローカル・トランザクションのトランザクションＩＤである。この例では、クライアント１、すなわちクライアント・コンピュータ１０２ａがサーバ１、すなわちサーバ１０６ａに対してデータ・マップに対するput(K1,U1)を実行し、次にサーバ２、すなわちサーバ１０６ｂに対してデータ・マップに対するget(K4)を実行後、データ・マップに対するput(K3,U3)を実行するよう指示し、次にサーバ１に対してcommitを実行するよう指示し、サーバ１に対してcommitを実行するよう指示する。

一方、クライアント２、すなわちクライアント・コンピュータ１０２ｂは、データ・マップに対するput(K2,U2)、get(K5)、put(K1,U1')、commitという処理を順次サーバ１に対して行う。

この場合、commit処理において、サーバ１がcommitを終了した後、サーバ２のcommit処理前にクライアント１に障害が発生した場合、サーバ２はトランザクションをcommitしていいのかどうか判断できないため、クライアント１は、K1とK3をアトミックに更新できず、よってグローバル・トランザクションは実現できない。

これを解決するために、図７に示すような、２フェーズ・コミットを応用し、グローバル・トランザクションを可能とするＫＶＳシステムが開発された。このようなシステムにおいては、共有ロックが、ローカル・トランザクションで保持され、排他ロックは、更新前のコミット済みの値(CURRENT)・更新中の値(DIRTY)とともに、排他ロックを獲得中のグローバル・トランザクションのトランザクションＩＤ（LOCK）を含んだマップ・エントリの値[CURRENT->DIRTY, LOCK]として保持される。なお、便宜上、以降、マップ・エントリはKEY列、VALUE列、LOCK列から構成されるものとし、VALUE列には、CURRENT及びDIRTYの値（CURRENT->DIRTY）を、LOCK列にはLOCKの値が格納されるものとする。DIRTYの値が存在しない場合は、VALUE列にはCURRENTのみを格納される。また、図７において、Tx1-1、Tx1-2、Tx2-1、Tx2-2、Tx2-3、GTX1-1、GTｘ1-2はローカル・トランザクションのトランザクションＩＤであり、GTx1、GTx2は、グローバル・トランザクションのトランザクションＩＤである。また、Tx1-1、Tx1-2、GTｘ1-1、GTx1-2で示されるローカル・トランザクションは、GTx1で示されるグローバル・トランザクションを処理するためのローカル・トランザクション処理である。

クライアント１である、クライアント・コンピュータ１０２ａにおいてまず、ローカル・トランザクションGTx1-1がまず、管理用マップに対し、put(GTxA,working)の後、commitするようにサーバ３（サーバ１０６ｃ）に指示する。

続いてクライアント１は、ローカル・トランザクションTx1-1で、データ・マップに対し、put(K1,V1->U1,GTxA)の後、commitするようにサーバ１（サーバ１０６ａ）に指示する。

次にクライアント１は、ローカル・トランザクションTx2-1で、データ・マップに対し、get(K4)を実行するようにサーバ２（サーバ１０６ｂ）に指示する。

次にクライアント１は、ローカル・トランザクションTx2-2で、データ・マップに対し、put(K3,V3->U3,GTxA)を実行し、commitするようにサーバ２に指示する。

次にクライアント１は、ローカル・トランザクションGTx1-2で、管理用マップに対し、put(GTxA,committed)の後、commitするようにサーバ３に指示する。

次にクライアント１は、ローカル・トランザクションTx1-2で、データ・マップに対し、put(K1,U1,NULL)を実行し、commitするようにサーバ１に指示する。

次にクライアント１は、ローカル・トランザクションTx2-1で、commitするようにサーバ２に指示する。

次にクライアント１は、ローカル・トランザクションTx2-3で、データ・マップに対し、put(K1,U3,NULL)の後、commitするようにサーバ２に指示する。

一方、クライアント２、すなわち、クライアント・コンピュータ１０２ｂは、サーバ１に対して、ローカル・トランザクションTx3で、データ・マップに対し、put(K2,U2,NULL)、get(K5)、put(K1,U1',NULL)、commitを実行するように指示する。

このような構成だと、クライアント１は、K1とK3の値をアトミックに更新可能であるが、クライアント２は、ローカル・トランザクションでK1の値を更新してはならない。なぜなら、クライアント１は、更新中のK1のマップ・エントリに対するサーバ１上のローカル排他制御機構のロックを保持しておらず、そのため、クライアント２はK1の値に対するデータを更新できてしまう。しかし、グローバル・トランザクション処理内では、クライアント１がLOCK値としてGTxAと記入しているので、本来は更新できてはならないものである。これを防ぐには、全てのトランザクションをグローバル・トランザクションにしなくてはならないが、複数のローカル・トランザクションにより実現されるグローバル・トランザクションはローカル・トランザクションよりもオーバーヘッドが大きいので、システム全体の性能が低下してしまう。

図８は、本発明の構成を示す。ここでの参照番号は、図４の機能ブロック図に対応する。すなわち、各サーバ１０６ａ、１０６ｂ、１０６ｃ、１０６ｄに、トランザクションＩＤ(TxID)とトランザクションの状態の列をもつ、管理用マップ４１２ａ、４１２ｂ、４１２ｃ、４１２ｄをそれぞれ別途設ける。そこで、VALUEの列に格納されるのがトランザクションの状態である。

また、各サーバ１０６ａ、１０６ｂ、１０６ｃ、１０６ｄには、ＫＶＳのデータを格納するテーブル（データ・マップ）４１０ａ、４１０ｂ、４１０ｃ、４１０ｄも設けられる。データ・マップ４１０ａ、４１０ｂ、４１０ｃ、４１０ｄはそれぞれ、キーを入れる列であるKEY列と、コミット確定済みの値と更新中の値を入れる列であるVALUE列と、ロック状態、すなわち更新中のトランザクションＩＤを格納するLOCK列をもつ。

各サーバ１０６ａ、１０６ｂ、１０６ｃ、１０６ｄは、データ・マップ４１０ａ、４１０ｂ、４１０ｃ、４１０ｄにおいて、マップ・エントリ毎に、ＫＶＳのトランザクション機構を利用して、４つのロック状態を管理する。４つのロック状態とは、S(グローバル・トランザクションまたはローカル・トランザクションが照会中）、Init（アクセスなし）、LX（ローカル・トランザクションが更新中）、GX（グローバル・トランザクションが更新中）であり、４つのロック状態は、図９の遷移図に従い遷移する。

図８において、グローバル・トランザクションを要求するクライアント・コンピュータ１０２ａは、複数のローカル・トランザクションを処理要求し、ローカル・トランザクションを要求するクライアント・コンピュータ１０２ｂは、単一のローカル・トランザクションを処理要求する。

各サーバ１０６ａ、１０６ｂ、１０６ｃ、１０６ｄは、図示しないが、ローカル排他制御機構を備え、各サーバ１０６ａ、１０６ｂ、１０６ｃ、１０６ｄに管理用マップ４１２ａ、４１２ｂ、４１２ｃ、４１２ｄを配置しておくことで、ローカル・トランザクション同士及びグローバル・トランザクション同士及びローカル・トランザクションとグローバル・トランザクションの共有・排他ロック衝突はローカル排他制御機構が解決し、グローバル・トランザクション同士の排他・排他ロック衝突は管理用マップを用いて解決し、ローカル・トランザクションとグローバル・トランザクションの排他・排他ロック衝突はローカル排他制御機構が解決し、グローバル・トランザクションとローカル・トランザクションの排他・共有ロック衝突及び排他・排他ロック衝突は、ローカル・トランザクションをグローバル・トランザクションに昇格後に管理用マップを利用して解決する。なお、ローカル排他制御機構においては、Getを要求した場合は共有ロックを、Putを要求した場合は排他ロックを、GetForUpdateを要求した場合は排他ロックを、要求したローカル・トランザクションを要求するクライアントに与えるものとする。

次に、４つのロック状態すなわち、S(グローバル・トランザクションまたはローカル・トランザクションが照会中）、Init（アクセスなし）、LX（ローカル・トランザクションが更新中）、GX（グローバル・トランザクションが更新中）について説明する。図９に示すように、Initからは、S、LX、GXのどれかに移行する。

Sからは、Init、LX、GXのどれかに移行する。LX、GXからは、Initに戻れるだけである。

ローカル・トランザクションがSロックを要求する場合、ローカル・トランザクションを開始し、照会処理（Get）を行い、GXでないことを確認後、照会処理を行う。GXの場合は、 ローカル・トランザクションをグローバル・トランザクションに昇格し、グローバル・トランザクションとして、更新中のグローバル・トランザクションの終了を待機し、その後、グローバル・トランザクションとして、Sを要求する。

ローカル・トランザクションがLXロックを要求する場合、ローカル・トランザクションを開始し、排他ロックの獲得を伴う照会処理（GetForUpdate）を行い、GXでないことを確認後、更新処理を行う。GXの場合は、 ローカル・トランザクションをグローバル・トランザクションに昇格し、更新中のグローバル・トランザクションの終了を待機し、その後、 グローバル・トランザクションとして、GXを要求する。

ローカル・トランザクションがCommit/Rollbackを要求する場合、ローカル・トランザクションのCommit/Rollbackを行う。

グローバル・トランザクションがSロックを要求する場合、ローカル・トランザクションを開始し、GXでないことを確認後、照会処理を行う。GXの場合は、ローカル・トランザクションをコミットし、更新中のグローバル・トランザクションの終了を待機する。

グローバル・トランザクションがGXロックを要求する場合、ローカル・トランザクションを開始し、データ・マップに対してGetForUpdateを利用して、Initであることを確認後、マップ・エントリ中のVALUE列のDIRTY、LOCK列の更新処理を行い、ローカル・トランザクションをコミットする。GXの場合は、ローカル・トランザクションをコミットし、更新中のグローバル・トランザクションの終了を待機する。

グローバル・トランザクションがGXからCommitを要求する場合、ローカル・トランザクションを開始し、VALUE列のCURRENT->DIRTYをDIRTYに更新し、LOCK列を削除し、ローカル・トランザクションをコミットする。

グローバル・トランザクションがGXからRollbackを要求する場合、ローカル・トランザクションを開始し、VALUE列のDIRTY、LOCK列を削除し、ローカル・トランザクションをコミットする。

次に、クライアント・コンピュータからの指示に従って、サーバで実行される処理について、フローチャートを参照して説明する。以下では特にフローチャートでの説明の便宜上、トランザクションIDをTxID、ローカル・トランザクションをLocalTx、グローバル・トランザクションをGlobalTxと略記することがある。

図１０は、トランザクションの最初の照会・更新時の処理時の処理のフローチャートを示す図である。

ステップ１００２では、トランザクションからのリクエストに応答して、例えばカタログ・サーバに一旦アクセスことによって、照会・更新するキーを基に、サーバが特定される。このために例えば、キーのハッシュ値をサーバの数で割った余りの値で、サーバＩＤを特定する。

ステップ１００４では、特定したサーバが、ローカル・トランザクションを開始する。ステップ１００６では特定したサーバがキーに対応する値を照会し、ステップ１００８では、照会したマップ・エントリのLOCK列に他のトランザクションＩＤがあるかどうか判断し、もしそうなら、ステップ１０１０でグローバル・トランザクションに昇格後、グローバル・トランザクションとして照会処理を行う。グローバル・トランザクションへの昇格の具体的処理については、図１３のフローチャートを参照して、後で説明する。

ステップ１００８で、照会した値のLOCK列に他のトランザクションＩＤはないと判断されると、ステップ１０１２で照会処理かどうか判断され、そうでないなら、ステップ１０１４で、ローカル・トランザクションとして更新処理が行われる。なお、ここでLOCKとは、データ・テーブル４１０ａ、・・・などのLOCK列の値のことである。

図１１は、トランザクションの２回目以降の照会・更新時の処理時の処理のフローチャートを示す図である。

ステップ１１０２では、トランザクションが、グローバル・トランザクションとして稼動中かどうかが判断される。もしそうなら、ステップ１１０４で、グローバル・トランザクションとして照会・更新処理が行われる。

グローバル・トランザクションとして稼動中でないなら、ステップ１１０６で、例えばカタログ・サーバに一旦アクセスことによって、照会・更新するキーを基に、サーバが特定される。このために例えば、キーのハッシュ値をサーバの数で割った余りの値で、サーバＩＤを特定する。

ステップ１１０８では前回と同じサーバかどうか判断され、もしそうなら、ステップ１１１０で、特定されたサーバがキーに対応する値を照会する。この際、更新処理の場合は、排他ロックを伴う照会(GetForUpdate)となる。

ステップ１１１２では、特定したサーバは、照会した値のロックに他トランザクションＩＤ(TxID)があるかどうかを判断する。もしそうなら、ステップ１１１４で、グローバル・トランザクションに昇格後、グローバル・トランザクションとして照会処理が行われる。

ステップ１１１２で、照会した値のロックに他のトランザクションＩＤはないと判断されると、ステップ１１１６で照会処理かどうか判断され、そうでないなら、ステップ１１１８で、ローカル・トランザクションとして更新処理が行われる。

ステップ１１０８に戻って、前回の処理と同じサーバでないと判断されると、ステップ１１１４で、グローバル・トランザクションに昇格後、グローバル・トランザクションとして照会処理が行われる。

図１２は、グローバル・トランザクションの開始処理のフローチャートを示す図である。

ステップ１２０２では、グローバル・トランザクションの識別子であるトランザクションＩＤが、クライアント内で生成される。

ステップ１２０４では、トランザクションＩＤを基に、サーバが特定される。このとき例えば、トランザクションＩＤのハッシュ値をサーバの数で割った余りの値で、サーバＩＤを特定する。

ステップ１２０６では、特定したサーバで、管理用ローカル・トランザクションが開始される。そしてステップ１２０８で、管理用ローカル・トランザクション内で、トランザクションＩＤをキーとするマップ・エントリの排他ロックが獲得される。

図１３は、ローカル・トランザクションからグローバル・トランザクションに昇格する処理のフローチャートを示す図である。

ステップ１３０２では、トランザクションＩＤを識別子とするグローバル・トランザクションが開始される。

ステップ１３０４では、ローカル・トランザクションを処理しているサーバで、照会用ローカル・トランザクションが開始される。

ステップ１３０６では、ローカル・トランザクションで照会中、すなわちSロックを獲得中の全ての値が、照会用ローカル・トランザクションで照会される。

ステップ１３０８では、ローカル・トランザクションで更新中、すなわちLXロックを獲得中の全ての値が、更新前の値(CURRENT)と更新中の値(DIRTY)と排他ロックを獲得中のトランザクションＩＤ（LOCK）を組み合わせた値[CURRENT->DIRTY,LOCK]に更新する。なお、ここでLOCK値とは、データ・テーブル４１０ａ、・・・などのLOCK列の値のことである。

ステップ１３１０では、元のローカル・トランザクションがコミットされる。これによって、獲得していたLXロックは、GXロックに昇格する。なお、この時点で照会用ローカル・トランザクションをコミットしないことに留意されたい。

図１４は、グローバル・トランザクションの照会処理のフローチャートを示す図である。ステップ１４０２では、キーを基に、サーバが特定される。このために例えば、キーのハッシュ値をサーバの数で割った余りの値で、サーバＩＤを特定する。

ステップ１４０４では、特定されたサーバで照会用ローカル・トランザクションを開始する。

ステップ１４０６では、照会用ローカル・トランザクションでキーに対応する値が照会される。

ステップ１４０８では、照会した値のLOCK値に他トランザクションＩＤがあるかどうかが判断され、もしそうならステップ１４１０で他トランザクションＩＤの待機処理が行われ、ステップ１４０２に戻る。

照会した値のLOCK値に他トランザクションＩＤがないなら、処理は終了するが、この時点では照会用ローカル・トランザクションはコミットされない。

図１５は、グローバル・トランザクションの更新処理のフローチャートを示す図である。ステップ１５０２では、キーを基に、サーバが特定される。このために例えば、キーのハッシュ値をサーバの数で割った余りの値で、サーバＩＤを特定する。

ステップ１５０４では、特定されたサーバで更新用ローカル・トランザクションを開始する。

ステップ１５０６では、更新用ローカル・トランザクションでキーに対応する値が照会される。

ステップ１５０８では、照会した値のLOCK値に他トランザクションＩＤがあるかどうかが判断され、もしそうならステップ１５１０で他トランザクションＩＤの待機処理が行われ、ステップ１５０２に戻る。

照会した値のLOCK値に他トランザクションＩＤがないなら、ステップ１５１２で、更新用ローカル・トランザクションで、更新前の値(CURRENT)と更新中の値(DIRTY)と排他ロックを獲得中のトランザクションＩＤ(TxID)を組み合わせた値[CURRENT->DIRTY,TxID]に更新される。

ステップ１５１４では、更新用ローカル・トランザクションがコミットされる。

図１６は、グローバル・トランザクションのコミット処理のフローチャートを示す図である。ステップ１６０２では、該当するサーバが、管理用ローカル・トランザクションで、管理用マップのトランザクションＩＤをキーとする値をCommittedに更新する。

当該サーバは、ステップ１６０４で、管理用ローカル・トランザクションをコミットする。

ステップ１６０６でコミットが成功したかどうかの判断が行われ、そうでないならステップ１６０８でロールバックが行われる。

ステップ１６０６でコミットが成功したと判断されると、ステップ１６１０で、全ての照会用がコミットされる。

ステップ１６１２では、全ての更新中のVALUEを選択したかどうかが判断され、もしそうなら処理は終了する。

全ての更新中のVALUEがまだ選択されたのでないなら、ステップ１６１４で、更新中のキー(KEY)とその値[CURRENT->DIRTY,TxID]が選択される。

ステップ１６１６では、キーを基にサーバが特定される。このために例えば、キーのハッシュ値をサーバの数で割った余りの値で、サーバＩＤを特定する。

ステップ１６１８では、特定したサーバで更新用ローカル・トランザクションが開始される。

ステップ１６２０では、更新用ローカル・トランザクションで、キーに対応する値が照会される。

ステップ１６２２では、照会した値が[CURRENT->DIRTY,TxID]かどうか判断し、もしそうなら、ステップ１６２４で更新用ローカル・トランザクションで、キーに対応する値が[DIRTY,NULL]に更新され、ステップ１６２６で更新用ローカル・トランザクションがコミットされ、ステップ１６１２に戻る。

ステップ１６２２で、照会した値が[CURRENT->DIRTY,TxID]でない場合は直ちにステップ１６２６で更新用ローカル・トランザクションがコミットされ、ステップ１６１２に戻る。

図１７は、トランザクションＩＤ TxID'を識別子とするグローバル・トランザクションの待機処理のフローチャートを示す図である。

ステップ１７０２は、管理用ローカル・トランザクションで、トランザクションＩＤ TxIDをキーとする値を、[Waiting,TxID']に更新する処理が行われる。

ステップ１７０４で、管理用ローカル・トランザクションがコミットされる。

ステップ１７０６でコミットが成功したかどうかの判断が行われ、そうでないならステップ１７０８でロールバックが行われる。

ステップ１７０６でコミットが成功したと判断されると、ステップ１７１０で、TxID'を基にサーバが特定される。これは例えば、TxID'のハッシュ値をサーバ数で割った値で決定する。

ステップ１７１２では、特定したサーバで待機用ローカル・トランザクションが開始される。

ステップ１７１４では、待機用ローカル・トランザクションで、TxID'の値が管理用マップで照会される。

ステップ１７１６では、TxID'の値がCommittedとRollbackedのどちらかが判断され、Committedの場合は、ステップ１７１８でTxIDを基にサーバが特定され、ステップ１７２０で、管理用ローカル・トランザクションで、TxIDをキーとする値を、Workingに更新し、処理を終了する。

TxID'の値がRollbackedであった場合には、ステップ１７２２で、TxID'の値にTxIDが含まれているかどうかが判断され、そうでないならステップ１７２４でロールバック処理に進む。

ステップ１７２２で、TxID'の値にTxIDが含まれていると判断されると、ステップ１７２６で待機用ローカル・トランザクションがコミットされ、次にステップ１７２８でTxIDを基にサーバが特定され、次にステップ１７３０で、特定したサーバで管理用ローカル・トランザクションが開始される。

そして、ステップ１７３２で、TxID'のグローバル・トランザクションの待機処理が開始される。

図１８は、グローバル・トランザクションの終了処理のフローチャートを示す図である。

ステップ１８０２では、グローバル・トランザクションの開始時に開始したローカル・トランザクションを用いて、グローバル・トランザクションの状態を表すマップ・エントリに対する値を、CommittedもしくはRollbackedに更新してコミットが行われる。

ステップ１８０４では、グローバル・トランザクションの状態がCommittedまたはRollbackedのどちらかであるかに応じて分岐され、Committedの場合はステップ１８０６で、グローバル・トランザクション内で更新した全マップ・エントリに対し、 VALUE列のCURRENT->DIRTYをDIRTYに更新し、LOCK列を削除する処理（ローカル・コミット）が行われ、Rollbackedの場合はステップ１８０８で、グローバル・トランザクション内で更新した全マップ・エントリに対し、VALUE列のDIRTY、LOCK列を削除する処理（ローカル・ロールバック）が行われる。

次に、クライアントの障害時の処理について説明する。
先ず、グローバル・トランザクションのコミット前に、クライアントに障害が発生した場合、各マップ・エントリはGX状態のまま残る。そして、管理マップのグローバル・トランザクションの状態を表すマップ・エントリに対するローカル・トランザクションは、当該サーバによりロールバックされ、状態が保存されていない状態になる。次回、当該マップ・エントリを照会・更新するトランザクションは、管理マップを確認することで、トランザクションがロールバック済みであることを確認可能である。ロールバック済みであった場合は、 ローカル・ロールバック処理は、ロールバック済みであることを確認したトランザクションが行う。

次に、ローカル・コミット処理前に、クライアントに障害が発生した場合、各マップ・エントリはGX状態のまま残る。次回、当該マップ・エントリを照会・更新するトランザクションは、管理マップを確認することで、コミット済みであることを確認可能である。コミット済みであった場合は、 ローカル・コミット処理は、コミット済みであることを確認したトランザクションが行う。

このように、グローバル・トランザクションのコミット前に、クライアントに障害が発生した場合でも、ローカル・コミット処理前に、クライアントに障害が発生した場合でも、本発明によれば、処理の一貫性を保つことが可能である。

次に図１９を参照して、本発明のこの実施例の動作の例を説明する。図１９において先ず、クライアント１（クライアント・コンピュータ１０２ａ）のグローバル・トランザクションGTxA-1がサーバ３（サーバ１０６ｃ）に対して、put(GTxA,working)を実行するよう指示し、続いてcommitするように指示する。

次にクライアント１のローカル・トランザクションTx1-1が、サーバ１（サーバ１０６ａ）に対して、put(K1,V1->U1,GTxA)を実行するよう指示し、続いてcommitするように指示する。

次にクライアント１のローカル・トランザクションTx2-1が、サーバ２（サーバ１０６ｂ）に対して、put(K3,V3->U3,GTxA)を実行するよう指示し、続いてcommitするように指示する。

次にクライアント１のローカル・トランザクションTx1-2が、サーバ１に対して、put(GTx1,committed)を実行するよう指示し、続いてcommitするように指示する。それと同時にクライアント１のグローバル・トランザクションGTxA-1がサーバ３に対して、put(GTxA,committed)を実行するよう指示し、続いてcommitするように指示する。

この間にクライアント２（クライアント・コンピュータ１０２ｂ）のローカル・トランザクションTx3がサーバ１に対してGetForUpdate(K1)を実行しようと試みる。このとき処理は、他のグローバル・トランザクションによって排他ロックがとられていない場合と、他のグローバル・トランザクションによって排他ロックがとられている場合とで分かれる。

他のグローバル・トランザクションによって、排他ロックがとられていない場合、以下の処理が実行される。
Tx3-1’. getForUpdate(K2)
Tx3-2’. put(K2, U2, NULL)
Tx3-3’. get(K5)
Tx3-4’. getForUpdate(K1)
Tx3-5’. put(K1,U1’, NULL)
Tx3-6’. commit

他のグローバル・トランザクションによって、排他ロックがとられている場合、以下の処理が実行される。
Tx3-1’. getForUpdate(K2)
Tx3-2’. put(K2, U2, NULL)
Tx3-3’. get(K5)
Tx3-4’. getForUpdate(K1)
Tx3-5’. put(K2, V2->U2, GTxB) // Tx3からGTxBに昇格
Tx4-1’. get(K5) // Tx4を起動し、照会中のマップ・エントリを再照会する
Tx3-6’. commit
Wait for GTxA commit/rollback // GTxAの終了を待機
Tx5-1’. put(K1, U1->U1’, GTxB) // 更新中のマップ・エントリの排他ロックを、既存のトランザクションで、グローバル・トランザクション用に修正する

以上、特定のハードウェア及びソフトウェアのプラットアフォームの上で本発明の実施例を説明してきたが、本発明は、任意のコンピュータのハードウェア及びプラットフォームで実施可能であることを、この分野の当業者なら理解するであろう。

１０２ クライアント・コンピュータ
１０６ サーバ
２０２ 主記憶
２０４ ＣＰＵ
２０６ メインメモリ
２０６ 主記憶
２１０ ハードディスク・ドライブ
３０６ ＣＰＵ
３０８ 主記憶
３１０ ハードディスク・ドライブ
４０４ アプリケーション・プログラム
４０６ トランザクション処理プログラム
４０８ ＫＶＳプログラム
４１０ データ・マップ
４１２ 管理用マップ

Claims (18)

1. 複数のサーバにデータを分散してもち、クライアント・コンピュータからデータにアクセスされる分散ＫＶＳシステムにおいて、該分散ＫＶＳシステムによって実行されるステップを有する方法であって、
   前記複数のサーバの各々に、トランザクションＩＤとその状態を示す値を含む管理テーブルと、キーの値と、バリューと、ロックの値を含むデータ・テーブルを配置するステップと、
   前記クライアント・コンピュータにおいて、トランザクションＩＤを確定して、グローバル・トランザクションを開始するステップと、
   前記複数のサーバのうちローカル・トランザクションを処理しているサーバで、照会用ローカル・トランザクションを開始するステップと、
   前記ローカル・トランザクションで照会中の全ての値を前記照会用ローカル・トランザクションで照会するステップと、
   前記ローカル・トランザクションで更新中の全ての値を、前記データ・テーブルにおいて、更新前の値と更新中前の値と、前記トランザクションＩＤをロックの値の組み合わせに更新するステップと、
   前記ローカル・トランザクションをコミットするステップを有する、
   分散ＫＶＳシステムの処理方法。
2. 前記ローカル・トランザクションをコミットした時点では、前記照会用ローカル・トランザクションはコミットされない、請求項１に記載の処理方法。
3. 前記ロックは、グローバル・トランザクションまたはローカル・トランザクションが照会中というSロックと、ローカル・トランザクションが更新中というLXロックと、グローバル・トランザクションが更新中というGXロックを有する、請求項１に記載の処理方法。
4. 前記グローバル・トランザクションを開始するステップは、
   前記クライアント・コンピュータが前記トランザクションＩＤを生成するステップと、
   前記トランザクションＩＤを基に、前記グローバル・トランザクションの状態を表す管理用マップを保持するサーバを確定するステップと、
   前記前記グローバル・トランザクションの状態を表す前記管理用マップのマップ・エントリに対してローカル・トランザクションを開始し、ロックを獲得するステップを有する、
   請求項１に記載の処理方法。
5. 前記ローカル・トランザクションを用いて、前記管理マップにおける、前記グローバル・トランザクションの状態を表すマップ・エントリの値を、Committedに変更しコミットするステップと、
   前記グローバル・トランザクションで更新した全マップ・エントリに対して、更新中のデータを現在データに変更し、更新中のデータとトランザクションＩＤを削除するステップを実行することにより前記グローバル・トランザクションを終了させるステップをさらに有する、
   請求項４に記載の処理方法。
6. 前記ローカル・トランザクションを用いて、前記管理マップにおける、前記グローバル・トランザクションの状態を表すマップ・エントリの値を、Rollbackedに変更しコミットするステップと、
   前記グローバル・トランザクションで更新した全マップ・エントリに対して、更新中のデータとトランザクションＩＤを削除するステップを実行することにより前記グローバル・トランザクションを終了させるステップをさらに有する、
   請求項４に記載の処理方法。
7. 複数のサーバにデータを分散してもち、クライアント・コンピュータからデータにアクセスされる分散ＫＶＳシステムにおいて、
   前記分散ＫＶＳシステムに、
   前記複数のサーバの各々に、トランザクションＩＤとその状態を示す値を含む管理テーブルと、キーの値と、バリューと、ロックの値を含むデータ・テーブルを配置するステップと、
   前記クライアント・コンピュータにおいて、トランザクションＩＤを確定して、グローバル・トランザクションを開始するステップと、
   前記複数のサーバのうちローカル・トランザクションを処理しているサーバで、照会用ローカル・トランザクションを開始するステップと、
   前記ローカル・トランザクションで照会中の全ての値を前記照会用ローカル・トランザクションで照会するステップと、
   前記ローカル・トランザクションで更新中の全ての値を、前記データ・テーブルにおいて、更新前の値と更新中前の値と、前記トランザクションＩＤをロックの値の組み合わせに更新するステップと、
   前記ローカル・トランザクションをコミットするステップを実行させる、
   分散ＫＶＳシステムの処理プログラム。
8. 前記ローカル・トランザクションをコミットした時点では、前記照会用ローカル・トランザクションはコミットされない、請求項７に記載の処理プログラム。
9. 前記ロックは、グローバル・トランザクションまたはローカル・トランザクションが照会中というSロックと、ローカル・トランザクションが更新中というLXロックと、グローバル・トランザクションが更新中というGXロックを有する、請求項７に記載の処理プログラム。
10. 前記グローバル・トランザクションを開始するステップは、
    前記クライアント・コンピュータが前記トランザクションＩＤを生成するステップと、
    前記トランザクションＩＤを基に、前記グローバル・トランザクションの状態を表す管理用マップを保持するサーバを確定するステップと、
    前記前記グローバル・トランザクションの状態を表す前記管理用マップのマップ・エントリに対してローカル・トランザクションを開始し、ロックを獲得するステップを有する、
    請求項７に記載の処理プログラム。
11. 前記ローカル・トランザクションを用いて、前記管理マップにおける、前記グローバル・トランザクションの状態を表すマップ・エントリの値を、Committedに変更しコミットするステップと、
    前記グローバル・トランザクションで更新した全マップ・エントリに対して、更新中のデータを現在データに変更し、更新中のデータとトランザクションＩＤを削除するステップを実行することにより前記グローバル・トランザクションを終了させるステップをさらに実行させる、
    請求項１０に記載の処理プログラム。
12. 前記ローカル・トランザクションを用いて、前記管理マップにおける、前記グローバル・トランザクションの状態を表すマップ・エントリの値を、Rollbackedに変更しコミットするステップと、
    前記グローバル・トランザクションで更新した全マップ・エントリに対して、更新中のデータとトランザクションＩＤを削除するステップを実行することにより前記グローバル・トランザクションを終了させるステップをさらに実行させる、
    請求項１０に記載の処理プログラム。
13. 複数のサーバにデータを分散してもち、クライアント・コンピュータからデータにアクセスされる分散ＫＶＳシステムであって、
    前記複数のサーバの各々に、トランザクションＩＤとその状態を示す値を含む管理テーブルと、キーの値と、バリューと、ロックの値を含むデータ・テーブルを配置する手段と、
    前記クライアント・コンピュータにおいて、トランザクションＩＤを確定して、グローバル・トランザクションを開始する手段と、
    前記複数のサーバのうちローカル・トランザクションを処理しているサーバで、照会用ローカル・トランザクションを開始する手段と、
    前記ローカル・トランザクションで照会中の全ての値を前記照会用ローカル・トランザクションで照会する手段と、
    前記ローカル・トランザクションで更新中の全ての値を、前記データ・テーブルにおいて、更新前の値と更新中前の値と、前記トランザクションＩＤをロックの値の組み合わせに更新する手段と、
    前記ローカル・トランザクションをコミットする手段を実行を有する、
    分散ＫＶＳシステムの処理システム。
14. 前記ローカル・トランザクションをコミットした時点では、前記照会用ローカル・トランザクションはコミットされない、請求項１３に記載の処理システム。
15. 前記ロックは、グローバル・トランザクションまたはローカル・トランザクションが照会中というSロックと、ローカル・トランザクションが更新中というLXロックと、グローバル・トランザクションが更新中というGXロックを有する、請求項１３に記載の処理システム。
16. 前記グローバル・トランザクションを開始する手段は、
    前記クライアント・コンピュータが前記トランザクションＩＤを生成する手段と、
    前記トランザクションＩＤを基に、前記グローバル・トランザクションの状態を表す管理用マップを保持するサーバを確定する手段と、
    前記前記グローバル・トランザクションの状態を表す前記管理用マップのマップ・エントリに対してローカル・トランザクションを開始し、ロックを獲得する手段を有する、
    請求項１３に記載の処理システム。
17. 前記ローカル・トランザクションを用いて、前記管理マップにおける、前記グローバル・トランザクションの状態を表すマップ・エントリの値を、Committedに変更しコミットする手段と、
    前記グローバル・トランザクションで更新した全マップ・エントリに対して、更新中のデータを現在データに変更し、更新中のデータとトランザクションＩＤを削除する手段を実行することにより前記グローバル・トランザクションを終了させる手段をさらに有する、
    請求項１６に記載の処理システム。
18. 前記ローカル・トランザクションを用いて、前記管理マップにおける、前記グローバル・トランザクションの状態を表すマップ・エントリの値を、Rollbackedに変更しコミットする手段と、
    前記グローバル・トランザクションで更新した全マップ・エントリに対して、更新中のデータとトランザクションＩＤを削除する手段を実行することにより前記グローバル・トランザクションを終了させる手段をさらに有する、
    請求項１６に記載の処理システム。

Images