WO2018193638A1 - 計算機及びトランザクション処理方法 - Google Patents

Abstract

計算機は、リニアライザブルコンセンサスを実現するディセントラライズドストレージシステムに対し、状態情報及びトランザクション（Ｔｘ）情報のうちの状態情報が有するオブジェクトに処理対象のＴｘの状態を書き込む。状態情報は、Ｔｘ毎のオブジェクト（状態オブジェクト）で構成される。Ｔｘ情報は、それぞれがＣＲＵＤ要求の対象となり得るオブジェクト（Ｔｘオブジェクト）で構成される。計算機は、処理対象のＴｘの対象のうち、少なくとも、ＣＵＤが必要とされる各Ｔｘオブジェクトについて、上記の状態に応じたライト要求を送信する。

Description

計算機及びトランザクション処理方法

　本発明は、概して、トランザクションの処理に関する。

　一般に、トランザクション（Ｔｘ）とは、１以上のＣＲＵＤ（Create、Read、Update又はDelete）要求から成り、Ｔｘ処理では、１以上のレコード（典型的には２以上のレコード）に対してＡＣＩＤ（Atomicity、Consistency、Isolation及びDurability）性を保証しつつＣＲＵＤ要求を実行する必要がある。

　また、トランザクションシステム（Ｔｘ処理を行うシステム）は、１以上のテーブルを格納するストレージシステムと、そのストレージシステムと通信可能な複数のクライアント計算機とを含む。複数のクライアント計算機が、並行して、その１以上のテーブルに対する複数のＴｘ処理を実行することがあり得る。

　一般に、トランザクションシステムのアーキテクチャにおいては、マスターノードと１以上のスレーブノードとを含んだマスター／スレーブ型のアーキテクチャが採用される。マスターノードが全てのＴｘ処理の状態を管理できるので、複数のレコードに対してＡＣＩＤ性を保証しつつＣＲＵＤ要求を実行するトランザクションシステムの実現が容易のためである。マスター／スレーブ型のトランザクションシステムとして、例えば、非特許文献１に開示のシステムがある。

https://static.googleusercontent.com/media/research.google.com/ja//archive/spanner-osdi2012.pdf

　非特許文献１に開示のようなマスター／スレーブ型のトランザクションシステムを実現することは可能である。しかし、実現できるアプリケーションの範囲が必ずしも広くない。例えば、複数の主体が平等に使用、管理及び運用するトランザクションシステムをマスター／スレーブアーキテクチャで実現することは困難である。加えて、マスターノードが常に固定であるため、アベーラビリティ及びスケーラビリティが必ずしも高くない。

　このような課題は、Ｔｘの対象がレコード以外のオブジェクトの場合にもあり得る。

　そこで、特定のノードに依らずＴｘ処理を実現するディセントラライズドなトランザクションシステムが考えられる。本発明の一形態では、既存のディセントラライズドストレージシステムと、クライアント計算機において実現される新しいＴｘ管理機構との組合せにより、ディセントラライズドなトランザクションシステムを実現する。

　具体的には、例えば、下記の通りである。

　通常、ディセントラライズドストレージシステムでは、オブジェクトは、複数のストレージノードにレプリカとして分散し、その複数のレプリカが１つの論理的なオブジェクトとして管理される。従って、ディセントラライズドストレージシステムは、１以上の論理的なオブジェクトから成る論理的な情報Ｘを管理できる。物理的には、論理的なオブジェクト毎に、オブジェクト（レプリカ）は、複数のストレージノードに分散しており、典型的には、ストレージノード間で、存在するオブジェクト（レプリカ）は異なる。なぜなら、通常、論理的なオブジェクト毎に、オブジェクト（レプリカ）の分散先となるストレージノードが異なるからである。例えば、ディセントラライズドストレージシステムがストレージノード１～５から構成されていて、論理的な情報Ｘが論理的なオブジェクトＡ～Ｃから構成されているとする。オブジェクトＡが、ストレージノード１～３にのみ分散していて、オブジェクトＢが、ストレージ２～４にのみ分散していて、オブジェクトＣが、ストレージ３～５にのみ分散していることがあり得る。この場合、ストレージノード３のみが、情報Ｘを構成する全てのオブジェクト（レプリカ）Ａ～Ｃを有するが、ストレージノード３以外のストレージノード１、２、４及び５の各々は、オブジェクトＡ～Ｃのうちの一部のオブジェクトしか有しない。

　ディセントラライズドストレージシステムは、リニアライザブルコンセンサスを実現する機能を有するものとする。リニアライザブルコンセンサスでは、ＣＲＵＤ（Create、Read、Update又はDelete）のいずれも特定の条件の下でアトミックに実行することが、１つの論理的なオブジェクトについて保証されているものの、２以上の論理的なオブジェクトについて保証されていない。以下の説明では、「オブジェクト」は、特段の記載が無い限り、「論理的なオブジェクト」を意味する。また、以下の説明において、ＣＲＵＤに関し、「書込み」は、Read以外（Create、Update及びDelete）のうちのいずれかを意味する。

　そこで、クライアント計算機（ディセントラライズドストレージシステムと通信可能に接続されている計算機）で、クライアントによるＴｘ管理のためのコンピュータプログラムであるＴｘマネージャ（Ｔｘ管理機構の一例）が実行される。また、ディセントラライズドストレージシステムに、Ｔｘの対象となるＴｘ情報に加えて、Ｔｘの状態を管理するための情報である状態情報が、例えばＴｘマネージャにより格納される。

　Ｔｘマネージャは、状態オブジェクトに処理対象のＴｘであるカレントＴｘの状態を書き込むためのライト要求をディセントラライズドストレージシステムに対して送信する（状態オブジェクトは、状態情報を構成する１以上のオブジェクトのうちのいずれかである）。Ｔｘマネージャは、カレントＴｘの対象のうち、少なくとも、ＣＵＤ（Create、Update又はDelete）が必要とされる各Ｔｘオブジェクトについて、上記のライト要求に従う状態に応じたライト要求を、ディセントラライズドストレージシステムに対して送信する（Ｔｘオブジェクトは、Ｔｘ情報を構成する１以上のオブジェクトのうちのいずれかである）。

　以上の結果、ディセントラライズトトランザクションシステム、すなわち、特定のノードによらず（つまり非中央管理型で）Ｔｘ処理を行うトランザクションシステムが実現される。なお、ディセントラライズドストレージシステムでは、典型的には、ソフトウェア（プログラム）とハードウェア（例えばＣＰＵ及びメモリ）とが協働してリニアライザブルコンセンサスが実現されるが、複数のストレージノードが有する複数の専用ハードウェアによりリニアライザブルコンセンサスが実現されてもよい。

　マスター／スレーブ型のトランザクションシステムに比べて、実現できるアプリケーションの範囲が広く、かつ、アベーラビリティ及びスケーラビリティが高いディセントラライズドなトランザクションシステムを実現することができる。

実施例１に係るトランザクションシステムの構成を示す。 クライアント計算機の構成を示す。 ストレージノードの構成を示す。 Ｔｘテーブル及び状態テーブルの各々の構成を示す。 Ｔｘ処理の一例の全体の流れを示す。 図５に例示のＴｘ処理に関しクライアント計算機とディセントラライズドストレージシステム間でのやり取りを示す。 PREPAREの流れを示す。 COMMIT STATE RECORDの流れを示す。 COMMIT TX RECORDSの流れを示す。 ABORT STATE RECORDの流れを示す。 ABORT TX RECORDSの流れを示す。 RECOVERの流れを示す。 実施例２に係るＴｘ処理の一例の流れの一部を示す。 実施例２に係るPREPAREの流れの一部を示す。

　以下、本発明の幾つかの実施例を説明する。

　また、以下の説明では、「インターフェース部」は、１以上のインターフェースを含む。１以上のインターフェースは、１以上の同種の通信インターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

　また、以下の説明では、「記憶部」は、１以上のメモリを含む。記憶部に関して少なくとも１つのメモリは、揮発性メモリでよい。記憶部は、主に、プロセッサ部による処理の際に使用される。記憶部は、メモリの他に、１以上の不揮発性の記憶デバイス（例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive））を含んでもよい。

　また、以下の説明では、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサである。１以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。

　また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ部によって実行されることで、定められた処理を、適宜に記憶部（例えばメモリ）及び／又はインターフェース部（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサ部あるいはそのプロセッサ部を有する装置が行う処理としてもよい。また、プロセッサ部は、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

　また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通符号を使用し、同種の要素を区別する場合は、参照符号を使用することがある。

　また、以下の説明では、「オブジェクト」とは、アプリケーションプログラムのようなプログラムから見た１つの論理的な電子データの塊であり、例えば、レコード、ファイル、キーバリューペア及びタプルのうちのいずれでもよい。以下、オブジェクトとして、レコードを例に取り、複数のオブジェクトを有する情報として、テーブルを例に取る。

