JP2022115672A - 多重系処理システム及び多重系処理システムの制御方法 - Google Patents

Abstract

【課題】アクセス対象のデータのバージョンを事前に一括してノード間で合意を形成することで同期に要する遅延を削減する。【解決手段】プロセッサとメモリと通信装置を含むノードを複数有し、前記複数のノードをネットワークを介して接続し、前記複数のノードが入力に対して一意の出力を行う１以上のタスクをそれぞれ実行する多重系処理システムであって、前記ノードは、イベントを受け付けて、前記イベントに対応する前記タスクを実行するトランザクションを開始するタスク実行制御部と、前記タスクがアクセスするデータベースのデータのバージョンを管理するステート管理部と、を有し、前記タスク実行制御部は、前記タスクの処理を開始する以前に、前記データベースで前記タスクが参照するデータのバージョン又は前記タスクが更新するデータのバージョンを一括して前記ノード間で合意を形成することを特徴とする多重系処理システム。【選択図】図２１

Description

本発明は、フォールトトレラントシステムの技術を適用する多重系処理システムに関する。

多重化された計算機（ノード）間で同じ処理を実施し、いずれかの計算機に障害が発生しても無停止で業務を継続可能とするフォールトトレラントシステム（ｆａｕｌｔ－ｔｏｌｅｒａｎｔ ｓｙｓｔｅｍ）が知られている。

また、多重化の一例としては、ステートマシンレプリケーション（Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｒｅｐｌｉｃａｔｉｏｎ）が知られている。ステートマシンレプリケーションは、各複製ノードに対して同じ入力に対して決定性の処理を行うことで、同じ出力をして同じステートを維持し、ノードに障害が発生した場合にシームレスな主従系交替を実現する。

複数のタスクを並列実行する構成のアプリケーションの場合、各タスクへの入力内容をノード間で一致化させることで、全体としての決定性を保証する技術として、例えば、特許文献１が知られている。特許文献１は、共有データへのアクセスを行う際、リーダ－フォロワ型の合意形成プロトコルによってアクセス順を決定して処理を実行することで、複製ノード間での決定性を保証する。

国際公開第２０１２／１２７６５２号

上記特許文献１では、タスク間の共有データ（＝ステート）へのアクセスの順序を、アクセスの都度、ノード間で一致化することで決定性を保証している。すなわち、特許文献１では、タスク間で共有されるデータへのアクセス要求が発生する都度、リーダノードとフォロワノード間で通信が発生するため、ワークロードによっては同期のための負荷が増大する恐れがあった。

そこで本発明は、上記問題点に鑑みてなされたもので、アクセス対象の共有データのバージョンを事前に一括してノード間で合意を形成することで同期に要する遅延を削減することを目的とする。

本発明は、プロセッサとメモリと通信装置を含むノードを複数有し、前記複数のノードをネットワークを介して接続し、前記複数のノードが入力に対して一意の出力を行う１以上のタスクをそれぞれ実行する多重系処理システムであって、前記ノードは、イベントを受け付けて、前記イベントに対応する前記タスクを実行するトランザクションを開始するタスク実行制御部と、前記タスクがアクセスするデータベースのデータのバージョンを管理するステート管理部と、を有し、前記タスク実行制御部は、前記タスクの処理を開始する以前に、前記データベースで前記タスクが参照するデータのバージョン又は前記タスクが更新するデータのバージョンを一括して前記ノード間で合意を形成することを特徴とする多重系処理システム。

したがって、本発明は、同時に複数のバージョンのデータ（ステート）を管理し、アクセス対象のデータのバージョンを事前に一括してノード間で合意を形成することで同期に要する遅延を削減することができる。そして、各ノードをリーダ－フォロワ方式で構成することで、リーダノードは合意形成前にタスクの実行を開始し、フォロワノードは合意形成の後にタスクの実行を開始することで、少なくともリーダノードは合意形成待ちによる遅延を回避することが可能となる。

本明細書において開示される主題の、少なくとも１つの実施の詳細は、添付されている図面と以下の記述の中で述べられる。開示される主題のその他の特徴、態様、効果は、以下の開示、図面、請求項により明らかにされる。

本発明の実施例１を示し、多重系の計算機システムの一例を示すブロック図である。 本発明の実施例１を示し、ノードの一例を示すブロック図である。 本発明の実施例１を示し、ノードで行われる処理の一例を示すフローチャートである。 本発明の実施例１を示し、タスクの一例を示す図である。 本発明の実施例１を示し、ノードで行われる受信処理の一例を示す図である。 本発明の実施例１を示し、メッセージのヘッダの一例を示す図である。 本発明の実施例１を示し、ステート管理部の機能の一例を示す図である。 本発明の実施例１を示し、データベース管理テーブルの一例を示す図である。 本発明の実施例１を示し、テーブル管理テーブルの一例を示す図である。 本発明の実施例１を示し、データベースのテーブルの一例を示す図である。 本発明の実施例１を示し、リードオンリのトランザクションの開始処理の一例を示すフローチャートである。 本発明の実施例１を示し、ハンドルの一例を示す図である。 本発明の実施例１を示し、指定されたテーブルへのリードオンリのトランザクションの開始要求の一例を示すフローチャートである。 本発明の実施例１を示し、リードオンリのトランザクションの終了要求の一例を示すフローチャートである。 本発明の実施例１を示し、リードライトのトランザクションの開始要求の一例を示すフローチャートである。 本発明の実施例１を示し、ハンドルの一例を示す図である。 本発明の実施例１を示し、リードライトのトランザクションの終了要求の一例を示すフローチャートである。 本発明の実施例１を示し、ノード間で行われる合意形成の一例を示す図である。 本発明の実施例１を示し、タスクの初期化処理の一例を示すシーケンス図である。 本発明の実施例１を示し、タスク管理テーブルの一例を示す図である。 本発明の実施例１を示し、タスク処理の一例を示すシーケンス図である。 本発明の実施例１を示し、イベント登録処理の一例を示すフローチャートである。 本発明の実施例１を示し、イベント管理キューの一例を示す図である。 本発明の実施例１を示し、リーダノードで行われるトランザクション開始処理の一例を示すフローチャートである。 本発明の実施例１を示し、フォロワノードで行われるトランザクション開始処理の一例を示すフローチャートである。 本発明の実施例１を示し、送信処理の一例を示す図である。 本発明の実施例２を示し、ステート管理部で行われる処理の一例を示すフローチャートである。 本発明の実施例２を示し、ハンドルの一例を示す図である。

以下、本発明の実施形態を添付図面に基づいて説明する。

図１は、本発明の実施例１を示し、多重系処理システムの一例を示すブロック図である。図示の例では、３つのノード１－１～１－３がリーダ－フォロワ型で構成されて、リーダノード１－１の複製をフォロワノード１－２～１－３とした多重系処理システムを示す。

なお、以下の説明では、ノードの説明の際に、リーダノードとフォロワノードを区別しない場合には、「－」以降を省略した符号「１」を用いる。なお、他の構成要素の符号が「－」を含む場合も同様である。

各クライアントアプリケーション２は同一のクライアント計算機４上で動作するプロクシ３と接続し、プロクシ３はネットワーク５を介して各ノード1に接続する。

本実施例の多重系の計算機システムは、多重化されたノード１－１～１－３それぞれの上で複製された同一状態のサーバアプリケーション２０（図２参照）が動作する。クライアントアプリケーション２はサーバアプリケーション２０宛てのリクエストメッセージ３００をプロクシ３に送信し、プロクシ３はこれを複製して各ノード１に配信する。各ノード１上で動作するサーバアプリケーション２０はそれぞれ同一の処理を実施し、その処理結果をプロクシ３を経由してクライアントアプリケーション２へ応答する。プロクシ３は各クライアントアプリケーション２と同じクライアント計算機４上で動作する。このためプロクシ３が単一障害点となることはない。

本実施例の多重系の概要は次の通りである。まず、クライアントアプリケーション２が各ノード１上に複製されたサーバアプリケーション宛てのリクエストメッセージを送信し、仲介役のプロクシ３が一旦これを受信する（Ｓ１）。プロクシ３は、クライアントアプリケーション２から受信したリクエストメッセージを複製し、各ノード１へ配信する（Ｓ２）。

リーダノード１－１は、フォロワノード１－２、１－３との間で、各ノード上で動作するサーバアプリケーションが決定性の振る舞いをするよう、合意を形成する（Ｓ３）。なお、各ノード１間の合意の形成には、ＲＡＦＴ等の周知又は公知の分散合意アルゴリズムを採用すればよいので、本実施例では詳述しない。

各ノード１上のサーバアプリケーションは、前述の合意結果に基づき決定性の振る舞いにてクライアントアプリケーション２からのリクエストメッセージを処理し、結果をプロクシ３へ応答する（Ｓ４）。

プロクシ３は、予め設定したポリシー（多数決等）に基づいて、各ノード１からの処理結果を１つ選択してクライアントアプリケーション２へ応答する（Ｓ５）。

本実施例では、クライアントアプリケーション２と多重化されたノード１は、いずれかのノード１に障害が発生しても、アクセス要求や処理結果を紛失することなく処理を続行することができる。

本実施例のノード１は、後述するように、同時に複数のバージョンのステート（共有データ＝データベース１００）をＭＶＣＣ（ＭｕｌｔｉＶｅｒｓｉｏｎ Ｃｏｎｃｕｒｒｅｎｃｙ Ｃｏｎｔｒｏｌ）方式で管理し、アクセス対象のデータのバージョンを事前に一括してノード１間で合意を形成することで同期に要する負荷を削減することができる。

＜ノードの構成＞
図２は、ノード１の一例を示すブロック図である。リーダノード１－１とフォロワノード１－２、１－３は同様の構成であるので、以下ノード１として説明する。

ノード１は、プロセッサ１１と、メモリ１２と、通信インタフェース（又は通信装置）１３を含む計算機である。通信インタフェース１３は、ネットワーク５に接続されて、クライアント計算機４や他のノード１と通信を行う。

メモリ１２には、サーバアプリケーション２０と、多重化処理部３０がロードされてプロセッサ１１によって実行される。また、メモリ１２には、後述するタスク群２１から共有される共有メモリ９０が設定されて、共有メモリ９０内にサーバアプリケーション２０のステートを格納するデータベース１００を配置する。また、データベース１００は前記ステートの他、データベース管理テーブル２００と、テーブル管理テーブル２１０－１～２１０－３も保持し、ステート管理部６０によって利用される。

また、メモリ１２は、タスク管理テーブル２２０を格納し、多重化処理部３０によって利用される。

本実施例では、ノード１の共有メモリ９０に格納されたデータベース１００に対してそれぞれの多重化処理部３０がアクセスする例を示すが、これに限定されるものではない。例えば、各ノード１からアクセス可能なストレージ装置（図示省略）にデータベース１００を格納してもよい。

サーバアプリケーション２０は、１以上のタスク２１－Ａ～２１－Ｎで構成することができる。各タスク２１は、プロクシ３から受信したメッセージを入力として、ステート管理部６０が管理するデータベース１００に格納されたステート（共有データ）に基づいて、決定性の処理（ステートの更新や外部への送信）を行う。

多重化処理部３０は、外部通信部４０と、タスク実行制御部５０と、ステート管理部６０と、ノード間通信部７０と、イベント管理キュー８０を含む。外部通信部４０と、タスク実行制御部５０と、ステート管理部６０と、ノード間通信部７０の各機能部はプログラムとしてメモリ１２にロードされる。

プロセッサ１１は、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、プロセッサ１１は、タスク実行制御グラムに従って処理を実行することでタスク実行制御部５０として機能する。他のプログラムについても同様である。さらに、プロセッサ１１は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

外部通信部４０は、プロクシ３を介してクライアント計算機４からメッセージ（サーバアプリケーション２０に対するサービスリクエスト）を受け付けてタスク実行制御部５０に通知し、また、各タスク２１の処理結果をプロクシ３を介してクライアントアプリケーション２へ応答する。

タスク実行制御部５０は、イベント（タイマイベントやメッセージの受信等）の管理と、イベントに基づくタスク２１の駆動を行う。このタスク２１の駆動に際し、タスク実行制御部５０はステート管理部６０を通し、当該タスクがアクセスするステートのトランザクションの制御を行う。また、タスク実行制御部５０は、ノード間通信部７０を使用して、１つのイベントの処理順序（アクセス対象のデータのバージョン）についてノード１間で一括して合意を形成する。

ステート管理部６０は、ステートフルなサーバアプリケーション２０のステートをバージョン毎に管理する。ステートのバージョンはトランザクション番号として表現され、トランザクションを開始する毎に１ずつ加算されていく。

ノード間通信部７０は、ノード１間で合意形成プロトコルを実行する。イベント管理キュー８０は、タスク２１を駆動させるイベントを順に保持する。イベント管理キュー８０は、例えば、ＦＩＦＯで構成することができる。

メモリ１２に格納されたデータベース管理テーブル２００は、コミット済みのトランザクションの番号、及び最後に開始したトランザクションの番号を保持し、ステート管理部６０によって管理される。データベース１００は一つ以上のテーブルを持つことができる。テーブル管理テーブル２１０－１～２１０－３は、データベース１００内のテーブル単位でトランザクションの状態を管理する。これらはステート管理部６０によって管理される。

タスク管理テーブル２２０は、タスク実行制御部５０によって管理され、タスク毎に駆動の契機となるイベントと、当該タスクが更新対象とするテーブル名を管理する。

＜タスクのモデル＞
図３は、ノード１上で動作するタスク２１の振る舞いの一例を示すフローチャートである。本実施例のサーバアプリケーション２０は一つ以上のイベント駆動型タスク２１から構成される。各タスク２１は起動後、まずリソースの確保などの初期化を実施する（Ｓ６）。

次に各タスク２１は、イベントを待つ（Ｓ７）。イベントは、タイマイベントやメッセージの受信や所定の条件の成立などであり、予め設定されたものである。タスク２１は、イベントを受け付けると、入力（クライアントアプリケーション２から受信したリクエストメッセージや、データベース１００上のステート、等）に対して一意の処理を実行して、一意の処理結果を出力する（Ｓ８）。すなわちタスク２１は、処理結果を送信メッセージとして出力したり、データベース１００のステートの更新を実施したりする。

そして、タスク２１は、１つのイベントに対する処理が完了すると、ステップＳ７のイベント待ちに戻って、上記処理を繰り返す。なお、本実施例では、更新対象のステート（データ）はタスク２１毎に固有とし、複数のタスク２１から同じステートが更新されることはないものとする。したがって、特定のステートを更新するタスク２１は１つのみとなり、更新の競合は発生しない。参照については他のタスクからも可能とする。

図４は、タスク２１のイベント駆動パターンの一例を示す図である。タスクＡ（２１－Ａ）は、自身による周期タイマイベントによって駆動される。タイマイベントの情報には、対象タスクＩＤと、周期や起床時刻などを設定することができる。タスクＡ（２１－Ａ）は、１００ｍｓ毎に繰り返して実行する。

イベントがタイマ駆動のタスク２１－Aについては、タイマが起動してからタイマが作動（カウントアップ）する前に、予めアクセス対象のステートのバージョンについて一括してノード１間で合意を形成することができる。これにより、フォロワノード１－２、１－３も含めて合意形成待ちによる処理の遅延と周期抜けのリスクを削減することができる。

タスクＢ（２１－Ｂ）は、タイマイベントによってタスクＣ（２１－Ｃ）を駆動する。図示の例では、タスクＢ（２１－Ｂ）がタイマをセットした１００ｍｓ後にタスクＣ（２１－Ｃ）が実行される。タイマイベントの情報には対象タスクＩＤと起床時刻などを設定することができる。

タスクＤ（２１－Ｄ）は、メッセージの受信イベントで駆動される。イベントの情報には、対象タスクＩＤや受信メッセージなどを設定することができる。タスクＥ（２１－Ｅ）は所定の条件が成立した場合にタスクＦ（２１－Ｆ）を起床させる。イベントの情報には対象タスクＩＤと起床要因などを設定することができる。

＜外部通信部４０＞
図５は、ノード１の外部通信部４０で行われる受信処理の一例を示す図である。プロクシ３は、クライアントアプリケーション２からサーバアプリケーション２０に対するリクエストメッセージ３００を受信し、メッセージ３００に管理用のヘッダ３１０を付与し、サーバアプリケーション２０が動作する各ノード１に同一のメッセージ３００を転送する。

図６は、ヘッダ３１０の一例を示す図である。ヘッダ３１０は少なくとも、クライアント計算機４とノード１間の複数のコネクションを区別するためのコネクションＩＤ３１１と、同コネクションを用いて送信されたメッセージの通し番号であるメッセージＩＤ３１２と、元のメッセージのサイズ３１３を含む。

コネクションＩＤ３１１は、例えば、クライアント計算機４のＩＰアドレスと、プロクシ３とのコネクションが確立された度に加算される通し番号のタプルにて、一意のＩＤを割り当てる。

リクエストメッセージ３００を受信した外部通信部４０は、管理用のヘッダ３１０のメッセージサイズ３１３を参照して、１メッセージ分のデータの受信が完了するのを待つ。外部通信部４０は、１メッセージ分のデータを受信したら、コネクションＩＤ３１１を参照して当該メッセージ３００を待ち受けているタスク２１のタスクＩＤを特定する。

外部通信部４０は、タスク２１を駆動させるためのイベントを生成し、管理用のヘッダ３１０を取り除いたメッセージ３００を、生成したそのイベントに紐づけて、イベント管理キュー８０に追加する。

＜ステート管理部６０＞
図７は、ステート管理部６０の機能の一例を示す図である。ステート管理部６０は、ＭＶＣＣ方式のデータベース１００で複数のステートを管理する。ＭＶＣＣは複数のバージョンのデータセットを平行して読み書きする機能を有する。

ステート管理部６０は、共有メモリ９０上のデータベース１００にて、タスク２１間で共有されるステート全体を管理する。ステート管理部６０は、１つのデータベース１００に含まれる１以上のテーブルについて、テーブル単位で各ステートを管理する。また、本実施例では上述したように、特定のステート（テーブル）を更新するタスク２１は１つのみという前提である。

タスク実行制御部５０は、タスク２１の駆動要求が発生した場合、所定のルールに基づいて、当該タスク２１がステートにアクセスするためのトランザクションの開始をステート管理部６０に要求し、その応答としてステート（テーブル）のハンドルを取得して当該タスク２１にハンドルを渡す。なお、各タスク２１は、ハンドルを介して、ステート管理部６０経由でステートの参照又は更新を実行する。

タスク実行制御部５０は、所属するノード１がリーダノード１－１の場合、処理に併せてトランザクションを構成するタスク２１のアクセス対象について一括して合意形成処理を開始する。一方、所属するノード１がフォロワノード１－２、１－３の場合、タスク実行制御部５０は、合意形成処理が完了してから、その合意内容に基づいてトランザクションの開始をステート管理部６０に要求し、当該タスク２１の駆動を行う。

タスク２１で１つのイベント分の処理が終わり、イベント待ち状態に戻る際、タスク実行制御部５０は、当該タスク２１のトランザクションの終了をステート管理部６０に要求する。ステート管理部６０は、要求を受け付けると後述する管理テーブルに当該トランザクションの番号を設定してトランザクションを終了する。

＜管理テーブル＞
図８は、データベース管理テーブル２００の一例を示す図である。データベース管理テーブル２００は、１以上のテーブル１１０を含むデータベース１００の全体を管理するテーブルである。

データベース管理テーブル２００は、トランザクションの状態を格納するトランザクション状態２０１と、トランザクションの番号を格納するＸＮＯ２０２を１つのレコードに含む。

トランザクション状態２０１が「Ｃｏｍｍｉｔｔｅｄ」のレコードには、コミット済みのトランザクション番号の最大値が格納される。図示の例では、ＸＮＯ２０２が「１０２」までのトランザクションがコミット済みであることを示す。なお、ＸＮＯ２０２が「１０４」のトランザクションがコミット済みであっても、ＸＮＯ２０２が「１０３」のトランザクションが未コミットの場合は、「Ｃｏｍｍｉｔｔｅｄ」のＸＮＯ２０２は「１０２」となる。