　図１は、実施例１に係るトランザクションシステムの構成を示す。

　トランザクションシステムにおいて、Ｔｘ処理におけるＣＲＵＤ（Create、Read、Update又はDelete）要求の対象となるテーブルを格納するストレージシステムとして、本実施例では、リニアライザブルコンセンサスを実現するディセントラライズドストレージシステム１０３が採用される。

　ディセントラライズドストレージシステム１０３は、典型的には、複数のストレージノード１０５で構成された分散コンセンサスを可能とするシステムである。各ストレージノード１０５は、例えば、Ｐ２Ｐ（Pier to Pier）ネットワークに参加したＰ２Ｐノード（Ｐ２Ｐネットワークの構成要素）でよい。ディセントラライズドストレージシステム１０３において、通常、ストレージノード１０５の数は制限されず、ストレージノード１０５間は遠距離でも近距離でもよく、且つ、ストレージノード１０５間でマスター／スレーブの関係は無い（言い換えれば平等である）。

　下記の要素を有する装置であれば、どのような装置も、ストレージノード１０５となり得る。このため、ストレージノード１０５は、プロセッサと記憶装置（少なくとも不揮発性の記憶装置）を有する装置、例えば、汎用計算機であってもよいし、複数の不揮発記憶デバイスを有するストレージ装置でもよいし、スマートフォンのような小型の装置でもよい。また、全てのストレージノード１０５の仕様（例えば、プロセッサ数や記憶容量といったリソース量）が同じである必要もない。
・１以上のレコード（レプリカ）を格納する機能。
・ＣＲＵＤ要求に応答して、リニアライザブルコンセンサスの下でＣＲＵＤ要求を実行する機能。

　各ストレージノード１０５は、分散コンセンサスアルゴリズム（プロトコル）（例えば、Ｐａｘｏｓ、Ｒａｆｔ又はその拡張）で、そのストレージノード１０５以外のストレージノード１０５と通信する。これにより、ＣＲＵＤのいずれも特定の条件の下でアトミックに実行することが、１つの論理的なオブジェクトについて保証されているリニアライザブルコンセンサスが実現される。

　このようなディセントラライズドストレージシステム１０３におけるいずれのストレージノード１０５にも、各クライアント計算機１０１はアクセス可能である。クライアント計算機１０１は、１つのＴｘの処理のために、ディセントラライズドストレージシステム１０３に対して複数の要求（例えばリード要求又はライト要求）を発行するが、そのＴｘについて、複数の要求の発行先は常に同一のストレージノード１０５であってもよいし、要求によって発行先のストレージノード１０５は異なってもよい。複数のクライアント計算機１０１は、複数の物理的な計算機でもよいし、少なくとも１つの物理的な計算機により実行される複数の仮想的な計算機（例えばＶＭ（Virtual Machine））でもよいし、物理的な計算機と仮想的な計算機の混在でもよい。物理的な計算機は、プロセッサと記憶装置（例えばメモリ）を有する装置であり、例えば、汎用計算機でもよいし、アプリケーションサーバ装置のようなサーバ装置でもよいし、スマートフォンのような小型の装置でもよい。本実施例では、各クライアント計算機１０１は、物理的な計算機であるとする。

　本実施例では、各クライアント計算機１０５に、Ｔｘマネージャ１１１がインストールされる。Ｔｘマネージャ１１１は、Ｔｘの指示元（例えばアプリケーションプログラム）とストレージノード１０５との間のやり取りを調整するコンピュータプログラムである。ディセントラライズドストレージシステム１０３をはじめとする分散ストレージシステムにおいては、リニアライザブル（特定の条件の下でアトミック）な書き込みの失敗をリアルタイムに検知すること（別の言い方をすれば、書き込みが失敗なのか遅いのかを区別すること）は困難である。そこで、Ｔｘマネージャ１１１は、レイジーリカバリ処理を実行する。「レイジーリカバリ処理」とは、トランザクション（Ｔｘ）が未確定であることが検知された場合のリカバリ処理である。

　各クライアント計算機１０１は、そのクライアント計算機１０１が実行するＴｘに関してそのクライアント計算機１０１が把握した情報（例えば、Ｔｘの状態）を他のクライアント計算機１０１との間で共有するためのクライアント計算機間通信を実行しない。つまり、クライアント計算機１０１間の情報共有においては、ディセントラライズドストレージシステム１０３を利用する。これにより、ディセントラライズドトランザクションシステムを実現するためのＴｘマネージャ１１１の構成をシンプルにすることができる。

　図２は、クライアント計算機１０１の構成を示す。

　クライアント計算機１０１は、インターフェース部２０１、記憶部２０２及びそれらに接続されたプロセッサ部２０３を有する。クライアント計算機１０１は、インターフェース部２０１を通じて、ストレージノード１０５と通信する。プロセッサ部２０３は、記憶部２０２に格納されたコンピュータプログラムを実行したり、記憶部２０２に格納された情報を参照又は更新したりする。

　記憶部２０２におけるプログラムとして、例えば、Ｔｘ　ＡＰＰ２０４と、Ｔｘマネージャ１１１とがある。Ｔｘ　ＡＰＰ２０４は、指示元の一例であり、Ｔｘマネージャ１１１に対して、リード又はライトといった要求を出すアプリケーションプログラムである。Ｔｘマネージャ１１１は、Ｔｘ　ＡＰＰ２０４とストレージノード１０５間のやり取りを調整する。なお、Ｔｘ　ＡＰＰ２０４は、クライアント計算機１０１内に代えて、クライアント計算機１０１と通信可能な別の計算機で実行されてもよい。この場合、クライアント計算機１０１は、サーバでよく、別の計算機が、そのサーバに対するクライアントでもよい。

　また、記憶部２０２には、キャッシュ領域２０６とワーク領域２０７が設けられる。

　キャッシュ領域２０６には、ストレージノード１０５から読み出された情報が一時的に格納される。読み出された情報は、例えば、後述のＴｘレコード情報である。

　ワーク領域２０７には、キャッシュ領域２０６に読み出された情報に基づく処理の結果等の一時的な情報が格納される。一時的な情報は、例えば、ディセントライズドストレージシステム１０３に対するライト対象の情報である。ライト対象の情報は、例えば、読み出されたＴｘレコード情報それ自体、又は、作成後、更新後或いは削除対象のＴｘレコード情報である。

　図３は、ストレージノード１０５の構成を示す。

　ストレージノード１０５は、インターフェース部３０１、記憶部３０２及びそれらに接続されたプロセッサ部３０３を有する。ストレージノード１０５は、インターフェース部３０１を通じて、他のストレージノード１０５と通信したり、クライアント計算機１０１と通信したりする。プロセッサ部３０３は、記憶部３０２に格納されたコンピュータプログラムを実行したり、記憶部３０２に格納された情報を参照又は更新したりする。

　記憶部３０２におけるプログラムとして、例えば、リニアライザブルコンセンサスを実現するコンセンサスマネージャ３０４がある。コンセンサスマネージャ３０４は、例えば、上述した分散コンセンサスアルゴリズム（プロトコル）に従い、リニアライザブルコンセンサスのために、他のストレージノード１０５と通信する。また、コンセンサスマネージャ３０４は、クライアント計算機１０１からのリード／ライト要求に応答して、リニアライザブルコンセンサスの下でリード／ライト処理を実行する。

　記憶部３０２に格納される情報として、Ｔｘレコード部３５１及び状態レコード部３５２がある。

　Ｔｘレコード部３５１は、１以上のＴｘレコードである。その１以上のＴｘレコードは、後述のＴｘテーブルの少なくとも一部のレプリカである。「Ｔｘレコード」とは、Ｔｘテーブルにおけるレコードである。

　状態レコード部３５２は、１以上の状態レコードである。その１以上の状態レコードは、後述の状態テーブルの少なくとも一部のレプリカである。「状態レコード」とは、状態テーブルにおけるレコードである。

　各ストレージノード１０５が、Ｔｘレコード部３５１及び状態レコード部３５２を有している。ストレージノード１０５間で、Ｔｘレコード部３５１、及び、状態レコード部３５２は異なり得る。なぜなら、通常、論理的なレコード毎に、当該レコード（レプリカ）の分散先となるストレージノード１０５が異なるからである。

　複数のストレージノード１０５が有する複数のＴｘレコード部３５１に基づいて、１つの論理的なＴｘテーブルが構成される。同様に、複数のストレージ１０５が有する複数の状態レコード部３５２に基づいて、１つの論理的な状態テーブルが構成される。なお、レコード部３５１及び３５２のうちの少なくとも１つのレコードが、ストレージノード１０５の外部の記憶デバイスに格納されてもよい。

　図４は、Ｔｘテーブル及び状態テーブルの各々の構成を示す。