トランザクション状態２０１が「Ｌａｓｔ」のレコードには、最後に開始したリード／ライトのトランザクション（以下、ＲＷトランザクションとする）の連番がトランザクション番号としてＸＮＯ２０２に設定される。

図９は、テーブル管理テーブル２１０の一例を示す図である。テーブル管理テーブル２１０－１～２１０－３は、データベース１００内のテーブル単位でトランザクションを管理する。本実施例では、データベース１００内にｆｏｏ、ｂａｒ、ｂａｚの３つのテーブルを有する例を示す。

テーブル管理テーブル２１０は、テーブル名２１１と、Ｃｏｍｍｉｔｔｅｄ２１２と、Ｉｎｐｒｏｇｒｅｓｓ２１３の項目で構成される。Ｃｏｍｍｉｔｔｅｄ２１２は、当該テーブルにおいて最後にコミットが完了したトランザクション番号（ＸＮＯ）を格納する。

ＩｎＰｒｏｇｒｅｓｓ２１３は、当該テーブルで現在進行中のＲＷトランザクション番号（ＸＮＯ）が格納される。なお、トランザクションの開始時などでトランザクション番号が未定の場合には無効値（例えば、－１等）を設定する。

＜データベース＞
図１０は、データベース１００のテーブル１１０－１～１１０－３の一例を示す図である。テーブル１１０－１は、テーブル名がｆｏｏである。テーブル１１０－２は、テーブル名がｂａｒである。テーブル１１０－３は、テーブル名がｂａｚである。

各テーブル１１０は、１つのステート（共有データ）を管理する。各テーブル１１０の行（レコード）は、ステートがリストやＫｅｙ－Ｖａｌｕｅ構造を持つ場合、各要素に対応する。各行は、ＸＮＯ１１１と、Ｉｎｄｅｘ１１２と、Ｖａｌｕｅ１１３を含む。

ＸＮＯ１１１は、当該行を更新したトランザクションの番号を格納する。過去の行も上書きせずに残しておくことができる。例えば、ｂａｒテーブル１１０－２のｉｎｄｅｘ＝１は、２つの更新履歴（ＸＮＯ＝１０２、１０４）を残している。

Ｉｎｄｅｘ１１２は、テーブル１１０内の行を識別する通し番号が格納される。なお、データベース１００がＫｅｙ－Ｖａｌｕｅ型の場合ではＫｅｙを格納することができる。Ｖａｌｕｅ１１３は、データ本体は格納される。データベース１００がＲＤＢであればカラム群で構成され、ＫＶＳ（Ｋｅｙ－Ｖａｌｕｅ Ｓｔｏｒｅ）であればＶａｌｕｅの部分が格納される。

＜ＭＶＣＣ方式＞
本実施例のデータベース１００は、上述したようにＭＶＣＣ方式でデータのバージョンが管理され、ＲＯトランザクションとＲＷトランザクションをサポートする。

ＲＯトランザクションはデータベース１００の全テーブル１１０、又は特定のテーブル１１０に対して参照のみのアクセス権を与える。

ＲＷトランザクションはデータベース１００内の特定のテーブル１１０に対して、参照及び更新のアクセス権を与える。ＲＷトランザクションの対象となるテーブル１１０は、当該テーブル１１０において進行中のＲＷトランザクションがコミットされるまで、当該テーブル１１０に対する次のＲＷトランザクションは開始できない。また、前提として、あるステート（テーブル１１０）を更新するタスク２１は１つのみとしているため、このようなＲＷトランザクションが開始できないケースは発生しない。

また、本実施例のＭＶＣＣ方式は、データベース１００全体としてのバージョンをトランザクション番号（ＸＮＯ）で管理する。各テーブル１１０内のレコードは、当該レコードを更新したトランザクション番号ＸＮＯとセットで管理される。

トランザクション番号ＸＮＯ＝Ｎの全テーブル１１０に対するＲＯトランザクションでは、トランザクション番号ＸＮＯがＮ以下の、全テーブル１１０のコミット済みの最新レコードを参照することができる。なお、ＸＮＯ＝Ｎの特定テーブルに対するＲＯトランザクションについては後述する。

トランザクション番号ＸＮＯ＝ＮのＲＷトランザクションでは、指定されたテーブル１１０を更新でき、かつテーブル１１０のコミット済みの最新のレコードを参照することができる。ステート管理部６０は、最新のトランザクション番号ＸＮＯがＮのとき、新たなＲＷトランザクションの番号と最新のトランザクション番号ＸＮＯをＮ＋１とする。

＜ＲＯトランザクション開始処理＞
図１１は、リードオンリ（ＲＯ）のトランザクションの開始処理の一例を示すフローチャートである。この処理は、ステート管理部６０がタスク実行制御部５０からリードオンリのトランザクションの開始要求を受け付けた場合に開始される。

ステート管理部６０は、タスク実行制御部５０からのトランザクションの開始要求にトランザクションの番号（ＸＮＯ）が指定されているか否かを判定する（Ｓ１１）。トランザクションの番号が指定されていなければステップＳ１２へ進み、指定されていればステップＳ１３に進む。

ステップＳ１２では、ステート管理部６０がデータベース管理テーブル２００を参照して、トランザクション状態２０１が「Ｃｏｍｍｉｔｔｅｄ」のＸＮＯ２０２を取得して当該トランザクション番号に対応するハンドルを生成してタスク実行制御部５０に応答する。図８のデータベース管理テーブル２００では、ステート管理部６０がＸＮＯ２０２＝１０２のトランザクション番号を取得して、各テーブル１１０でトランザクション番号が１０２以下の最新の行（レコード）を参照するハンドルを生成する。

ステップＳ１３では、指定されたトランザクション番号が、データベース管理テーブル２００のトランザクション状態２０１が「Ｃｏｍｍｉｔｔｅｄ」のＸＮＯ２０２に等しいか否かを判定する。指定されたトランザクション番号がＸＮＯ２０２と等しい場合には、ステート管理部６０がＸＮＯ２０２のトランザクション番号で各テーブル１１０を参照するハンドルを生成してタスク実行制御部５０に応答する。

一方、指定されたトランザクション番号がＸＮＯ２０２と等しくない場合には、ステート管理部６０はタスク実行制御部５０にエラーを通知して処理を終了する。

上記処理によって、ステート管理部６０は、データベース１００の全体に対してコミット済みのデータを参照するためのハンドルを生成して、タスク実行制御部５０に応答する。

図１２は、ハンドルの一例を示す図である。図１１のステップＳ１４で生成されたハンドル５１０は、対象テーブル５１１がデータベース１００の全体で、トランザクション番号（ＸＮＯ）が指定されたトランザクション番号で、かつテーブル１１０へのアクセスモードがリードオンリ（ＲＯ）であることを示す。

図１３は、指定されたテーブルへのリードオンリのトランザクション（以下、ＲＯトランザクションとする）の開始要求の一例を示すフローチャートである。この処理は、ステート管理部６０がタスク実行制御部５０から指定されたテーブル１１０に対してＲＯトランザクションの開始要求を受け付けた場合に開始される。

ステート管理部６０は、指定されたテーブル１１０のテーブル管理テーブル２１０を参照して、トランザクションの開始要求で指定されたトランザクション番号が、ＩｎＰｒｏｇｒｅｓｓ２１３のトランザクション番号－１以下、すなわち、コミット済みであるか否かを判定する（Ｓ２１）。

ステート管理部６０は、コミット済みであればステップＳ２２へ進んで、当該テーブル１１０に対するハンドルを生成してタスク実行制御部５０に応答し、未コミットであればステップＳ２３へ進んで、タスク実行制御部５０にエラーを通知する。

＜ＲＯトランザクション終了処理＞
図１４は、ＲＯトランザクションの終了要求の一例を示すフローチャートである。この処理は、ステート管理部６０がタスク実行制御部５０からＲＯトランザクションの終了要求を受け付けた場合に実行される。

ステート管理部６０は、アクセスが完了したハンドルを解放して処理を終了する（Ｓ２５）。

上記処理によって、ステート管理部６０は、ＲＯトランザクションの開始及び終了の処理でハンドルの生成と解放を実行する。

＜ＲＷトランザクション開始処理＞
図１５は、指定されたテーブルへのＲＷトランザクションの開始要求の一例を示すフローチャートである。この処理は、ステート管理部６０がタスク実行制御部５０から指定されたテーブル１１０に対してＲＷトランザクションの開始要求を受け付けた場合に開始される。

ステート管理部６０は、指定されたテーブル１１０のテーブル管理テーブル２１０を参照して、ＩｎＰｒｏｇｒｅｓｓ２１３の値が無効値であるか否か、すなわち、処理中のＲＷトランザクションが存在するか否かを判定する（Ｓ３１）。ＩｎＰｒｏｇｒｅｓｓ２１３の値が無効値であれば処理中のＲＷトランザクションは存在しないとみなし、ステップＳ３２へ進み、無効値ではない場合（トランザクションの処理中）であればステップＳ３４に進む。

ステップＳ３２では、ステート管理部６０がデータベース管理テーブル２００のトランザクション状態２０１がＬＡＳＴのレコードのＸＮＯ２０２の値に１を加算して更新し、指定されたテーブル１１０のトランザクション番号とする。ステート管理部６０は、指定されたテーブル１１０のテーブル管理テーブル２１０のＩｎｐｒｏｇｒｅｓｓ２１３に当該トランザクション番号を設定する。

ステップＳ３３では、指定されたテーブル１１０を参照するハンドルを生成してタスク実行制御部５０に応答する。

一方、ステップＳ３４では、指定されたテーブル１１０のテーブル管理テーブル２１０でＩｎＰｒｏｇｒｅｓｓ２１３の値が無効値ではない場合は、現在トランザクションの処理中であるので、ステート管理部６０はタスク実行制御部５０にエラーを通知して処理を終了する。

上記処理によって、ステート管理部６０は、指定されたテーブル１１０がトランザクションの処理中ではない場合には、当該テーブル１１０をアクセスするハンドルを生成して、タスク実行制御部５０に応答する。

図１６は、ハンドルの一例を示す図である。図１５のステップＳ３３で生成されたハンドル５１０は、対象テーブル５１１が指定されたテーブル１１０で、トランザクション番号（ＸＮＯ）がデータベース管理テーブル２００のＬＡＳＴに対応するＸＮＯ２０２を更新した結果である「１０５」、かつテーブル１１０へのアクセスモードがリード／ライトであることを示す。

特定のテーブル１１０に対するＲＷトランザクションの一例について、図９を参照して以下に説明する。

テーブル名２１１＝「ｆｏｏ」と「ｂａｒ」のテーブル管理テーブル２１０－１、２１０－２のＩｎｐｒｏｇｒｅｓｓ２１３には、未コミットのＲＷトランザクション番号が設定されているため、新たなＲＷトランザクションの開始はできない。

テーブル名２１１＝「ｂａｚ」のテーブル１１０に対してＲＷトランザクションの開始を要求した場合、データベース管理テーブル２００のトランザクション状態２０１が「Ｌａｓｔ」のＸＮＯ２０２に格納されている「１０４」に１を加算した値＝「１０５」を、データベース管理テーブル２００のＬａｓｔのＸＮＯ２０２と、テーブル名２１１＝「ｂａｚ」のテーブル管理テーブル２１０のＩｎＰｒｏｇｒｅｓｓ２１３にセットする。以後、トランザクションの要求に応じてテーブル名２１３＝「ｂａｚ」のテーブル１１０－３を更新した場合、ＸＮＯ１１１＝「１０５」の行がテーブル１１０－３に追加される。

＜ＲＷトランザクション終了処理＞
図１７は、ＲＷのトランザクションの終了要求の一例を示すフローチャートである。この処理は、ステート管理部６０がタスク実行制御部５０からＲＷトランザクション終了要求（コミット完了）を受け付けた場合に開始される。

ステート管理部６０は、タスク実行制御部５０から受け付けた終了要求のテーブル１１０とトランザクション番号を受け付けて、該当するテーブル１１０のテーブル管理テーブル２１０のＣｏｍｍｉｔｔｅｄ２１２に、上記受け付けたトランザクション番号を設定し、Ｉｎｐｒｏｇｒｅｓｓ２１３には無効値を設定する（Ｓ４１）。

ステート管理部６０は、データベース管理テーブル２００を参照してトランザクション状態２０１が「Ｃｏｍｍｉｔｔｅｄ」のレコードのＸＮＯ２０２の値が、トランザクションの終了要求を受け付けたテーブル管理テーブル２１０のＣｏｍｍｉｔｔｅｄ２１２のトランザクション番号－１の場合には、テーブル管理テーブル２１０のＣｏｍｍｉｔｔｅｄ２１２及びトランザクション番号を、トランザクション状態２０１が「Ｃｏｍｍｉｔｔｅｄ」のレコードのＸＮＯ２０２に設定する。

次にステップＳ４３～Ｓ４６では、ステート管理部６０は、データベース管理テーブル２００を参照してトランザクション状態２０１が「Ｃｏｍｍｉｔｔｅｄ」のレコードのＸＮＯ２０２の値に１を加算したトランザクション番号から、トランザクション状態２０１が「Ｌａｓｔ」のレコードのＸＮＯ２０２のトランザクション番号についてコミット済みであるかを判定してデータベース管理テーブル２００を更新する。

ステップＳ４３では、ステート管理部６０が、トランザクション状態２０１が「Ｃｏｍｍｉｔｔｅｄ」のレコードのＸＮＯ２０２に１を加算した値を変数ｉに設定する。ステップＳ４４では、ステート管理部６０が、テーブル管理テーブル２１０を参照してトランザクション番号＝ｉがコミット済みであるか否かを判定する。ステート管理部６０は、コミット済みであればステップＳ４５に進み、そうでない場合には処理を終了する。

ステップＳ４５では、ステート管理部６０が、データベース管理テーブル２００のトランザクション状態２０１が「Ｃｏｍｍｉｔｔｅｄ」のレコードのＸＮＯ２０２に変数ｉの値を設定する。ステップＳ４６では、変数ｉに１を加算してから、ステップＳ４４に戻って上記処理を繰り返す。

上記処理によって、ＲＷトランザクションのうちコミット済みのトランザクション番号がテーブル管理テーブル２１０とデータベース管理テーブル２００に設定されて、コミット完了の設定が終了する。

＜タスク実行制御部５０＞
図１８は、ノード１間で行われる合意形成の一例を示す図である。合意形成の処理は、タスク実行制御部５０が主体となって実行する。

タスク実行制御部５０は、イベントに基づいて所定のタスク２１を駆動する他、ノード１間で決定的な動作をするようにタスク２１の実行やステート管理部６０上のトランザクションをコントロールする。

まず、タスク実行制御部５０はノード間通信部７０を介して合意形成プロトコルを実行して、イベント管理キュー８０内のイベントについてイベントの処理順序、及びイベント情報をノード１間で合意する（Ｓ５１）。ここでいうイベント情報とは、後述するイベント管理キュー８０に登録されたエントリに含まれる要求元タスクＩＤ８２、対象タスクＩＤ，イベント詳細８４、ハンドル８６である。ハンドル８６には駆動対象のタスク２１が、データベース１００のテーブル１１０のいずれのバージョン（トランザクション番号ＸＮＯ）のデータに対して参照及び更新するのか、といった情報を含む。

次に、リーダノード１－１のタスク実行制御部５０は、イベント管理キュー８０のイベントについて、ＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）にて当該イベントを待つタスク２１の駆動を行う（Ｓ５２）。フォロワノード１－２、１－３のタスク実行制御部５０は合意済みイベントのみ、タスク２１の駆動を実施する。

タスク実行制御部５０は、上記タスク２１の駆動に先立ち、当該タスク２１がアクセスするステート（共有データ）に対するＲＯトランザクションやＲＷのトランザクションの開始をステート管理部６０に要求する。タスク実行制御部５０は、当該要求に対する応答として、アクセス用のハンドルをステート管理部６０から受け取る（Ｓ５３）。

このハンドルは、タスク２１の駆動の際にタスク実行制御部５０が当該タスク２１に渡す。駆動されたタスク２１は、タスク実行制御部５０から渡されたハンドルを用いて所定のバージョンのステート（データ）にアクセスし、再びイベント待ちに入る際にタスク実行制御部５０が当該ハンドルを解放し、ＲＷトランザクションをコミットする。

タスク実行制御部５０は、各タスク２１に対して、タスク登録、イベント登録、イベント待ち、タスクの駆動、外部送信の機能を提供する。

タスク登録は、多重化対象のサーバアプリケーション２０を構成するタスク２１を、タスク実行制御部５０の管理対象に登録する。そして、タスク実行制御部５０は、タスク２１の初期化処理時に当機能の呼び出しを行う。また、タスク実行制御部５０は、タスク２１が更新するステート（テーブル）のリストの登録も行う。

イベント登録は、タスク実行制御部５０が、呼び出し元のタスク２１又は他のタスク２１を駆動させるイベントをイベント管理キュー８０に追加する。

イベント待ちは、タスク実行制御部５０が、呼び出し元のタスク２１を駆動させるイベントが発生するまでタスク２１を待ち状態にする。また、タスク実行制御部５０は、呼び出し元のタスク２１が保持しているハンドルについて、トランザクション終了処理を行う。

タスクの駆動については、タスク２１を駆動するイベントが発生した際、タスク実行制御部５０がイベント待ち状態の所定のタスク２１を駆動させる。その際、ステート管理部６０にトランザクション開始要求を出力し、タスク２１が参照又は更新するステート（テーブル１１０）にアクセスするためのハンドルを生成させて、タスク実行制御部５０が取得してからタスク２１にハンドルを渡す。

ノード１がリーダノード１－１の場合、当該ノード１のタスク実行制御部５０は、タスク２１の駆動に平行して、イベントの処理順序についてフォロワノード１－２、１－３との間で一括して合意を形成する。すなわち、リーダノード１－１では、合意形成の以前にタスク２１を開始しておくことで、合意形成（同期）に要する遅延を抑制して処理結果を出力することができる。

また、リーダノード１－１は、１つのイベントで駆動するタスク２１が、データベース１００のテーブル１１０のデータのいずれのバージョン（トランザクション番号ＸＮＯ）に対して参照し、いずれのバージョンでデータを更新するのかも併せてフォロワノード１－２、１－３との間で合意を形成する。

リーダノード１－１は、フォロワノード１－２、１－３との間で、アクセス対象のバージョンを一括して合意を形成することで、前記従来例のように、タスク２１がデータベース１００へアクセスする度にノード１間で合意形成を行うのを回避して、同期による遅延を回避することができる。

一方、ノード１がフォロワノード１－２、１－３の場合、タスク実行制御部５０は、合意が形成された後に、合意結果に基づいて対象のタスク２１の駆動を行う（ハンドルの生成処理も含む）。

外部送信は、タスク実行制御部５０が、タスク２１に代わってクライアント計算機４等の外部へ応答（処理結果を含むメッセージ３００）を送信する。また、タスク実行制御部５０は、要求元のタスク２１を駆動させたイベントについて、処理順序の合意形成が未完了の場合、合意形成が完了するまで実際の送信を保留する。また、タスク実行制御部５０は、要求元のタスク２１を駆動させたイベントについて、処理順序の合意形成に失敗した場合、送信予定であった処理結果を破棄する。

＜タスク初期化処理＞
図１９は、タスクの初期化処理の一例を示すシーケンス図である。タスク実行制御部５０がタスク２１を起動すると（Ｓ６１）、初期化処理を実行する（Ｓ６２）。

各タスク２１は初期化処理において、タスク実行制御部５０の「タスク登録」機能を呼び出して、当該タスク２１を多重化対象のタスク２１としてタスク管理テーブル２２０へ登録する。当該タスク２１は今後、更新し得るステート（テーブル１１０）のリストもタスク実行制御部５０に伝える。タスク実行制御部５０は、これらの情報をタスク管理テーブル２２０にて管理する。

初期化処理が完了すると、タスク２１はイベント待ち状態になり（Ｓ６３）、所定のイベント（タイマ、メッセージ受信、他のタスクからの駆動要求等）が発生するまでスリープする。

図２０は、タスク管理テーブル２２０の一例を示す図である。タスク管理テーブル２２０は、タスク実行制御部５０によって管理される。