　ディセントラライズドストレージシステム１０３が、Ｔｘテーブル３１１及び状態テーブル３１２を管理する。なお、これらのテーブル３１１及び３１２は、論理的に分かれているが、物理的には同一でもよい。すなわち、テーブル３１１及び３１２の各々の構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部または一部が１つのテーブルであってもよい。

　Ｔｘテーブル３１１は、Ｔｘ情報の一例である。Ｔｘテーブル３１１は、１以上（典型的には複数）のＴｘレコードで構成される。Ｔｘテーブル３１１は、Ｔｘ　ＡＰＰ２０４に認識されるテーブルである。各Ｔｘレコードは、プライマリキー４０１が格納されるフィールドと、このＴｘテーブル３１１にとって最新の情報であるカレント情報４５０Ｃが格納されるフィールド群（複数のフィールド）と、このＴｘテーブル３１１にとって１つ古い情報（１つ前のバージョンの情報）であるプレビアス情報４５０Ｐが格納されるフィールド群とを有する。

　プライマリキー４０１は、レコードのＩＤである。

　情報４５０は、バリュー４１１、バージョン４１２、ＴｘＩＤ４１３及びレコード状態４１４で構成される。バリュー４１１は、Ｔｘ　ＡＰＰ２０４に使用されるバリューを示す情報要素である。バリュー４１１は、１つでも複数でもよい。バージョン４１２は、情報４５０のバージョンを示す情報要素である。例えば、情報４５０が新しい程、バージョン４１２としての数値は大きくなる。このため、バージョン４１２の大小から、情報４５０の新旧を判断することができる。ＴｘＩＤ４１３は、バリュー４１１の格納を含んだ処理に対応したＴｘのＩＤを示す情報要素である。レコード状態４１４は、このレコード状態４１４を格納したレコードの状態を示す情報要素である。カレント情報４５０Ｃにおける各種情報要素の参照符号の末尾は、当該情報の参照符号の末尾と同じアルファベット、すなわち、カレントの頭文字である「Ｃ」である。一方、プレビアス情報４５０Ｐにおける各種情報要素の参照符号の末尾は、当該情報の参照符号の末尾と同じアルファベット、すなわち、プレビアスの頭文字である「Ｐ」である。

　Ｔｘテーブル３１１において、プライマリキー４０１及びバリュー４１１は、Ｔｘ　ＡＰＰ２０４により定義された情報である。バージョン４１２、ＴｘＩＤ４１３及び状態４１４が、Ｔｘ管理用のメタデータである。

　状態テーブル３１２は、状態情報の一例である。状態テーブル３１２は、Ｔｘの状態を管理するテーブルである。状態テーブル３１２は、１以上（典型的には複数）の論理的な状態レコードで構成される。各状態レコードは、Ｔｘレコードと異なり、Ｔｘ　ＡＰＰ２０４からのＣＲＵＤ指示の対象（ＣＲＵＤオペレーションの対象）とならない。言い換えれば、状態テーブル３１２は、Ｔｘテーブル３１１と異なり、Ｔｘ　ＡＰＰ２０４に認識されない（提供されない）テーブルである。各状態レコードは、ＴｘのＩＤであるＴｘＩＤ４３１が格納されるフィールドと、Ｔｘの状態を示すＴｘ状態４３２が格納されるフィールドとを有する。

　図５は、Ｔｘ処理の一例の全体の流れを示す。図６は、図５に例示のＴｘ処理に関しクライアント計算機１０１とディセントラライズトストレージシステム１０３間でのやり取りを示す模式図である。なお、「コンセンサスマネージャ部３５４」は、複数ストレージノード１０５にそれぞれ存在する複数のコンセンサスマネージャ３０４である。

　図５の例によれば、処理対象のＴｘは、２以上のＴｘレコードを読み出しその２以上のＴｘレコードを更新し更新後の２以上のＴｘレコードをＴｘテーブル３１１に格納するといった典型的なＴｘである。Ｔｘ処理での更新対象Ｔｘレコードの数は、２以上に限らず、１でもよい。

　Ｔｘマネージャ１１１がディセントラライズトストレージシステム１０３に対して送信したＣＲＵＤ要求は、いずれも、リニアライザブルコンセンサスの下で実行される。例えば、ディセントラライズトストレージシステム１０３に対して、或るプライマリキーに対応したＴｘレコードのリード要求が送信された場合、リニアライザブルコンセンサス（ＣＲＵＤのいずれも特定の条件の下でアトミックに実行することが１つのレコードについて保証された分散コンセンサスプロトコル）に従い、そのプライマリキーに対応した最新のＴｘレコードが読み出される。また、例えば、ディセントラライズトストレージシステム１０３に対して、或るプライマリキーに対応したＴｘレコードのライト（作成、更新又は削除）が要求された場合、リニアライザブルコンセンサスに従い、Ｔｘテーブル３１１にそのＴｘレコードが書き込まれることになる。図５（及び図７～図１２）では、「ｗ／ＬＣ」は、リニアライザブルコンセンサスの下での実行を意味する表記であり、with LCの省略形である。以下の説明では、適宜、「ｗ／ＬＣ」という表記を採用する。

　以下、図５及び図６を参照して、Ｔｘ処理の一例を説明する。なお、Ｔｘ処理の開始時点において、Ｔｘテーブル３１１及び状態テーブル３１２の各々における各フィールド上の数値は、図４に例示の通りであるとする。

　Ｔｘ処理は、例えば、Ｔｘマネージャ１１１がＴｘ　ＡＰＰ２０４からＴｘ開始を指示されたときに開始する。

　Ｔｘマネージャ１１１は、プライマリキー（例えば“１”）を指定したリード指示をＴｘ　ＡＰＰ２０４から受ける。Ｔｘマネージャ１１１は、そのリード指示に応答して、そのプライマリキー（例えば“１”）を指定したリード要求ｗ／ＬＣを、ディセントラライズトストレージシステム１０３に送信する（Ｓ５０１）。コンセンサスマネージャ部３５４は、そのリード要求ｗ／ＬＣに応答して、指定されたプライマリキー（例えば“１”）に対応した最新のＴｘレコード（例えば最新のバージョン４１２Ｃを含んだカレント情報４５０Ｃを有するＴｘレコード）からＴｘレコード情報を読み出し、読み出したＴｘレコード情報を、Ｔｘマネージャ１１１に返す。

　Ｔｘマネージャ１１１は、ディセントラライズトストレージシステム１０３からのＴｘレコード情報を、記憶部２０２（例えばキャッシュ領域２０６）に格納し、そのＴｘレコード情報中の状態４１４Ｃが“Prepared”（未確定を意味する状態の一例）か否かを判断する（Ｓ５０２）。ここでは、プライマリキー４０１“１”に対応したＴｘレコード情報（バリュー４１１Ｃ“５”、バージョン４１２Ｃ“２”、ＴｘＩＤ４１３Ｃ“Ｂ”及び状態４１４Ｃ“Committed”（確定を意味する状態の一例）を含んだ情報）が読み出されたとする。状態４１４Ｃが“Committed”のため、Ｓ５０２の判断結果は偽となる。

　Ｓ５０２の判断結果が偽の場合、Ｔｘマネージャ１１１は、プライマリキー（例えば“１”）及びバリュー（例えば“１０”）を指定したライト指示（Ｔｘ　ＡＰＰ２０４からのライト指示）に応答して、記憶部２０２におけるＴｘレコード情報を更新する（Ｓ５０３）。更新後のＴｘレコード情報は、例えば上述したようにワーク領域２０７に格納される。Ｓ５０３では、例えば、プレビアス情報４５０Ｐにカレント情報４５０Ｃが上書きされる。図４の例で言えば、記憶部２０２において、バリュー４１１Ｐが、“４”から“５”に変わり、バージョン４１２Ｐが、“１”から“２”に変わり、ＴｘＩＤ４１３Ｐが“Ａ”から“Ｂ”に変わり、レコード状態４１４Ｐが“Committed”から“Committed”に変わる（言い換えれば“Committed”のままである）。また、Ｓ５０３では、カレント情報４５０Ｃが更新される。例えば、記憶部２０２において、バリュー４１１Ｃ“５”が、指定されたバリュー（例えば“１０”）に更新され、バージョン４１２Ｃが“２”から“３”にインクリメントされ、ＴｘＩＤ４１３ＣがカレントＴｘのＴｘＩＤ（例えば“Ｃ”）に更新され、レコード状態４１４Ｃが“Committed”から“Prepared”に更新される。

　Ｔｘマネージャ１１１は、処理対象のＴｘレコードに未実施Ｔｘレコード（Ｓ５０１が未だ実行されていないＴｘレコード）が少なくとも１つあるか否かを判断する（Ｓ５０４）。Ｓ５０４の判断結果が真の場合、未実施Ｔｘレコードからのカレント情報４５０Ｃの読み出しのために処理がＳ５０１に戻る。