タスク管理テーブル２２０は、タスクＩＤ２２１と、待ちイベント２２２と、更新対象テーブル２２３を１つのレコードに含む。タスクＩＤ２２１には、サーバアプリケーション２０を構成するタスク２１の識別子が格納される。

待ちイベント２２２は、タスク２１を起動させる契機となるイベントを格納する。更新対象テーブル２２３は、タスク２１の実行によって更新されるデータベース１００のテーブル１１０の識別子（又は名称）を格納する。

タスク実行制御部５０は、イベントが発生すると、タスク管理テーブル２２０の待ちイベント２２２に対応するタスク２１を起動して、更新対象テーブル２２３をステート管理部６０へ通知することができる。

＜タスクの１イベント処理＞
図２１は、タスク処理の一例を示すシーケンス図である。図示の例では、リーダノード１－１のタスク２１と、フォロワノード１－２、１－３のタスク２１がそれぞれ起動して、イベント待ちの状態を示している（Ｓ７１）。

＜リーダノードの処理＞
まず、リーダノード１－１が行う処理について説明する。リーダノード１－１は、タスク２１が待ち受けているイベントを受け付ける。リーダノード１－１は、タスク実行制御部５０がイベントをイベント管理キュー８０に登録する（Ｓ７２）。

タスク実行制御部５０は、タスク管理テーブル２２０を参照して、待ちイベント２２２に対応するタスクＩＤ２２１を特定し、トランザクションの開始をステート管理部６０に要求する（Ｓ７３）。トランザクションは、タスクＩＤ２２１に対応するタスク２１が参照するテーブル、又は全テーブルに対するＲＯトランザクションや、更新対象テーブル２２３にて示されるテーブルのＲＷトランザクションである。

ステート管理部６０は、トランザクションの種類（ＲＯ、ＲＷ）とアクセス対象のテーブル１１０に応じてハンドルを生成してタスク実行制御部５０に応答する（Ｓ７４）。タスク実行制御部５０は、アクセス対象のステート（テーブル１１０）に対するハンドルを取得する。

タスク実行制御部５０は、タスク２１がどのバージョンのステート（テーブル１１０）に対して参照又は更新を行うかについて、他のノード１と合意を形成する（Ｓ７６）。

タスク実行制御部５０は、他のノード１との間で合意が形成されるのを待たずに、タスク２１を駆動する（Ｓ７７）。タスク実行制御部５０は、ステップＳ７４で取得したハンドルをタスク２１に渡す。

タスク２１は、タスク実行制御部５０から受け取ったハンドルを経由してステート（テーブル１１０）に対してアクセス（参照、更新）を行う（Ｓ７８）。タスク２１は、共有メモリ９０に格納されているデータベース１００のテーブル１１０にノンブロッキングでアクセスする。

タスク２１は、処理結果として外部への送信をタスク実行制御部５０に要求する（Ｓ８０）。

リーダノード１－１では、タスク２１を開始した後に、フォロワノード１－２から合意の形成を受信する（Ｓ７９）。

タスク実行制御部５０は、ステップＳ７９で受信した合意形成が完了済みであることを確認した後に、外部（プロクシ３）への送信を実行する（Ｓ８１）。タスク実行制御部５０は、合意形成が未完了だった場合は完了するまで送信を保留する。これにより、仮に合意形成に失敗して他のノード１にリーダを交替する場合、ノード１間で異なる処理結果を送信するのを防止する。なお、合意形成に失敗した場合には、上述のようにタスク実行制御部５０は処理結果を破棄する。

タスク２１は、１つのイベントの処理が完了するとイベント待ちの状態に移行して、再びスリープ状態となる（Ｓ８２）。

タスク実行制御部５０は、他のノード１と合意形成の完了を確認した後、ステート管理部６０にタスク２１を含むトランザクションの終了要求を出力し（Ｓ８３）、ステート管理部６０は、データベース管理テーブル２００及びテーブル管理テーブル２１０でコミット完了を設定する。

タスク実行制御部５０は、処理が完了した当該イベントをイベント管理キュー８０から削除して１つのイベントに関する処理を終了する（Ｓ８４）。

＜フォロワノードの処理＞
次に、フォロワノード１－２で行われる処理について説明する。なお、以下の説明では、フォロワノード１－２、１－３は同様であるので、フォロワノード１－２についてのみ説明する。

上述したように、フォロワノード１－２で起動したタスク２１はイベント待ちの状態で（Ｓ７１）、ステップＳ７２でタスク実行制御部５０がイベントを受け付けてイベント管理キュー８０に登録する。

タスク実行制御部５０は、リーダノード１－１からの合意形成の要求に応じて、タスク２１を駆動させるイベントがイベント管理キュー８０に登録済みであることを確認した後に、合意形成を返信する（Ｓ７９）。

合意形成後、タスク実行制御部５０は、合意内容に基づいてタスク管理テーブル２２０を参照して、待ちイベント２２２に対応するタスクＩＤ２２１を特定し、トランザクションの開始をステート管理部６０に要求する（Ｓ８５）。トランザクションは、リーダノード１－１との合意内容に含まれるハンドル５１０情報に基づき、所定のテーブル５１１、所定のトランザクション番号５１２、所定のモード５１３（ＲＯ、又はＲＷ）にて開始する。

ステート管理部６０は、トランザクションの種類（ＲＯ、ＲＷ）とアクセス対象のテーブル１１０に応じてハンドルを生成してタスク実行制御部５０に応答する（Ｓ８６）。タスク実行制御部５０は、アクセス対象のステート（テーブル１１０）に対するハンドルを取得する。

タスク実行制御部５０は、タスク２１を駆動する（Ｓ８７）。タスク実行制御部５０は、ステップＳ８６で取得したハンドルをタスク２１に渡す。

タスク２１は、タスク実行制御部５０から受け取ったハンドルを経由してテーブル１１０（ステート）に対してアクセス（参照、更新）を行う（Ｓ８８）。タスク２１は、共有メモリ９０に格納されているデータベース１００のテーブル１１０にノンブロッキングでアクセスする。

タスク２１は、処理結果として外部への送信をタスク実行制御部５０に要求する（Ｓ８９）。タスク実行制御部５０は、外部（プロクシ３）への送信を実行する（Ｓ８９、Ｓ９０）。

タスク２１は、１つのイベントの処理が完了するとイベント待ちの状態に移行して、再びスリープ状態となる（Ｓ９１）。

タスク実行制御部５０は、ステート管理部６０にタスク２１のトランザクションの終了要求を出力し、ステート管理部６０は、データベース管理テーブル２００及びテーブル管理テーブル２１０でコミット完了を設定する（Ｓ９２）。

タスク実行制御部５０は、処理が完了した当該イベントをイベント管理キュー８０から削除して１つのイベントに関する処理を終了する（Ｓ９３）。

＜タスク実行制御部５０のトランザクション終了要求＞
上記の例ではタスク２１のイベント待ちに併せ、暗黙的にタスク実行制御部５０がステート管理部６０に対してトランザクション終了要求を出力しているが、タスク２１が明示的にトランザクションの終了要求を出力してもよい。

例えば、タスクＡ（２１－Ａ）がステートＴ１を更新し、続いてタスクＢ（２１－Ｂ）を駆動する場合、ステートＴ１の更新結果をタスク２１－Ｂに参照させることを保証するには、タスクＡは明示的にステートＴ１の更新をコミットしてからタスクＢを駆動する必要がある。

ステートＴ１をコミットした後、タスクＡは次回のイベント駆動にてトランザクションを改めて開始するまでステートＴ１を更新できない。ステートＴ１の更新結果をタスクＢに参照させる必要がない場合は、タスクＡによる明示的なコミットは不要となる。この場合、タスクＢには更新前のステートＴ１を参照させることになる。

＜タスク実行制御部５０のイベント登録処理＞
図２２は、タスク実行制御部５０が実施するイベント登録処理の一例を示すフローチャートである。

まず、タスク実行制御部５０は、タスク２１からの要求に基づいてイベントを生成してイベント管理キュー８０に登録する（Ｓ１０１）。イベントの生成については後述する。

タスク実行制御部５０は、当該ノード１がリーダノード１－１であるか否かを判定する（Ｓ１０２）。リーダノード１－１であればステップＳ１０３へ進みフォロワノード１－２、１－３であればステップＳ１０６に進む。

ステップＳ１０３では、タスク実行制御部５０が、所定のルールに基づいて、駆動対象のタスク２１が使用するＲＯトランザクションやＲＷトランザクションの開始要求をステート管理部６０に出し、ステート管理部６０からの応答としてアクセス用のハンドルを受け取る。このハンドルの参照を、上記ステップＳ１０１で生成したイベントにセットしておく。ハンドルをイベントにセットする手法については後述する。

リーダノード１－１のタスク実行制御部５０は、当該イベントの処理順序、及びイベント情報について、フォロワノード１－２、１－３との間で合意形成を開始する（Ｓ１０４）。合意形成はリーダノード１－１におけるイベントの登録順に行う。

そして、リーダノード１－１では、合意形成の完了を待たずに対象のタスク２１の駆動を開始する（Ｓ１０５）。最終的にタスク２１のＲＷトランザクションの内容をステートに反映（コミット）する場合や、外部送信する場合にはタスク実行制御部５０は、合意形成の完了を待ち合わせるので、その時点まで先行してタスク２１の処理を進めておくことに問題はない。万が一、合意形成に失敗した場合は、タスク実行制御部５０は、トランザクションの処理結果や外部送信データを破棄するので、誤った処理結果を出力することはない。なお、タスク実行制御部５０が駆動するタスク２１にはステップＳ１０３のハンドルが渡される。

当該ノード１がフォロワノード１－２の場合のステップＳ１０６では、フォロワノード１－２がハンドルの生成やタスク２１の駆動前に当該イベントに対する合意形成の完了を待つ必要がある。

既にリーダノード１－１から合意形成の要求が来ていた場合、フォロワノード１－２は合意可能か（同じ内容のイベントがイベント管理キュー８０存在するか）を判定し、判定結果を他のノード１に応答する（Ｓ１０６）。