　Ｓ５０４の判断結果が偽の場合（すなわち、処理対象の全てのＴｘレコードのＴｘレコード情報が記憶部２０２に読み出され且つ更新された場合）、Ｔｘマネージャ１１１は、処理対象のうち全てのＴｘレコードについて、記憶部２０２における更新後のＴｘレコード情報をディセントラライズドストレージシステム１０３上のＴｘテーブル３１１に反映するPREPARE（図７）を実行する（Ｓ５０５）。これにより、PREPAREでは、処理対象のうち全ての各Ｔｘレコードが更新され、結果として、レコード状態４１４Ｃが“Committed”から“Prepared”に変わる。

　図５～図１２の説明において、処理対象のＴｘ（一例として、PREPARE後のＴｘＩＤ４１３Ｃに対応したＴｘ）を「カレントＴｘ」と言い、PREPARE前のＴｘＩＤ４１３Ｃに対応したＴｘを「プレビアスＴｘ」と言うことができる。

　PREPARE（Ｓ５０５）の結果が“Success”の場合（Ｓ５０６：Success）、Ｔｘマネージャ１１１は、カレントＴｘのＴｘＩＤ４３１とカレントＴｘに対応したＴｘ状態４３２“Committed”とを状態テーブル３１２に書き込むためのライト要求ｗ／ＬＣを発行するCOMMIT STATE RECORD（図８）を実行する（Ｓ５０７）。コンセンサスマネージャ部３５４は、そのライト要求ｗ／ＬＣに応答して、カレントＴｘのＴｘＩＤ４３１とそれに対応した状態４３２“Committed”とを状態レコードに書き込む。

　COMMIT STATE RECORD（Ｓ５０７）の結果が“Success”の場合（Ｓ５０８：Success）、Ｔｘマネージャ１１１は、カレントＴｘの状態４１４Ｃ“Committed”を書き込むためのライト要求ｗ／ＬＣを処理対象の各Ｔｘレコードについて発行するCOMMIT TX RECORDS（図９）を実行する（Ｓ５１３）。このCOMMIT TX RECORDSでの対象となるＴｘＩＤは、カレントＴｘのＴｘＩＤである。コンセンサスマネージャ部３５４は、処理対象の各Ｔｘレコードについて、ライト要求ｗ／ＬＣに応答して、レコード状態４１４Ｃ“Committed”を書き込む。

　PREPARE（Ｓ５０５）の結果が“Fail”の場合（Ｓ５０６：Fail）、Ｔｘマネージャ１１１は、カレントＴｘのＴｘＩＤ４３１とカレントＴｘに対応したＴｘ状態４３２“Aborted”とを状態テーブル３１２に書き込むためのライト要求ｗ／ＬＣを発行するABORT STATE RECORD（図１０）を実行する（Ｓ５０９）。コンセンサスマネージャ部３５４は、そのライト要求ｗ／ＬＣに応答して、カレントＴｘのＴｘＩＤ４３１とそれのＴｘ状態４３２“Aborted”とを状態レコードに書き込む。

　ABORT STATE RECORD（Ｓ５０９）の結果が“Success”の場合（Ｓ５１０：Success）、Ｔｘマネージャ１１１は、カレントＴｘのレコード状態４１４Ｃ“Aborted”を書き込むためのライト要求ｗ／ＬＣを処理対象の各Ｔｘレコードについて発行するABORT TX RECORDS（図１１）を実行する（Ｓ５１４）。このABORT TX RECORDSでの対象となるＴｘＩＤは、カレントＴｘのＴｘＩＤである。コンセンサスマネージャ部３５４は、処理対象の各Ｔｘレコードについて、ライト要求ｗ／ＬＣに応答して、レコード状態４１４Ｃ“Aborted”を書き込む。

　PREPARE（Ｓ５０５）の結果が“Unknown”の場合（言い換えれば、“Success”及び“Fail”のいずれでもない場合）（Ｓ５０６：Unknown）、或いは、COMMIT STATE RECORD（Ｓ５０７）又はABORT STATE RECORD（Ｓ５０９）の結果が“Fail”の場合（Ｓ５０８：Fail、又は、Ｓ５１０：Fail）、Ｔｘマネージャ１１１は、カレントＴｘについてRECOVER（図１２）を実行する（Ｓ５１１）。

　RECOVER（Ｓ５１１）の結果が“Committed”の場合（Ｓ５１２：Committed）、Ｔｘマネージャ１１１は、カレントＴｘについて上述のCOMMIT TX RECORDS（図９）を実行する（Ｓ５１３）。RECOVER（Ｓ５１１）の結果が“Aborted”の場合（Ｓ５１２：Aborted）、Ｔｘマネージャ１１１は、カレントＴｘについて上述のABORT TX RECORDS（図１１）を実行する（Ｓ５１４）。RECOVER（Ｓ５１１）の結果が“Unknown”の場合（言い換えれば、“Committed”及び“Aborted”のいずれでもない場合）（Ｓ５１２：Unknown）、Ｔｘマネージャ１１１は、カレントＴｘのＴｘ処理を終了する。

　さて、上述したように、Ｓ５０２では、Ｔｘマネージャ１１１は、Ｓ５０１で読み出されたカレント情報４５０Ｃ内のレコード状態４１４Ｃ、つまり、プレビアスＴｘに対応したレコード状態４１４Ｃが“Prepared”か否かを判断する。プレビアスＴｘの処理において、もし、COMMIT TX RECORDS及びABORT TX RECORDSのいずれも実行されていなければ、プレビアスＴｘに対応したレコード状態４１４Ｃは“Prepared”のままになっている。なお、プレビアスＴｘに対応したCOMMIT TX RECORDS（Ｓ５１３）及びABORT TX RECORDS（Ｓ５１４）のいずれについても、結果の成否は判断されてもされないでもよい（失敗が検知されたとしても直ちにRECOVERが実行されないでよい）。

　そこで、Ｓ５０２の判断結果が真の場合、Ｔｘマネージャ１１１は、プレビアスＴｘについてRECOVER（図１２）を実行する（Ｓ５２１）。

　RECOVER（Ｓ５２１）の結果が“Committed”の場合（Ｓ５２２：Committed）、Ｔｘマネージャ１１１は、プレビアスＴｘについてレコード状態４１４Ｃ“Committed”をＴｘテーブル３１１に書き込むためのライト要求ｗ／ＬＣを発行するCOMMIT TX RECORDS（図９）を実行する（Ｓ５２３）。このCOMMIT TX RECORDSでの対象となるＴｘＩＤは、プレビアスＴｘのＴｘＩＤである。

　RECOVER（Ｓ５２１）の結果が“Aborted”の場合（Ｓ５２２：Aborted）、Ｔｘマネージャ１１１は、プレビアスＴｘについてレコード状態４１４Ｃ“Aborted”をＴｘテーブル３１１に書き込むためのライト要求ｗ／ＬＣを発行するABORT TX RECORDS（図１１）を実行する（Ｓ５２４）。このABORT TX RECORDSでの対象となるＴｘＩＤは、プレビアスＴｘのＴｘＩＤである。

　Ｓ５２３又はＳ５２４の後、Ｔｘマネージャ１１１は、カレントＴｘをアボートする（Ｓ５２５）。

　レイジーリカバリ処理は、プレビアスＴｘが未確定であることがわかったとき（状態４１４Ｃ“Prepared”が見つかったとき）のプレビアスＴｘのリカバリ処理に相当し、具体的には、Ｓ５２１、Ｓ５２２及びＳ５２３（又はＳ５２４）から成る処理に相当する。

　本実施例では、状態４１４Ｃについて、Ｔｘの確定を意味する状態の一例である“Committed”の他に、Ｔｘの未確定を意味する状態の一例である“Prepared”が用意されている。Ｓ５０１で読み出されたカレント情報４５０Ｃ内のレコード状態４１４Ｃが“Prepared”であれば、プレビアスＴｘが未確定であることがわかり、レイジーリカバリ処理が実行される。

　なお、RECOVER（Ｓ５２１）の結果が“Unknown”の場合（Ｓ５２２：Unknown）、Ｔｘマネージャ１１１は、カレントＴｘをアボートする（Ｓ５２５）。

　以上が、Ｔｘ処理の一例の全体の流れである。なお、Ｔｘ処理では、少なくとも１つのＴｘレコードについて、下記のうちの少なくとも１つの変形例もあり得る。
・例えば、削除の場合は、次の通りである。PREPARE（Ｓ５０５）では、削除対象のＴｘレコードに“Prepared”が書き込まれ、加えて、当該レコードが削除対象であることを示す情報が書き込まれる。具体的には、例えば、各Ｔｘレコードに、カレント情報４５０Ｃ及びプレビアス情報４５０Ｐの各々について、削除対象であるか否かを示す情報の一例である削除フラグ（図示せず）が関連付けられていて（例えばＴｘレコード上に設けられていて）、削除対象のＴｘレコードに関して、削除フラグ“１”（削除対象を意味する値）が書き込まれてよい。これにより、レイジーリカバリ処理において、そのレイジーリカバリ処理の対象のＴｘ（カレントＴｘ又はプレビアスＴｘ）についてのＴｘレコードに関連付けられている削除フラグの値から、当該Ｔｘレコードが削除対象なのか否かを判断することができる。COMMIT STATE RECORD（Ｓ５０７）では、Ｔｘ状態“Committed”が書き込まれる。COMMIT TX RECORD（Ｓ５１３）では、削除対象のＴｘレコード（削除フラグ“１”が関連付けられているＴｘレコード）が削除される。
・Ｓ５０１の読み出しが実行されず、Ｔｘレコードが新規に作成される。この場合、Ｓ５０２がスキップされ、Ｓ５０３の書き込みが実行される。

　図７は、PREPAREの流れを示す。

　Ｔｘマネージャ１１１は、処理対象のＴｘレコードのうち、Ｓ７０１が未処理のＴｘレコードについて、記憶部２０２内のＴｘレコード情報をそのＴｘレコードに書き込むためのライト要求ｗ／ＬＣであって、条件「最新バージョン＝直前バージョン＋１」が関連付けられたライト要求ｗ／ＬＣを、ストレージノード１０５に送信する（Ｓ７０１）。「最新バージョン」とは、直前バージョンの更新後（インクリメント後）のバージョン、具体的には、書込み対象のＴｘレコード情報（例えば、読み出されて更新された後のＴｘレコード情報）におけるバージョンである。「直前バージョン」とは、読み出されたＴｘレコード情報におけるバージョンである。書込み対象のＴｘレコード情報が、新規作成されたＴｘレコード情報の場合、ライト要求ｗ／ＬＣに関連付けられる条件は、「書込み対象のＴｘレコード情報が新規のＴｘレコード情報であれば書き込む」となる。ライト要求ｗ／ＬＣでは、該当Ｔｘレコードに対応したプライマリキーが指定される。コンセンサスマネージャ部３５４は、そのライト要求ｗ／ＬＣに応答して、そのライト要求ｗ／ＬＣに関連付けられている条件が満たされていれば、該当Ｔｘレコードに書込み対象のＴｘレコード情報を書き込む。結果として、レコード状態４１４Ｃが“Committed”から“Prepared”に変わる。ストレージノード１０５（コンセンサスマネージャ３０４）は、そのライト要求ｗ／ＬＣの処理の結果を返す。

　Ｔｘマネージャ１１１は、Ｓ７０１の結果が“Success”か否かを判断する（Ｓ７０２）。ライト要求ｗ／ＬＣに関連付けられている条件が満たされていない、又は、書き込みに失敗した場合、Ｓ７０２の判断結果は偽となる。

　Ｓ７０２の判断結果が真の場合、Ｔｘマネージャ１１１は、処理対象のＴｘレコードにＳ７０１が未処理のＴｘレコードがあるか否かを判断する（Ｓ７０３）。Ｓ７０３の判断結果が真の場合、その未処理のＴｘレコードのために処理がＳ７０１に戻る。Ｓ７０３の判断結果が偽の場合、Ｔｘマネージャ１１１は、結果“Success”を記憶部２０２（例えばワーク領域２０７）に設定する（Ｓ７０４）。

　Ｓ７０２の判断結果が偽の場合、Ｔｘマネージャ１１１は、処理対象のＴｘレコードにＳ７０１が未処理のＴｘレコードがあるか否かに関わらず、結果“Fail”を記憶部２０２（例えばワーク領域２０７）に設定する（Ｓ７０５）。本実施形態では、いわゆるFirst Committer Wins Ruleと類似したルールをPREPAREにおいて用いることにより、カレントＴｘとは別のＴｘが該当Ｔｘレコードを先に書き換えた場合、カレントＴｘが負けたことになり、結果が“Fail”となる。

　図７のPREPAREの流れによれば、下記の通りである。

　すなわち、本実施例では、Ｓ５０１で読み出されたＴｘレコード情報の更新の有無に関わらず、当該Ｔｘレコード情報について、Ｓ５０３の書き込みが実行される（新規作成のＴｘレコード情報についても同様）。

　そして、PREPAREでは、上述したように、First Committer Wins Ruleに類似したルールを採用しており、そのルールを「First Preparer Wins Rule」と呼ぶことができる。First Preparer Wins Ruleでは、他のＴｘ処理により先に書き込み先Ｔｘレコードにレコード状態４１４Ｃ“Prepared”が書き込まれている場合、書き込みが失敗となる。

　本実施例では、Ｔｘレコード情報の更新の有無に関わらずＴｘレコード情報を書き込むことと、上述のFirst Preparer Wins Ruleにより、アイソレーション（アイソレーションレベル：コンフリクトシリアライザブル（以下、シリアライザブル））が担保される。

　図８は、COMMIT STATE RECORDの流れを示す。

　Ｔｘマネージャ１１１は、カレントＴｘのＴｘＩＤ４３１とカレントＴｘに対応したＴｘ状態４３２“Committed”とを状態テーブル３１２に書き込むためのライト要求ｗ／ＬＣをディセントラライズドストレージシステム１０３に送信する（Ｓ８０１）。そのライト要求ｗ／ＬＣでは、ＴｘＩＤ４３１及びＴｘ状態４３２“Committed”が指定される。コンセンサスマネージャ部３５４は、そのライト要求ｗ／ＬＣに応答して、カレントＴｘのＴｘＩＤ４３１とそれに対応したＴｘ状態４３２“Committed”とを状態レコードに書き込む。コンセンサスマネージャ部３５４は、そのライト要求ｗ／ＬＣの処理の結果を返す。

　Ｔｘマネージャ１１１は、Ｓ８０１の結果が“Success”か否かを判断する（Ｓ８０２）。

　Ｓ８０２の判断結果が真の場合、Ｔｘマネージャ１１１は、結果“Success”を記憶部２０２（例えばワーク領域２０７）に設定する（Ｓ８０３）。

　Ｓ８０２の判断結果が偽の場合、Ｔｘマネージャ１１１は、結果“Fail”を記憶部２０２（例えばワーク領域２０７）に設定する（Ｓ８０４）。

　図９は、COMMIT TX RECORDSの流れを示す。

　Ｔｘマネージャ１１１は、処理対象のＴｘレコードのうち、Ｓ９０１が未処理のＴｘレコードについて、カレントＴｘに対応した状態４１４Ｃ“Committed”を書き込むためのライト要求ｗ／ＬＣ（又は、当該Ｔｘレコードの削除のためのライト要求（削除要求）ｗ／ＬＣ）であって、条件「ＴｘＩＤの一致」が関連付けられたライト要求ｗ／ＬＣを、ディセントラライズドストレージシステム１０３に送信する（Ｓ９０１）。「ＴｘＩＤの一致」とは、処理対象のＴｘレコードのカレント情報４５０ＣにおけるＴｘＩＤ４１３Ｃが、このCOMMIT TX RECORDSの対象となっているＴｘのＴｘＩＤと一致することである。ライト要求ｗ／ＬＣでは、該当Ｔｘレコードに対応したプライマリキーが指定される。コンセンサスマネージャ部３５４は、そのライト要求ｗ／ＬＣに応答して、そのライト要求ｗ／ＬＣに関連付けられている条件が満たされていれば、該当Ｔｘレコードにレコード状態４１４Ｃ“Committed”を書き込む（又は該当Ｔｘレコードを削除する）。コンセンサスマネージャ部３５４は、そのライト要求ｗ／ＬＣの処理の結果を返す。

　Ｔｘマネージャ１１１は、Ｓ９０１の結果が“Success”か否かを判断する（Ｓ９０２）。ライト要求ｗ／ＬＣに関連付けられている条件が満たされていない、又は、書き込みに失敗した場合、Ｓ９０２の判断結果は偽となる。Ｓ９０２の判断結果が偽の場合、COMMIT TX RECORDSが終了する。

　Ｓ９０２の判断結果が真の場合、Ｔｘマネージャ１１１は、処理対象のＴｘレコードにＳ９０１が未処理のＴｘレコードがあるか否かを判断する（Ｓ９０３）。Ｓ９０３の判断結果が真の場合、その未処理のＴｘレコードのために処理がＳ９０１に戻る。Ｓ９０３の判断結果が偽の場合、COMMIT TX RECORDSが終了する。

　図１０は、ABORT STATE RECORDの流れを示す。