タスク実行制御部５０は、合意が形成済みであるか否かを判定する（Ｓ１０７）。当該イベントに対する合意形成が完了していた場合、タスク実行制御部５０は、合意内容に従って、所定のトランザクション番号のＲＯトランザクションやＲＷトランザクションの開始要求をステート管理部６０に出力して、ステート管理部６０からの応答としてハンドルを取得する（Ｓ１０８）。

そして、タスク実行制御部５０は、当該イベントにより駆動されるタスク２１を駆動して、ステップＳ１０８で取得したハンドルをタスク２１に渡す（Ｓ１０９）。

上記処理によって、イベント管理キュー８０にイベントが登録されて、タスク実行制御部５０がステート管理部６０からのハンドルをタスク２１に渡して、タスク２１の駆動が実施される。

＜イベント管理キュー８０の構成＞
図２３は、イベント管理キュー８０の一例を示す図である。イベント管理キュー８０は、イベントの識別子を格納するＥＮＯ８１と、要求元タスクＩＤ８２と、対象タスクＩＤ８３と、イベント詳細８４と、合意形成情報８５と、ハンドル８６と、送信キュー８７を１つのレコードに含む。

ＥＮＯ８１は、イベントの発生順にリーダノード１－１が割り当てる通し番号を格納する。フォロワノード１－２、１－３はＥＮＯ８１が未設定の状態でイベントを生成する。その後、リーダノード１－１から送信された合意形成情報を参照して内容が一致するイベントを検索し、合意形成情報に含まれるＥＮＯの値を自ノード１のイベント管理キュー８０に設定する。

要求元タスクＩＤ８２は、当該イベントを生成したタスクの識別子を格納する。対象タスクＩＤ８３は、要求元タスクＩＤ８２から渡されたイベント詳細８４を参照して、同条件でイベント待ちしているタスク２１を検索し、そのタスク２１の識別子を設定するイベント詳細８４は、図４に示したイベントの種類や周期を格納する。

合意形成情報８５は、合意形成プロトコルで使用する情報を格納する。合意形成としてはＲＡＦＴなど、任意のリーダ－フォロワ型の合意形成プロトコルを使用することを想定している。合意形成情報８５は、少なくとも、他のノード１から受信した合意形成内容や、合意形成完了か未完か、等の情報を含む。合意形成内容は当該イベントの情報（ＥＮＯ、要求元タスクＩＤ８２、対象タスクＩＤ８３、イベント詳細８４、ハンドル８６）を含む。

ハンドル８６は、ステート管理部６０を介してステートを参照又は更新するための情報を格納する。すなわち図１６に示す０個以上のハンドル５１０であり、アクセス対象テーブルの識別子、トランザクション番号、ＲＯとＲＷのどちらか、といった情報を含む。フォロワノード１－２、１－３はリーダノード１－１から受信した合意形成内容に含まれるハンドル情報を参照し、同一内容のハンドルを生成するようステート管理部６０に要求する。

送信キュー８７は、当該イベントにより駆動したタスク２１による外部送信メッセージ（処理結果）を格納する。タスク実行制御部５０は、タスク２１から外部への送信要求があった場合、まだ合意形成が未完だった場合、合意形成が完了するまで送信キューにて送信メッセージを保持する。

＜リーダノードのトランザクション開始処理＞
図２４は、リーダノード１－１で行われるトランザクション開始処理の一例を示すフローチャートである。この処理は、タスク実行制御部５０がトランザクションを開始する際に実行される。

まず、ステップＳ１１１では、タスク実行制御部５０が、トランザクション番号（ＸＮＯ２０２）を指定せずに、ＲＯトランザクションの開始要求を出力する。トランザクション番号（ＸＮＯ２０２）の指定はないので、データベース管理テーブル２００のＣｏｍｍｉｔｔｅｄのＸＮＯ２０２の値がトランザクション番号として使用される。

ステート管理部６０は、ＲＯトランザクションの開始要求に応じてハンドルを生成し、タスク実行制御部５０はステート管理部６０からハンドルを取得する。

次に、タスク実行制御部５０は、タスク管理テーブル２２０を参照して、駆動するタスクＩＤ２２１の行を参照して、更新対象テーブル２２３の内容をリストとして生成する（Ｓ１１２）。

タスク実行制御部５０は、ステップＳ１１３～Ｓ１１５で、上記ステップＳ１１２で生成したリストのテーブル１１０についてステップＳ１１４の処理を繰り返して実行する。ステップＳ１１４では、タスク実行制御部５０が、ステート管理部６０に対して、現在処理対象のテーブルＴのＲＷトランザクションの開始要求を出力し、ステート管理部６０の応答からハンドルを取得する。

次に、タスク実行制御部５０は、今回駆動されるタスク２１が他のタスクから駆動されたものか否かを判定する（Ｓ１１６）。駆動対象のタスク２１が他のタスク２１からの駆動イベントによるものだった場合にはステップＳ１１７へ進み、駆動しない場合にはステップＳ１２２へ進む。

上記判定は、タスク実行制御部５０がイベント管理キュー８０を参照して、駆動対象の対象タスクＩＤ８３が要求元タスクＩＤ８２に含まれていれば、他のタスク２１を駆動すると判定することができる。

タスクＡ（２１－Ａ）から別のタスクＢ（２１－Ｂ）を駆動する場合、ステートの更新と参照の順序性を担保するため、駆動元のタスク２１－Ａが更新した内容を駆動先のタスクＢに提供する必要がある。

例えば、上記ステップＳ１１１におけるＲＯトランザクション番号ＸＮＯが１００の場合、駆動元のタスクＡが更新したテーブル１１０のトランザクション番号ＸＮＯが１０３だったとすると、ステップＳ１１１で取得したハンドルでは駆動元のタスクＡが更新した内容を別のタスクＢでは参照できない（より古い内容しか参照できない）。

そこで、タスク実行制御部５０は、アクセス対象のテーブル１１０として当該テーブルを指定し、トランザクション番号ＸＮＯ＝１０３のＲＯトランザクションの開始を要求する。なお、この場合、駆動元のタスクＡがＸＮＯ＝１０３のＲＷトランザクションを終了（コミット）するまで、当該テーブルのＸＮＯ＝１０３のＲＯトランザクションを開始できない。このため、トランザクション番号ＸＮＯ＝１０３のトランザクションの終了（コミット）が完了するのを待ってから処理を再開する。

ステップＳ１１７では、タスク実行制御部５０がタスク管理テーブル２２０を参照して駆動元となるタスクＡのタスクＩＤ２２１の行から更新対象テーブル２２３の値を取得して、アクセス可能なテーブルのリストとして生成する。

次に、タスク実行制御部５０は、ステップＳ１１８～Ｓ１２１で、上記ステップＳ１１７で生成したリストの更新対象のテーブル１１０についてステップＳ１１９～Ｓ１２０の処理を繰り返して実行する。この処理は、駆動元のタスクＡが更新したステートに対して、駆動先のタスクＢがリードオンリで参照可能にするための処理である。

ステップＳ１１９では、タスク実行制御部５０が上記リストの更新対象のテーブル１１０について、トランザクション番号（ＸＮＯ２０２）が上記ステップＳ１１１で取得したハンドルに対応するテーブル１１０のトランザクション番号よりも大で、かつ当該テーブル１１０はコミット済みであるか否かを判定する。コミット済みであればステップＳ１２０へ進み、そうでない場合にはステップＳ１２１へ進む。

タスクＡがタスクＢを駆動し、タスクＢがタスクＣを駆動するような連鎖的に別のタスク２１を駆動する場合も、タスクＣはタスクＡの更新結果を参照できる必要がある。よって、駆動元のタスクＡが有するＲＷのトランザクションだけではなく、特定のテーブル１１０に対するＲＯトランザクションも駆動先のタスクＢに引き継ぐ必要がある。

ただし、現在処理対象のテーブル１１０のトランザクション番号（ＸＮＯ）が、ステップＳ１１１でハンドルを取得した全テーブル１１０を対象とするＲＯトランザクションのトランザクション番号（ＸＮＯ）より小さくなった場合は、ステップＳ１１１で取得したハンドルにて目的のステートを参照可能であるので、新たにトランザクション開始を要求する必要はない。

ステップＳ１２０では、タスク実行制御部５０がステート管理部６０に、現在処理対象のテーブルＴのＲＯトランザクション開始要求を出力して、ステート管理部６０からテーブルＴに対するハンドルを取得する。

更新対象のトランザクションについてコミットが完了していない場合はトランザクションの開始に失敗するが、そのまま無視する。この場合は、当該ステートの更新内容を駆動先のタスクＢに参照させないことを意図していると考えられるため、更新前の状態を駆動先のタスクＢに参照させたとしてもアプリケーションロジック上は問題ない。

タスク実行制御部５０が、ステップＳ１２０で取得したハンドル情報は、当該イベントに対応するイベント管理キュー８０のハンドル８６に設定される（Ｓ１２２）。ハンドル８６は、（１）合意形成内容としてフォロワノード１－２、１－３へとトランザクション情報を伝えるため、又は（２）タスク２１が当該イベントの処理を完了し、再びイベント待ちに入る際に、タスク実行制御部５０が暗黙的にトランザクションを終了するために用いられる。

＜フォロワノードのトランザクション開始処理＞
図２５は、フォロワノード１－２、１－３で行われるトランザクション開始処理の一例を示すフローチャートである。この処理は、リーダノード１－１から合意形成要求に対してフォロワノード１－２、１－３が合意した後に開始される。

ステップＳ１３１では、タスク実行制御部５０がリーダノード１－１からの合意形成情報からハンドルを取得する。合意形成情報にはリーダノード１－１が取得したハンドル情報が含まれる。以降、このハンドルを参照して、どのテーブル１１０に対して、どのトランザクション番号（ＸＮＯ２０２）でトランザクションを開始するか特定する。

ステップＳ１３２では、タスク実行制御部５０が上記ステップＳ１３１で取得したハンドル情報から、リーダノード１－１と同じトランザクション番号（ＸＮＯ２０２）を指定して、全てのテーブル１１０を参照するためのＲＯトランザクションの開始要求をステート管理部６０に出力し、ステート管理部６０が生成したハンドルを取得する。

データベース管理テーブル２００でトランザクション状態２０１が「Ｃｏｍｍｉｔｔｅｄ」の行のトランザクション番号（ＸＮＯ２０２）が、上記ハンドルを取得したトランザクション番号（ＸＮＯ）よりも小さい場合、トランザクションを開始できないので、進行中のトランザクションが完了してＣｏｍｍｉｔｔｅｄがＸＮＯになるのを待ってから処理を再開する。

アクセス対象のテーブル１１０は、駆動対象のタスク２１が更新し得るテーブル１１０に加えて、タスクＡから別のタスクＢを駆動する場合で駆動元のタスクＡが更新したテーブル１１０も含む。駆動対象のタスク２１はＲＷのトランザクションで、駆動元のタスクＡが更新したテーブル１１０を参照する場合はＲＯトランザクションである。なお、ステップＳ１３２と同様に、進行中のＲＷトランザクションが終了（コミット）するまで新たなトランザクションを開始できない場合があるので、適宜待ち合わせをしてから再開する。

ステップＳ１３３では、タスク実行制御部５０が、タスク管理テーブル２２０を参照して、駆動するタスクＩＤ２２１の行を参照して、更新対象テーブル２２３の内容をリストとして生成する。

タスク実行制御部５０は、ステップＳ１３４～Ｓ１３６で、上記生成したリスト内のテーブル１１０についてステップＳ１３５の処理を繰り返して実行する。ステップＳ１３５では、タスク実行制御部５０が、ステート管理部６０に対して、現在処理対象のテーブル１１０のＲＯトランザクション及びＲＷトランザクションの開始要求を出力し、ステート管理部６０の応答からハンドルを取得する。

ステップＳ１３７では、上記ステップＳ１３５で取得した全てのハンドルを、当該タスク２１のイベント管理キュー８０のハンドル８６に設定する。

上記図２４、図２５の処理によって、リーダノード１－１とフォロワノード１－２、１－３でそれぞれトランザクションが開始される。

＜合意形成失敗の場合＞
ノード１間の合意形成は、失敗する場合も生じる。合意形成の失敗要因としては、通信異常やハードウェア障害に伴い、一部のノード１のみ通信メッセージ（合意形成情報）が欠損、あるいは遅延し、所定時間内に合意形成できなかった場合（タイムアウト）に発生する。

周知又は公知の例では、合意形成には自ノードを含め、過半数のノード１が合意すれば合意形成が完了となる。この際に合意できた過半数以上のノード１は合意成功、合意できなかったノード１は合意失敗となる

合意形成失敗時の処理としては、合意形成に失敗したノード１を除外し、残りのノード１でリーダの再選出を行う。なお、リーダの再選出方法は周知又は公知の合意形成プロトコルに含まれるので詳細は割愛する。

除外されたノード１は適宜、復旧処理を行う。例えば、元リーダノード１－１の場合、先行的に実行していたタスク２１の処理を中断し、ＲＷトランザクションをコミットせずに破棄し、送信データも破棄する。そして、タスク実行制御部５０は合意結果に基づいてトランザクションを改めて開始して、タスク２１を再駆動させる。

＜外部通信部４０＞
図２６は、送信処理の一例を示す図である。

各ノード１の外部通信部４０は処理順序、イベント情報の合意済みイベント８１０に付随する外部送信用のメッセージ３０２と宛先情報を取得し、宛先（プロクシ３）に向けて当該メッセージを送信する。この場合、外部通信部４０はメッセージ３００のヘッダ３１０にコネクションＩＤとメッセージＩＤを付与する。

コネクションＩＤはクライアントアプリケーション２とプロクシ３とのコネクション確立時にプロクシ３が割り当てた一意のＩＤである。メッセージＩＤは当該コネクションにて外部通信部４０が送信するメッセージ３００に対して一意に割り当てられたＩＤ（通し番号）である。

あるコネクションに着目すると、各ノード１からは同じメッセージＩＤの同じメッセージ３００がプロクシ３宛てに送信されることが期待される。プロクシ３はコネクションＩＤとメッセージＩＤを参照して同一メッセージを複数受信したことを確認し、所定のポリシーに基づいて１つのメッセージを選択し、ヘッダ３１０を取り除いたメッセージ３００をクライアントアプリケーション２に転送する。上記ポリシーは、例えば、先着優先や、多数決、などを採用することができる。

上記構成により、一部のノード１が外部送信前に障害で停止しても合意を形成した他のノード１から処理結果のメッセージ３００を取得することが可能となり、クライアントはタイムアウト＆リトライをせずとも、滞りなく処理を継続することが可能となる。

前記実施例１では、処理時間の長いタスク２１が存在した場合、ＲＷトランザクションを開始してから終了（コミット）するまで、長時間を要する場合がある。この処理が完了するまでの間に他のテーブルに対するＲＷトランザクションが何度か起こったとしても、ステート全体（全テーブル）に対するＲＯトランザクションは、それらの更新内容を参照することはできない。これは、ステート全体に対するＲＯトランザクションは、未コミットのデータを参照しないよう、連番でコミット済みのトランザクション番号以降に更新されたデータを参照しないためである。

そこで、実施例２では、ステート管理部６０が、コミット終了時までＲＷトランザクションのトランザクション番号（ＸＮＯ２０２）を未定のままにしておく。リーダノード１－１のタスク実行制御部５０がＲＷトランザクションをコミットする際に、どのハンドルをどの順序でコミットするかをノード１間で合意形成する。タスク実行制御部５０は、合意が形成された場合のみ実際のコミットを実行する。

上記により、各ノード１は、必ずコミットの順序でコミット済みのトランザクション番号が更新されていくので、長時間ＲＷトランザクションを保持し続けるタスク２１があったとしても、最新バージョンのステート全体に対してＲＯトランザクションが可能となる。

前記実施例１との相違点は、ステート管理部６０の処理の一部と、タスク実行制御部５０の処理の一部が変更され、その他の構成は前記実施例１と同様である。

図２７は、ＲＷのトランザクションの開始要求の一例を示すフローチャートである。この処理は、前記実施例１の図１５の処理のステップＳ３２、Ｓ３３をステップＳ１４１、Ｓ１４２に置き換えたもので、その他の構成は図１５と同様である。

ステート管理部６０は、指定されたテーブル１１０のテーブル管理テーブル２１０を参照して、ＩｎＰｒｏｇｒｅｓｓ２１３の値が無効値であるか否か、すなわち、処理が開始されてトランザクション番号が未定であるか否かを判定する（Ｓ３１）。ＩｎＰｒｏｇｒｅｓｓ２１３の値が無効値であればステップＳ１４１へ進み、無効値ではない場合（トランザクションの処理中）であればステップＳ３４に進む。

ステップＳ１４１では、ステート管理部６０がデータベース管理テーブル２００のトランザクション状態２０１がＬＡＳＴのレコードのＸＮＯ２０２の値に未定を意味する値（例えば、－２）を設定する。ステート管理部６０は、指定されたテーブル１１０のテーブル管理テーブル２１０のＩｎｐｒｏｇｒｅｓｓ２１３に未定値を設定する。

ステップＳ１４２では、テーブル１１０を参照するハンドル５１０を生成してタスク実行制御部５０に応答する。ハンドル５１０は、図２８で示すように、トランザクション番号のＸＮＯに未定値である「－２」が設定される。

一方、ステップＳ３４では、指定されたテーブル１１０のテーブル管理テーブル２１０でＩｎＰｒｏｇｒｅｓｓ２１３の値が無効値ではない場合は、現在トランザクションの処理中であるので、ステート管理部６０はタスク実行制御部５０にエラーを通知して処理を終了する。

上記処理によって、ステート管理部６０は、指定されたテーブル１１０がトランザクションの処理中ではない場合には、当該テーブル１１０をアクセスするハンドルに未定値を設定して、タスク実行制御部５０に応答する。

そして、ステート管理部６０は、ＲＷトランザクションの終了の際に、データベース管理テーブル２００のＣｏｍｍｉｔｔｅｄの値に１を加算し、当該トランザクションのＸＮＯ２０２を「未定値」から前記「Ｃｏｍｍｉｔｔｅｄ＋１」の値に更新する。これに伴い、トランザクション番号ＸＮＯが「未定値」となっている更新対象のテーブル１１０のレコードについて、トランザクション番号ＸＮＯを前記「Ｃｏｍｍｉｔｔｅｄ＋１」の新しい値に更新する

一方、タスク実行制御部５０の処理は、次のように変更する。

タスク実行制御部５０は、ＲＷトランザクションの終了（コミット）を代行する場合、コミット対象のハンドルの順序についてノード１間で合意形成する処理を追加する。

そして、タスク実行制御部５０は、コミットの順序の合意形成が完了してから、その順序の通りにコミットを実施する。リーダノード１－１もフォロワノード１－２、１－３も、合意形成が完了するまでコミットしない。この結果、タスク実行制御部５０は処理結果の外部送信も保留する。

この合意形成を処理している間、タスク２１はブロックせずに処理を可能とする（合意形成に失敗しても、タスクの実行には影響を与えないため）。

以上のように実施例２では、ノード１は、必ずコミットの順序でトランザクション番号が更新されるので、長時間のトランザクションがあったとしても、最新バージョンのステート全体に対してＲＯトランザクションが可能となる。

＜結び＞
以上のように、上記実施例の多重系処理システムは、以下のような構成とすることができる。

（１）プロセッサ１１とメモリ１２と通信装置（通信インタフェース１３）を含むノード（１）を複数有し、前記複数のノード（１）をネットワーク（５）を介して接続し、前記複数のノード（１）が入力に対して一意の出力を行う１以上のタスク（２１）をそれぞれ実行する多重系処理システムであって、前記ノード（１）は、イベントを受け付けて、前記イベントに対応する前記タスク（２１）を実行するトランザクションを開始するタスク実行制御部（５０）と、前記タスクがアクセスするデータベース（１００）のデータ（テーブル１１０内のデータ）のバージョンを管理するステート管理部（６０）と、を有し、前記タスク実行制御部（５０）は、前記タスク（２１）の処理を開始する以前に、前記データベース（１００）で前記タスク（２１）が参照するデータのバージョン又は前記タスク（２１）が更新するデータのバージョンを一括して前記ノード（１）間で合意を形成することを特徴とする多重系処理システム。