　Ｔｘマネージャ１１１は、カレントＴｘのＴｘＩＤ４３１とカレントＴｘに対応したＴｘ状態４３２“Aborted”とを状態レコードテーブル３１２に書き込むためのライト要求ｗ／ＬＣをディセントラライズドストレージシステム１０３に送信する（Ｓ１００１）。そのライト要求ｗ／ＬＣでは、ＴｘＩＤ４３１及びＴｘ状態４３２“Aborted”が指定される。コンセンサスマネージャ部３５４は、そのライト要求ｗ／ＬＣに応答して、カレントＴｘのＴｘＩＤ４３１とそれに対応したＴｘ状態４３２“Aborted”とを状態レコードに書き込む。コンセンサスマネージャ部３５４は、そのライト要求ｗ／ＬＣの処理の結果を返す。

　Ｔｘマネージャ１１１は、Ｓ１００１の結果が“Success”か否かを判断する（Ｓ１００２）。

　Ｓ１００２の判断結果が真の場合、Ｔｘマネージャ１１１は、結果“Success”を記憶部２０２（例えばワーク領域２０７）に設定する（Ｓ１００３）。

　Ｓ８０２の判断結果が偽の場合、Ｔｘマネージャ１１１は、結果“Fail”を記憶部２０２（例えばワーク領域２０７）に設定する（Ｓ１００４）。

　図１１は、ABORT TX RECORDSの流れを示す。

　Ｔｘマネージャ１１１は、処理対象のＴｘレコード（Ｓ５０１でのリード元となったＴｘレコード）のうち、Ｓ１１０１が未処理のＴｘレコードについて、そのＴｘレコードのプライマリキーを指定したリード要求ｗ／ＬＣをディセントラライズドストレージシステム１０３に送信する（Ｓ１１０１）。コンセンサスマネージャ部３５４は、そのリード要求ｗ／ＬＣに応答して、最新のＴｘレコードから読み出されたＴｘレコード情報を返す。Ｔｘマネージャ１１１は、そのＴｘレコード情報を記憶部２０２（例えばキャッシュ領域２０６）に格納する。

　Ｔｘマネージャ１１１は、その格納されたＴｘレコード情報中のカレント情報４５０Ｃに、そのＴｘレコード情報中のプレビアス情報４５０Ｐを上書きする（Ｓ１１０２）。結果、そのＴｘレコード情報において、カレント情報４５０Ｃもプレビアス情報４５０Ｐも同じ内容になる。

　Ｔｘマネージャ１１１は、Ｓ１１０２による更新後のＴｘレコード情報をＴｘテーブル３１１に書き込むためのライト要求ｗ／ＬＣであって、条件「ＴｘＩＤの一致」が関連付けられたライト要求ｗ／ＬＣを、ディセントラライズドストレージシステム１０３に送信する（Ｓ１１０３）。「ＴｘＩＤの一致」とは、処理対象のＴｘレコードのカレント情報４５０ＣにおけるＴｘＩＤ４１３Ｃが、このABORT TX RECORDSの対象となっているＴｘのＴｘＩＤと一致することである。ライト要求ｗ／ＬＣでは、該当Ｔｘレコードに対応したプライマリキーが指定される。コンセンサスマネージャ部３５４は、そのライト要求ｗ／ＬＣに応答して、そのライト要求ｗ／ＬＣに関連付けられている条件が満たされていれば、該当Ｔｘレコードに、そのライト要求ｗ／ＬＣで指定されたＴｘレコード情報を書き込む。コンセンサスマネージャ部３５４は、そのライト要求ｗ／ＬＣの処理の結果を返す。

　Ｔｘマネージャ１１１は、Ｓ１１０３の結果が“Success”か否かを判断する（Ｓ１１０４）。ライト要求ｗ／ＬＣに関連付けられている条件が満たされていない、又は、書き込みに失敗した場合、Ｓ１１０４の判断結果は偽となる。Ｓ１１０４の判断結果が偽の場合、ABORT TX RECORDSが終了する。

　Ｓ１１０４の判断結果が真の場合、Ｔｘマネージャ１１１は、処理対象のＴｘレコードにＳ１１０１が未処理のＴｘレコードがあるか否かを判断する（Ｓ１１０５）。Ｓ１１０５の判断結果が真の場合、その未処理のＴｘレコードのために処理がＳ１１０１に戻る。Ｓ１１０５の判断結果が偽の場合、ABORT TX RECORDSが終了する。

　図１２は、RECOVERの流れを示す。図１２の説明において、「対象Ｔｘ」は、図５のＳ５１１に関しては「カレントＴｘ」であり、図５のＳ５２１に関しては「プレビアスＴｘ」である。

　Ｔｘマネージャ１１１は、対象Ｔｘに対応した状態４３２を状態テーブル３１２から読み出すためのリード要求ｗ／ＬＣをディセントラライズドストレージシステム１０３に送信する（Ｓ１２０１）。そのリード要求ｗ／ＬＣでは、処理対象のＴｘのＴｘＩＤ４３１が指定される。コンセンサスマネージャ部３５４は、そのリード要求ｗ／ＬＣに応答して、対象ＴｘのＴｘＩＤ４３１に対応したＴｘ状態４３２を状態レコードから読み出し、その状態４３２を返す。

　Ｔｘ状態４３２が“Committed”の場合、Ｔｘマネージャ１１１は、結果“Committed”を、記憶部２０２（例えばワーク領域２０７）に設定する（Ｓ１２０３）。

　Ｔｘ状態４３２が“Aborted”の場合、Ｔｘマネージャ１１１は、結果“Aborted”を、記憶部２０２（例えばワーク領域２０７）に設定する（Ｓ１２０４）。

　Ｔｘ状態４３２が“Unknown”の場合（典型的には、対象ＴｘのＴｘＩＤに一致するＴｘＩＤを有する状態レコードが存在しない場合）、Ｔｘマネージャ１１１は、リトライ終了条件が満たされたか否か、例えば所定の時間が経過したか否かを判断する（Ｓ１２０５）。

　Ｓ１２０５の判断結果が真の場合、Ｔｘマネージャ１１１は、対象ＴｘのＴｘＩＤ４３１と対象Ｔｘに対応した状態４３２“Aborted”とを状態テーブル３１２に書き込むためのライト要求ｗ／ＬＣを発行するABORT STATE RECORDを実行する（Ｓ１２０６）。

　Ｓ１２０５の判断結果が偽の場合、Ｔｘマネージャ１１１は、Ｓ１２０１のリトライを実行するか否かを判断する（Ｓ１２０７）。Ｓ１２０７の判断結果が真の場合、Ｓ１２０１が再度実行される。Ｓ１２０７の判断結果が偽の場合、Ｔｘマネージャ１１１は、結果“Unknown”を、記憶部２０２（例えばワーク領域２０７）に設定する（Ｓ１２０６）。

　以上が、実施例１についての説明である。

　以下、実施例１を総括する。なお、下記の記述は、上述の説明に無い事項を含んでいてもよい。

　Ｔｘ処理では、典型的には、２以上のレコードに対してＡＣＩＤ性を保証しつつＣＲＵＤ要求を実行する必要がある。このため、テーブルを格納するストレージシステムとして、マスター／スレーブ型のトランザクションシステムが採用されることが一般的である。リアルタイムに情報共有（同期）が実行され、２以上のレコードに対してＡＣＩＤ性を保証しつつＣＲＵＤ要求を実行することの実現が容易であるためである。

　しかし、マスター／スレーブ型のトランザクションシステムでは、上述したように、実現できるアプリケーションの範囲が必ずしも広くなく、且つ、アベーラビリティ及びスケーラビリティは必ずしも高くない。

　そこで、特定のノードに依らずＴｘ処理を行うディセントラライズドなトランザクションシステムが考えられる。マスターが存在しない（全員がマスターであると考えることもできる）ため、トランザクションシステムを利用するアプリケーションの範囲が広がること、及び、高いアベーラビリティと高いスケーラビリティが期待できるためである。

　このようなトランザクションシステムでは、リニアライザブルコンセンサスを実現する既存のディセントラライズドストレージシステム１０３を利用することが考えられる。

　しかし、リニアライザブルコンセンサスでは、ＣＲＵＤのいずれも特定の条件の下でアトミックに実行することが、１つの（論理的な）レコードについて保証されているものの、２以上のレコードについては保証されていない。

　このような理由から、２以上のレコードに対してＡＣＩＤ性を保証しつつＣＲＵＤ要求を実行するディセントラライズドなトランザクションシステムを実現することは困難である。

　そこで、本実施例では、クライアント計算機において実現される新しいＴｘ管理機構（Ｔｘマネージャ１１１）を用いることにより、既存のディセントラライズドストレージシステム１０３を利用したディセントラライズドトランザクションシステム、すなわち、２以上のレコードに対してＡＣＩＤ性を保証しつつＣＲＵＤ要求を実行するディセントラライズドトランザクションシステムが実現される。

　Ａ（Atomicity）は、Ｔｘマネージャ１１１により担保される。すなわち、ディセントラライズドストレージシステム１０３に、Ｔｘの対象となるＴｘテーブル３１１に加えて、Ｔｘの状態を管理するためのテーブルである状態テーブル３１２が格納され、クライアント計算機１０１で、クライアントコーディネーテッドな処理の実現ためのＴｘマネージャ１１１が実行される。コミット処理又はアボート処理が２段階で実行される。具体的には、Ｔｘマネージャ１１１は、カレントＴｘの対象のうち更新が必要とされる各ＴｘレコードにカレントＴｘのレコード状態４１４Ｃ“Prepared”を書き込む。その後、Ｔｘマネージャ１１１は、１段階目の更新として、カレントＴｘそれ自体の結果（Ｔｘ状態“Committed”又は“Aborted”）を状態レコードに書き込み（図５のＳ５０７又はＳ５０９）、その後に、２段階目の更新として、カレントＴｘの対象のうち更新が必要とされる各Ｔｘレコードを更新する。リニアライザブルコンセンサスの下でリニアライザブル（アトミック）に更新されることが保証されるレコード数は１である。このため、本実施例では、１段階目で、Ｔｘそれ自体の結果を１つのレコード（状態レコード）に書き込み、２段階目で、そのＴｘの更新対象のレコード（Ｔｘレコード）が１つずつ更新されるようになっている。

　なお、２以上のレコードのうちの一部のレコードしか更新に成功しないことがあり得るが、リニアライザブルな書き込みの失敗をリアルタイムに検知すること（別の言い方をすれば、書き込みが失敗なのか遅いのかを区別すること）は困難である。そこで、本実施例では、２以上のレコードのうちの一部のレコードしか更新に成功しなかったという不整合をＴｘ　ＡＰＰ２０４に見せないために、レイジーリカバリ処理（プレビアスＴｘが未確定であることが検知された場合に走るＳ５２１、Ｓ５２２、Ｓ５２３（又はＳ５２４）から成る処理）が実行される。

　Ｉ（Isolation）も、Ｔｘマネージャ１１１により担保される。すなわち、First Preparer Wins Ruleにより、アイソレーションが担保される。なお、本実施例では、Ｔｘレコード情報の更新の有無に関わらずＴｘレコード情報が書き込まれるようになっている。これにより、アイソレーションレベルとしてシリアライザブルが担保される。

　Ｃ（Consistency）は、Ｔｘ　ＡＰＰ２０４により担保される。トランザクションシステム（Ｔｘマネージャ１１１及びディセントラライズドストレージシステム１０３）により最新の確定的な値が得られることが保証されるので、Ｔｘ　ＡＰＰ２０４がＣ（Consistency）を担保できるようになっている。

　Ｄ（Durability）は、ディセントラライズドストレージシステム１０３により担保される。“Durability”は、書き込まれたレコードは永続化される（消えない）という性質であり、Ｔｘマネージャ１１１は、ストレージシステム１０３側でそのような性質を有することが前提とされている。

　実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略又は簡略する。

　実施例１では、Ｔｘマネージャ１１１により実現されるアイソレーションレベルは、シリアライザブルである。すなわち、実施例１では、Ｔｘマネージャ１１１は、読み出されたＴｘレコード情報の更新の有無に関わらず、Ｔｘレコード情報をＴｘテーブル３１１に書き込む（新規作成のＴｘレコード情報についても同様）。

　実施例２では、Ｔｘマネージャ１１１により実現されるアイソレーションレベルは、スナップショットアイソレーションである。すなわち、実施例２では、Ｔｘマネージャ１１１は、読み出されたＴｘレコード情報が更新された場合には、Ｔｘレコード情報をＴｘテーブル３１１に書き込むが（新規作成のＴｘレコード情報についても同様）、読み出されたＴｘレコード情報が更新されていない場合には、Ｔｘレコード情報をＴｘテーブル３１１に書き込まない。

　従って、実施例２では、例えば、Ｔｘ処理の一部が、実施例１と相違する。すなわち、図１３に示すように、Ｔｘ処理において、Ｔｘマネージャ１１１は、Ｓ５０２の判断結果が偽の場合、Ｔｘレコード情報の書き込みの必要があるか否かを判断する（Ｓ１３０１）。「書き込みの必要がある」とは、読み出されたＴｘレコード情報が更新（又は削除）された、又は、Ｔｘレコード情報が新規作成された、である。Ｓ１３０１の判断結果が真の場合（つまり「書き込みの必要がある」場合）、Ｓ５０３の書き込みが実行される。Ｓ１３０１の判断結果が偽の場合、Ｓ５０３がスキップされる。少なくとも１つのＴｘレコードについての書き込みが実行された場合（Ｓ１３０２：Ｙｅｓ）、Ｓ５０５（PREPARE）が実行される。いずれのＴｘレコードについても書き込みが実行されなかった場合（Ｓ１３０２：Ｎｏ）、Ｔｘ処理が終了する。

　また、実施例２では、例えば、PREPAREの一部が、実施例１と相違する。すなわち、図１４に示すように、PREPAREにおいて、Ｔｘマネージャ１１１は、Ｔｘレコードについて、書き込みの必要があるか否かを判断する（Ｓ１４０１）。「書き込みの必要がある」とは、当該Ｔｘレコードが、更新後の（又は削除対象の）Ｔｘレコード、又は、新規作成されたＴｘレコードである。Ｓ１４０１の判断結果が真の場合に、Ｓ７０１が実行される。また、Ｓ７０３の判断結果が偽の場合の戻り先が、Ｓ７０１に代えてＳ１４０１とされる。

　以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。例えば、本発明は、データベースに対するＴｘ以外のＴｘ（例えば、１以上のファイルのような１以上のオブジェクトに対するＴｘ）にも適用することができる。

１０１…クライアント計算機　１０３…ディセントラライズドストレージシステム　１０５…ストレージノード　１１１…Ｔｘマネージャ

Claims (17)

1. 　（Ａ）ＣＲＵＤ（Create、Read、Update又はDelete）のいずれも特定の条件の下でアトミックに実行することが１つのオブジェクトについて保証されるリニアライザブルコンセンサスを実現するディセントラライズドストレージシステムに対し、前記ディセントラライズドストレージシステムが管理している状態情報及びトランザクション（Ｔｘ）情報のうちの状態情報が有する状態オブジェクトに処理対象のＴｘであるカレントＴｘの状態を書き込むためのライト要求を送信し、
   　　前記Ｔｘ情報は、１以上のＴｘオブジェクトで構成され、
   　　各Ｔｘオブジェクトは、Ｔｘ処理におけるＣＲＵＤ要求の対象となり得るオブジェクトであり、
   　　前記状態情報は、１以上の状態オブジェクトで構成され、
   　　各状態オブジェクトは、Ｔｘに対応しており、当該Ｔｘの状態を格納したオブジェクトであり、
   　（Ｂ）前記カレントＴｘの対象のうち、少なくとも、ＣＵＤ（Create、Update又はDelete）が必要とされる各Ｔｘオブジェクトについて、（Ａ）のライト要求に従う状態に応じたライト要求を、前記ディセントラライズドストレージシステムに対して送信する、
   ことを計算機に実行させるコンピュータプログラム。
2. 　（Ｅ）前記カレントＴｘの対象のうち、少なくとも、ＣＵＤが必要とされる各Ｔｘオブジェクトについて、そのＴｘオブジェクトについて未確定を意味する状態であるPreparedを含んだ情報を書き込むためのライト要求を、前記ディセントラライズドストレージシステムに対して送信する、
   ことを更に計算機に実行させ、
   　（Ａ）でのライト要求に従い書き込まれる状態は、（Ｅ）の結果に応じた状態であり、
   　前記カレントＴｘの対象のうち、少なくとも、ＣＵＤが必要とされる各Ｔｘオブジェクトについて、（Ｂ）でのライト要求は、確定を意味する状態であるCommittedを書き込むためのライト要求である、
   請求項１記載のコンピュータプログラム。
3. 　（Ｆ）前記カレントＴｘの対象のうち、少なくとも、読出しが必要とされるＴｘオブジェクトについて、そのＴｘオブジェクトについての最新の状態を含む情報である対象情報を読み出すためのリード要求を、前記ディセントラライズドストレージシステムに対して送信し、
   　（Ｇ）（Ｆ）でのリード要求に従い読み出された対象情報に含まれる状態がPreparedか否かを判断し、
   　（Ｇ）の判断結果が偽の場合、（Ｅ）を実行する、
   ことを計算機に実行させる請求項２記載のコンピュータプログラム。