上記構成により、タスク２１の処理を開始する前にどのバージョンのデータを参照し、どのバージョンとしてデータを更新するか多重系を構成するノード（１）間で合意形成することで、前記従来例のようにデータへの参照又は更新順をアクセスを行う度にノード（１）間で一致化させる必要がなくなって、同期に要する遅延を削減することができる。

（２）上記（１）に記載の多重系処理システムであって、

前記タスク実行制御部（５０）は、１つの前記イベントの処理におけるデータのアクセスについて、一括して前記ノード（１）間で合意を形成することを特徴とする多重系処理システム。

上記構成により、一括して前記ノード１間でアクセス対象となるデータについて合意を形成することで、前記従来例のようにデータへの参照又は更新順をアクセスを行う度にノード（１）間で一致化させる必要がなくなって、同期に要する遅延を削減することができる。

（３）上記（２）に記載の多重系処理システムであって、前記タスク実行制御部（５０）は、前記イベントがタイマイベントの場合には、前記タイマが作動する以前にアクセス対象のデータについて一括して前記ノード（１）間で合意を形成することを特徴とする多重系処理システム。

上記構成により、タイマイベントの場合、タスク実行制御部５０はタイマが作動する前に、予めアクセス対象のデータのバージョンについて合意を形成することで、ノード１間の同期に要する遅延を削減することができる。

（４）上記（１）に記載の多重系処理システムであって、前記ノード（１）は、リーダノード（１－１）とフォロワノード（１－２、１－３）を含み、前記リーダノード（１－１）の前記タスク実行制御部（５０）は、前記イベントを受け付けると、当該イベントに対応する前記タスク（２１）がアクセスする前記データについて、前記フォロワノード（１－２、１－３）に合意の形成を依頼して、合意が形成される以前に前記タスク（２１）を開始することを特徴とする多重系処理システム。

上記構成により、リーダノード１－１は合意形成前にタスク２１の実行を開始し、フォロワノード１－２、１－３は合意形成の後にタスク２１の実行を開始することで、少なくともリーダノード１－１は合意形成待ちによる遅延を回避することが可能となる。

（５）上記（４）に記載の多重系処理システムであって、前記リーダノード（１－１）の前記タスク実行制御部（５０）は、前記合意の形成に失敗した場合には、処理を開始していた前記トランザクションを中断し、前記トランザクションの処理結果を破棄することを特徴とする多重系処理システム。

上記構成により、各ノード１は、必ずコミットの順序でコミット済みのトランザクション番号が更新されていくので、長時間ＲＷトランザクションを保持し続けるタスク２１があったとしても、最新バージョンのデータ（ステート）全体に対してＲＯトランザクションが可能となる。

（６）上記（１）に記載の多重系処理システムであって、前記ステート管理部（６０）は、前記トランザクションを識別する番号としてトランザクション番号（ＸＮＯ）を前記トランザクションに付与し、前記トランザクションが処理した前記データベース（１００）のデータのバージョンを前記トランザクション番号（ＸＮＯ）で管理することを特徴とする多重系処理システム。

上記構成により、データベース１００をＭＶＣＣ方式で管理し、アクセス対象のデータのバージョンを事前に一括してノード１間で合意を形成することで同期に要する負荷を削減することができる。

（７）上記（６）に記載の多重系処理システムであって、前記ステート管理部（６０）は、前記トランザクションがリードライトトランザクションの場合、当該リードライトトランザクションのコミットが完了するまで当該リードライトトランザクションのトランザクション番号を未定値とし、前記タスク実行制御部（５０）が、前記リードライトトランザクションをコミットする場合、当該リードライトトランザクションでアクセするデータの順序について前記ノード（１）間で合意を形成することを特徴とする多重系処理システム。

上記構成により、各ノード１は、必ずコミットの順序でコミット済みのトランザクション番号が更新されていくので、長時間ＲＷトランザクションを保持し続けるタスク２１があったとしても、最新バージョンのステート全体に対してＲＯトランザクションが可能となる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。

また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１－１～１－３ ノード
２ クライアントアプリケーション
３ プロクシ
４ クライアント計算機
５ ネットワーク
１１ プロセッサ
１２ メモリ
２０ サーバアプリケーション
２１－Ａ～２１－Ｃ タスク
３０ 多重化処理部
４０ 外部通信部
５０ タスク実行制御部
６０ ステート管理部
７０ ノード間通信部
８０ イベント管理キュー
９０ 共有メモリ
１００ データベース
１１０－１～１１０－３ テーブル
２００ データベース管理テーブル
２１０－１～２１０－３ テーブル管理テーブル

Claims (14)

1. プロセッサとメモリと通信装置を含むノードを複数有し、前記複数のノードをネットワークを介して接続し、前記複数のノードが入力に対して一意の出力を行う１以上のタスクをそれぞれ実行する多重系処理システムであって、
   前記ノードは、
   イベントを受け付けて、前記イベントに対応する前記タスクを実行するトランザクションを開始するタスク実行制御部と、
   前記タスクがアクセスするデータベースのデータのバージョンを管理するステート管理部と、を有し、
   前記タスク実行制御部は、
   前記タスクの処理を開始する以前に、前記データベースで前記タスクが参照するデータのバージョン又は前記タスクが更新するデータのバージョンを一括して前記ノード間で合意を形成することを特徴とする多重系処理システム。
2. 請求項１に記載の多重系処理システムであって、
   前記タスク実行制御部は、
   １つの前記イベントの処理におけるデータのアクセスについて、一括して前記ノード間で合意を形成することを特徴とする多重系処理システム。
3. 請求項２に記載の多重系処理システムであって、
   前記タスク実行制御部は、
   前記イベントがタイマイベントの場合には、タイマが作動する以前にアクセス対象のデータについて一括して前記ノード間で合意を形成することを特徴とする多重系処理システム。
4. 請求項１に記載の多重系処理システムであって、
   前記ノードは、
   リーダノードとフォロワノードを含み、
   前記リーダノードの前記タスク実行制御部は、
   前記イベントを受け付けると、当該イベントに対応する前記タスクがアクセスする前記データについて、前記フォロワノードに合意の形成を依頼して、合意が形成される以前に前記タスクを開始することを特徴とする多重系処理システム。
5. 請求項４に記載の多重系処理システムであって、
   前記リーダノードの前記タスク実行制御部は、
   前記合意の形成に失敗した場合には、処理を開始していた前記トランザクションを中断し、前記トランザクションの処理結果を破棄することを特徴とする多重系処理システム。
6. 請求項１に記載の多重系処理システムであって、
   前記ステート管理部は、
   前記トランザクションを識別する番号としてトランザクション番号を前記トランザクションに付与し、前記トランザクションが処理した前記データベースのデータのバージョンを前記トランザクション番号で管理することを特徴とする多重系処理システム。
7. 請求項６に記載の多重系処理システムであって、
   前記ステート管理部は、
   前記トランザクションがリードライトトランザクションの場合、当該リードライトトランザクションのコミットが完了するまで当該リードライトトランザクションのトランザクション番号を未定とし、
   前記タスク実行制御部が、
   前記リードライトトランザクションをコミットする場合、当該リードライトトランザクションでアクセするデータの順序について前記ノード間で合意を形成することを特徴とする多重系処理システム。
8. プロセッサとメモリと通信装置を含むノードを複数有し、前記複数のノードをネットワークを介して接続し、前記複数のノードが入力に対して一意の出力を行う１以上のタスクをそれぞれ実行する多重系処理システムの制御方法であって、
   前記ノードは、イベントを受け付けて、前記イベントに対応する前記タスクを実行するトランザクションを開始するタスク実行制御ステップと、
   前記ノードは、前記タスクがアクセスするデータベースのデータのバージョンを管理するステート管理ステップと、を含み、
   前記タスク実行制御ステップは、
   前記タスクの処理を開始する以前に、前記データベースで前記タスクが参照するデータのバージョン又は前記タスクが更新するデータのバージョンを一括して前記ノード間で合意を形成することを特徴とする多重系処理システムの制御方法。
9. 請求項８に記載の多重系処理システムの制御方法であって、
   前記タスク実行制御ステップは、
   １つの前記イベントの処理におけるデータのアクセスについて、一括して前記ノード間で合意を形成することを特徴とする多重系処理システムの制御方法。
10. 請求項９に記載の多重系処理システムの制御方法であって、
    前記タスク実行制御ステップは、
    前記イベントがタイマイベントの場合には、タイマが作動する以前にアクセス対象のデータについて一括して前記ノード間で合意を形成することを特徴とする多重系処理システムの制御方法。
11. 請求項８に記載の多重系処理システムの制御方法であって、
    前記ノードは、リーダノードとフォロワノードを含み、
    前記リーダノードの前記タスク実行制御ステップは、
    前記イベントを受け付けると、当該イベントに対応する前記タスクがアクセスする前記データについて、前記フォロワノードに合意の形成を依頼して、合意が形成される以前に前記タスクを開始することを特徴とする多重系処理システムの制御方法。
12. 請求項１１に記載の多重系処理システムの制御方法であって、
    前記リーダノードの前記タスク実行制御ステップは、
    前記合意の形成に失敗した場合には、処理を開始していた前記トランザクションを中断し、前記トランザクションの処理結果を破棄することを特徴とする多重系処理システムの制御方法。
13. 請求項８に記載の多重系処理システムの制御方法であって、
    前記ステート管理ステップは、
    前記トランザクションを識別する番号としてトランザクション番号を前記トランザクションに付与し、前記トランザクションが処理した前記データベースのデータのバージョンを前記トランザクション番号で管理することを特徴とする多重系処理システムの制御方法。
14. 請求項１３に記載の多重系処理システムの制御方法であって、
    前記ステート管理ステップは、
    前記トランザクションがリードライトトランザクションの場合、当該リードライトトランザクションのコミットが完了するまで当該リードライトトランザクションのトランザクション番号を未定とし、
    前記タスク実行制御ステップは、
    前記リードライトトランザクションをコミットする場合、当該リードライトトランザクションでアクセするデータの順序について前記ノード間で合意を形成することを特徴とする多重系処理システムの制御方法。

Images