4. 　（Ｇ）の判断結果が真の場合、前記対象情報から特定されたＴｘであるプレビアスＴｘについてのリカバリ処理を前記計算機に実行させ、
   　（Ｐ）前記プレビアスＴｘについてのリカバリ処理は、
   　　（ｐ１）前記プレビアスＴｘに対応した状態オブジェクトについて、その状態オブジェクトに書き込まれている状態を読み出すためのリード要求を、前記ディセントラライズドストレージシステムに対して送信すること、
   　　（ｐ２）前記プレビアスＴｘに対応した各Ｔｘオブジェクトについて、（ｐ１）のリード要求に従い読み出された状態に応じた更新のためのライト要求を、前記ディセントラライズドストレージシステムに対して送信すること、
   を含む、
   請求項３記載のコンピュータプログラム。
5. 　（ｐ１）のリード要求に従い読み出された状態が、確定を意味する状態であるCommittedの場合、前記プレビアスＴｘに対応した各Ｔｘオブジェクトについて、（ｐ２）でのライト要求は、確定を意味する状態であるCommittedを書き込むためのライト要求である、
   請求項４記載のコンピュータプログラム。
6. 　（ｐ１）のリード要求に従い読み出された状態が、失敗を意味する状態であるAbortedの場合、前記プレビアスＴｘに対応した各Ｔｘオブジェクトについて、（ｐ２）でのライト要求は、そのＴｘオブジェクトにおける最新の情報を１つ前の情報に戻すためのライト要求である、
   請求項４又は５記載のコンピュータプログラム。
7. 　確定を意味する状態であるCommitted又は失敗を意味する状態であるAbortedを示す状態が読み出されるまで所定時間（ｐ１）が繰り返されても、Committed又はAbortedを示す状態が読み出されない場合、
   　　前記プレビアスＴｘに対応した状態オブジェクトについて、失敗を意味する状態であるAbortedを書き込むためのライト要求を、前記ディセントラライズドストレージシステムに対して送信することを、前記計算機に実行させ、
   　　前記プレビアスＴｘに対応した各Ｔｘオブジェクトについて、（ｐ２）でのライト要求は、そのＴｘオブジェクトにおける最新の情報を１つ前の情報に戻すためのライト要求である、
   請求項４乃至６のうちのいずれか１項に記載のコンピュータプログラム。
8. 　（Ｅ）に関するルールは、先にPreparedを書き込むことができた場合に勝ちとなるルールである、
   請求項２乃至７のうちのいずれか１項に記載のコンピュータプログラム。
9. 　（Ｅ）に関するルールが、下記（ｅ１）及び（ｅ２）のいずれかのルールである、
   　　（ｅ１）リード要求に従うリード元のＴｘオブジェクトから読み出された情報が更新されたか否かに関わらず、当該Ｔｘオブジェクトに対して書込みを行う、
   　　（ｅ２）リード要求に従うリード元のＴｘオブジェクトから読み出された情報が更新されていない場合を除き、当該Ｔｘオブジェクトに対して書込みを行う、
   請求項２乃至８のうちのいずれか１項に記載のコンピュータプログラム。
10. 　（Ｅ）が成功の場合、
    　　（Ａ）でのライト要求に従い書き込まれる状態が、確定を意味する状態であるCommittedであり、
    　　前記カレントＴｘの対象のうち、少なくとも、ＣＵＤが必要とされる各Ｔｘオブジェクトについて、（Ｂ）でのライト要求は、最新の状態として、Preparedを、確定を意味する状態であるCommittedに更新するためのライト要求である、
    請求項２乃至９のうちのいずれか１項に記載のコンピュータプログラム。
11. 　（Ｅ）が失敗の場合、
    　　（Ａ）でのライト要求に従い書き込まれる状態が、失敗を意味する状態であるAbortedであり、
    　　前記カレントＴｘの対象のうち、少なくとも、ＣＵＤが必要とされる各Ｔｘオブジェクトについて、（Ｂ）でのライト要求は、そのオブジェクトにおける最新の情報を１つ前の情報に戻すためのライト要求である、
    請求項２乃至１０のうちのいずれか１項に記載のコンピュータプログラム。
12. 　（Ａ）が失敗の場合、前記カレントＴｘについてのリカバリ処理を前記計算機に実行させ、
    　（Ｃ）前記カレントＴｘについてのリカバリ処理は、
    　　（ｃ１）前記カレントＴｘに対応した状態オブジェクトについて、その状態オブジェクトに書き込まれている状態を読み出すためのリード要求を、前記ディセントラライズドストレージシステムに対して送信すること、
    　　（ｃ２）前記カレントＴｘの対象の各Ｔｘオブジェクトについて、（ｃ１）のリード要求に従い読み出された状態に応じた更新のためのライト要求を、前記ディセントラライズドストレージシステムに対して送信すること、
    を含む、
    請求項１乃至１１のうちのいずれか１項に記載のコンピュータプログラム。
13. 　（ｃ１）のリード要求に従い読み出された状態が、確定を意味する状態であるCommittedの場合、前記カレントＴｘの対象の各Ｔｘオブジェクトについて、（ｃ２）でのライト要求は、確定を意味する状態であるCommittedを書き込むためのライト要求である、
    請求項１２記載のコンピュータプログラム。
14. 　（ｃ１）でのリード要求に従い読み出された状態が、失敗を意味する状態であるAbortedの場合、前記カレントＴｘの対象の各Ｔｘオブジェクトについて、（ｃ２）でのライト要求は、そのＴｘオブジェクトにおける最新の情報を１つ前の情報に戻すためのライト要求である、
    請求項１２又は１３記載のコンピュータプログラム。
15. 　確定を意味する状態であるCommitted又は失敗を意味する状態であるAbortedを示す状態が読み出されるまで所定時間（ｃ１）が繰り返されても、Committed又はAbortedを示す状態が読み出されない場合、
    　　前記カレントＴｘに対応した状態オブジェクトについて、失敗を意味する状態であるAbortedを書き込むためのライト要求を、前記ディセントラライズドストレージシステムに対して送信することを、前記計算機に実行させ、
    　　前記カレントＴｘの対象の各Ｔｘオブジェクトについて、（ｃ２）でのライト要求は、そのＴｘオブジェクトにおける最新の情報を１つ前の情報に戻すためのライト要求である、
    請求項１２乃至１４のうちのいずれか１項に記載のコンピュータプログラム。
16. 　ＣＲＵＤ（Create、Read、Update又はDelete）のいずれも特定の条件の下でアトミックに実行することが１つのオブジェクトについて保証されるリニアライザブルコンセンサスを実現するディセントラライズドストレージシステムに対し、前記ディセントラライズドストレージシステムが管理している状態情報及びＴｘ情報のうちの状態情報が有する状態オブジェクトに処理対象のＴｘであるカレントＴｘの状態を書き込むためのライト要求を送信する第１の手段と、
    　　前記Ｔｘ情報は、１以上のＴｘオブジェクトで構成され、
    　　各Ｔｘオブジェクトは、Ｔｘ処理におけるＣＲＵＤ要求の対象となり得るオブジェクトであり、
    　　前記状態情報は、１以上の状態オブジェクトで構成され、
    　　各状態オブジェクトは、Ｔｘに対応しており、当該Ｔｘの状態を格納したオブジェクトであり、
    　前記カレントＴｘの対象のうち、少なくとも、ＣＵＤ（Create、Update又はDelete）が必要とされる各Ｔｘオブジェクトについて、前記第１の手段によるライト要求に従う状態に応じたライト要求を、前記ディセントラライズドストレージシステムに対して送信する第２の手段と
    を備える計算機。
17. 　（Ａ）ＣＲＵＤ（Create、Read、Update又はDelete）のいずれも特定の条件の下でアトミックに実行することが１つのオブジェクトについて保証されるリニアライザブルコンセンサスを実現するディセントラライズドストレージシステムに対し、前記ディセントラライズドストレージシステムが管理している状態情報及びトランザクション（Ｔｘ）情報のうちの状態情報が有する状態オブジェクトに処理対象のＴｘであるカレントＴｘの状態を書き込むためのライト要求を送信するステップと、
    　　前記Ｔｘ情報は、１以上のＴｘオブジェクトで構成され、
    　　各Ｔｘオブジェクトは、Ｔｘ処理におけるＣＲＵＤ要求の対象となり得るオブジェクトであり、
    　　前記状態情報は、１以上の状態オブジェクトで構成され、
    　　各状態オブジェクトは、Ｔｘに対応しており、当該Ｔｘの状態を格納したオブジェクトであり、
    　（Ｂ）前記カレントＴｘの対象のうち、少なくとも、ＣＵＤ（Create、Update又はDelete）が必要とされる各Ｔｘオブジェクトについて、（Ａ）のライト要求に従う状態に応じたライト要求を、前記ディセントラライズドストレージシステムに対して送信するステップと
    を有するトランザクション処理方法。

Images