トランザクション処理システム
複数の分散ノードを備えるシステムにおけるトランザクション処理の方法である。この方法は、第１のノードにおいてメッセージを受け取るステップを備える。このメッセージは、あるエンティティに関連するデータについて実行されるべき操作を規定している。さらに、この方法は、前記ノード上で動くメッセージ・ハンドラによる処理のために前記メッセージをキューイングするステップを備える。さらにこの方法は、他のメッセージ・ハンドラが前記データについて操作をしていない場合に、前記メッセージ・ハンドラに、前記メッセージの処理を許可するステップと、前記メッセージを、その後の処理のために第２のノードに送るステップとを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、トランザクション処理（transaction processing）に関しており、特に、しかし制限的ではなく、賭け取引を処理するための方法及び装置に関連するものである。
【背景技術】
【０００２】
トランザクション処理システムは様々な環境中で使用されており、それは、株式取引システム、旅行予約システム、及び、オンライン賭け取引所（online betting exchanges）のような賭けシステムを含む。高速なトランザクション処理システムへの要求が高まるにつれて、従来のシステムは、要求される処理速度を提供しようと努力することになる。
【発明の概要】
【０００３】
本発明によれば、分散された複数のノードを備えるシステムにおけるトランザクション処理の方法が提供される。ここでは、データは、複数のデータ・パーティションの中に保持される。それぞれのパーティション中のデータは、それぞれの単一のノードに関連付けられる。このシステムは、データ・パーティションのグループを制御するための複数のコントローラを含む。それぞれのコントローラは、データ・パーティション中のデータについての処理を実行するための、複数の書き込み段階（write stage）と、実行のスレッド（threads of execution）を書き込み段階に割り当てるためのスレッド・マネージャとを備える。ここで、スレッド・マネージャは、所定のデータ・パーティション中におけるデータ操作のために、最大でも、単一のスレッドを割り当てるように構成されている。この方法は、複数のコントローラ中の第１のものにおけるメッセージを受け取るステップを含む。このメッセージは、所定のデータ・パーティションに関連するデータについて実行されるべき操作を規定する。さらに、この方法では、複数の書き込み処理の一つによる処理のためにメッセージをキューイング（queuing）し、そして、書き込み段階に、メッセージの処理を許可するが、これは、処理のスレッドが所定のデータ・パーティションのために利用可能な場合においてである。
【０００４】
本発明によれば、複数の分散されたノードを備えるシステムにおけるトランザクション処理のための装置がさらに提供される。ここでは、データは、複数のデータ・パーティション内に保持される。それぞれのパーティション内のデータは、ノードのうちのそれぞれ一つに関連付けられる。このシステムは、データ・パーティションのグループを制御するための複数のコントローラを備える。それぞれのコントローラは、データ・パーティション中のデータについての処理を実行するための、複数の書き込み段階と、処理のスレッドを書き込み段階に割り当てるためのスレッド・マネージャとを備える。ここでは、スレッド・マネージャは、所定のデータ・パーティション中におけるデータについての操作のために、最大で単一のスレッドを割り当てるように構成されている。この装置は、複数のコントローラのうちの第１のものにおいてメッセージを受け取るためのレシーバを備える。メッセージは、所定のデータ・パーティションに関連するデータについて実行されるべき操作と複数の書き込み段階とを、メッセージを処理するために規定する。ここでは、所定のデータ・パーティションのために処理のスレッドが利用可能な場合は、書き込みステージは、一つ又はそれ以上のメッセージを処理するように構成されており、そして、処理のスレッドが利用可能でない場合には、この装置は、メッセージをキュー（queue）に配置するように構成されている。
【０００５】
本発明の他の態様によると、複数の分散されたノードを備えるシステムにおけるトランザクション処理の方法が提供される。この方法は、第１のノードにおけるメッセージを受け取るステップを備える。メッセージは、エンティティに関連するデータについて実行されるべき操作を規定する。さらに、この方法は、ノード上で動いているメッセージ・ハンドラによって処理するためにメッセージをキューイングすること、他のメッセージ・ハンドラがそのデータについて操作を行っていない場合は、メッセージ・ハンドラがメッセージを処理することを許可すること、そして、その後の処理のために、メッセージを第２のノードに送ることを含む。
【０００６】
メッセージ・ハンドラは、読み取りのみ要求（read only requests）を扱う複数の第１メッセージ・ハンドラと、読み取り−書き込み要求（read-write requests）を扱う複数の第２メッセージ・ハンドラとを備える。ここで、複数の読み取りのみ要求は、並列的に動作できる（runnable in parallel）ようになっている。
【０００７】
複数の読み取りのみ要求は、エンティティに関連するデータについての操作のために実行可能としうるが、これは、読み取り−書き込み要求が前記データについて操作していない場合においてのみである。ただ一つの読み取り−書き込み要求が、ある所定の時間において、あるエンティティに関連するデータについて実行可能となることができる。
【０００８】
この方法は、受け取ったメッセージを、受け取ったときにジャーナリング（journaling）することを含む。
【０００９】
この方法は、受領した他の複数のメッセージと共に、メッセージをバッチング（batching）することを備えることができる。バッチングは、それが実行される処理ステージに依存しうる。バッチングは、ネットワーク待ち時間（network latency）、ディスク待ち時間（disk latency）、及び処理されるべきエンティティのうちの少なくとも一つに従って実行されうる。
【００１０】
メッセージ・ハンドラは、複数のエンティティと関連することができる。そして、この方法は、メッセージが向けられたメッセージ・ハンドラに従って、メッセージをグループ化（grouping）することを、さらに含むことができる。
【００１１】
メッセージ・ハンドラに関連付けられた複数のエンティティに関するデータは、いずれかの単一のノードにおいて格納されうる。単一のエンティティに関するデータは、いずれかの単一のノードにおいて格納されうる。
【００１２】
エンティティは、ユーザに関連付けられたアカウントを備えることができ、あるいは、複数のユーザが賭けを行うマーケットを備えることができる。
【００１３】
メッセージは、非同期で送信されうる。
【００１４】
ノードは、サーバを含むことができる。
【００１５】
本発明によれば、分散された複数のノードを備えるシステムでのトランザクション処理のための装置がさらに提供される。この装置は、第１のノードにおいてメッセージを受け取る手段を備える。メッセージは、エンティティに関するデータについて実行されるべき操作を規定している。さらに、この装置は、ノード上で動くメッセージ・ハンドラによる処理のためにメッセージをキューイングするための手段、他のメッセージ・ハンドラがメッセージを処理していない場合に、メッセージ・ハンドラがそのメッセージを処理することを許可するための手段、及び、その後の処理のために、第２のノードに向けてメッセージを送るための手段を備える。
【００１６】
本装置は、単一のアカウントあるいは単一のマーケットについて動作するメッセージ・ハンドラに単一のスレッドを割り当てるために、スレッド・マネージャをさらに含むことができる。また、本装置は、複数のメッセージ・ハンドラに影響するメッセージを処理するためにプリプロセッサ（pre-processor）をさらに含むことができる。プリプロセッサは、多数のジャーナル・メッセージ・ストリームから、単一のメッセージ・ストリームを生成するように構成されうる。
【００１７】
本装置は、メッセージが受け取られていないことの通知に対応して、第１のノードから第２のノードにメッセージを再送付（resending）する手段を、さらに含むことができる。
【００１８】
本装置は、大量に要求されたデータを提供するために、データ・ディストリビュータのクラスタをさらに含むことができる。
【図面の簡単な説明】
【００１９】
本発明の実施形態は、例示を用いて、以下において、添付の図面を参照しながら説明される。
【図１】一般的なトランザクション処理環境についての概略図である。
【図２】賭け交換システムとしてのトランザクション処理システムを図示する概略図である。
【図３】図２で示されたサーバのコンポーネントを図示する概略図である。
【図４】本発明によるトランザクション処理システム内での、アカウント及びマーケットに関するデータの区分け（partitioning）を示す図である。
【図５】トランザクション処理機能を提供するソフトウエア・モジュールの構成を図示する概略図である。
【図６ａ】本発明によるトランザクション処理システムの一部を構成する二つのサーバ間における、メッセージについての通常の交換を示す図である。
【図６ｂ】本発明によるトランザクション処理システムの一部を構成する二つのサーバ間におけるメッセージ交換の間でのメッセージ損失を示す図である。
【図６ｃ】本発明によるトランザクション処理システムの一部を構成する二つのサーバ間におけるメッセージ交換の間での、メッセージの重複排除（de-duplication）を示す図である。
【図７】本発明によるトランザクション処理システムを通過するトランザクションの第１の流れを示す図である。
【図８】図２に示すサーバ上で動作して、図７に示すトランザクションの流れを許可するトランザクション処理モジュールについてのインスタンス（instances）を示す概略図である。
【図９】本発明によるトランザクション処理システムを通過するトランザクションの第２の流れと、第１及び第２の賭けを共にマッチングすることに関わるマッチング・プロセスとを示す図である。
【図１０】本発明によるトランザクション処理システムを通過するトランザクションの第２の流れと、第１及び第２の賭けを共にマッチングすることに関わるマッチング・プロセスとを示す図である。
【図１１】図２に示すサーバ上で動作し、図９及び１０に示すトランザクションの流れを許可するトランザクション処理モジュールについてのインスタンスを示す概略図である。
【発明を実施するための形態】
【００２０】
図１は、一般的なトランザクション処理環境１を表している。トランザクション処理システム２は、より大きな機能システム３の一部となっており、この機能システムは、他のシステム、アプリケーション、あるいはユーザと、クライアント・インタフェース４を介して通信する。クライアント・インタフェース・モジュール４は、異なるソースからトランザクション情報を受け取るために、そして、関連するトランザクション情報をトランザクション処理システム２に送り、若しくはそこから受け取るために、複数のサブシステム４ａ、４ｂ、４ｃを持つことができる。トランザクション処理システム２は、特定の機能システム３の要求に従って、トランザクションを処理する。例えば、機能システムは、株式交換システム（stock exchange system）であり、ここでは、トランザクション処理システムは、付け値（bids）と申し込み（offers）との釣り合い（match）を取る。あるいは、機能システムは、銀行システム（banking system）であり、ここでは、トランザクション処理システムは、預金（credits）と負債（debits）を処理する。
【００２１】
図２は、賭け交換システム（betting exchange system）３の環境でのトランザクション処理システム２を表している。この賭け交換システムは、例えば米国特許出願GB2356071Aに記載されているように、対向する賭け（opposing bets）の釣り合いを取るように構成されている。
【００２２】
賭け交換システム３は、クライアント・インタフェース・モジュール４と、例えばファイアウオール５を通してリンクされたトランザクション処理システム２とを含む。クライアント・インタフェース・モジュール４は、ここにおいてクライアント・インタフェース・サーバと呼ばれる複数のサーバ４００を備える。これらは、クライアントとの、到来する（incoming）又は出ていく（outgoing）通信を扱う。クライアントは、様々なシステムとのインタフェースを行うサーバ・アプリケーションでありうる。そして、この様々なシステムは、例えば、賭け交換をとりまとめ、そして、賭けトランザクション要求をトランザクション処理システムに供給するものである。クライアント・インタフェース・サーバ４００は、ユーザから出された賭け及び／又は関連する賭け情報要求メッセージを受け取るように、そして、対応する要求メッセージをトランザクション処理システム２に導入するように構成されている。クライアント・インタフェース・サーバ４００は、例えば、彼らの賭け可能なアカウントバランス（available-to-bet account balance）を見るために、ユーザからの要求メッセージを受け取り、あるいは、彼らの現在有効な全ての賭けを見るために、ユーザからの要求メッセージを受け取ることも可能である。クライアント・インタフェース・サーバ４００は、トランザクション処理システム２からメッセージを受け取り、そして、対応するメッセージをユーザに返すようにも構成される。このクライアント・インタフェース・サーバは、サーバ４００ａ・・・ｎとしてここで個別に言及もされている。
【００２３】
トランザクション処理システム２は、複数のサーバ２００にわたって、高度に分散されている。これらのサーバは、ここでは、トランザクション処理サーバとして言及されており、そして、それは、クライアント・インタフェース・サーバ４００からのメッセージを受け取るようになっている。トランザクション処理システム２を複数のサーバ２００にわたって配置することは、もし必要なときは、さらなるサーバの追加によって、容易にそして効率的なコストでシステムを拡大できることを意味する。
【００２４】
図３を参照すると、それぞれのトランザクション処理サーバ２００及びそれぞれのクライアント・インタフェース・サーバは、少なくとも一つのプロセッサ２０１／４０１と、例えばＲＡＭであるメモリ２０２／４０２と、例えばハードディスクのような不揮発性メモリ２０３／４０３と、ネットワークインタフェースを含むＩ／Ｏシステム２０４／４０４とを備える。当業者には理解されることとして、各サーバは、その機能を発揮するために必要な全てのコンポーネントを備えている。トランザクション処理サーバは、ここでは、個別に、サーバ２００ａ・・・ｎとして参照される。トランザクション・サーバ２００ａ〜ｃ、２００ｄ〜ｆのグループは、それぞれの共有ディスク（shared disks）６と関連付けられている。
【００２５】
トランザクション処理システム２内のメッセージは、例えば、トランザクション処理システム２における特定の出来事を列挙する（detailing）イベントや特定の操作を実行するためのコマンドを含むことができる。例えば、コマンド・メッセージは、ユーザの賭け可能なアカウントバランス（available-to-bet account balance）を見るための要求でありうるし、イベント・メッセージは、ユーザに対して、彼らの賭けの提出が成功したことを報告するメッセージでありうる。
【００２６】
高いトランザクション速度を達成するために、分散されたシステムにおける各サーバ２００は、ある程度のデータ局所性（data locality）を有しており、リモートのシステムあるいはディスクへのネットワーク呼（network calls）に関連するオーバヘッドを防いでいる。これは、ユーザ・アカウントによる、そして賭けマーケット（betting market）による、トランザクション処理システム２の区分け（partitioning）により達成される。単一のユーザ・アカウントに関連する全ての情報は、単一のサーバに格納され、単一の賭けマーケットに関する全ての情報は、単一のサーバに格納される。このことは、ネットワーク中におけるハードディスクなどの不揮発ストレージやリモートのサーバへのネットワーク呼を個別のサーバが作る必要性を減少させる。このようにして、トランザクション処理システムにおける待ち時間（latencies）が減少し、そして、トランザクションのスループットは向上する。可能であれば、データは、ローカルのメモリあるいは、少なくとも、少ない待ち時間のメモリに格納され、このようにして、例えばネットワーク化されたハードディスクのように待ち時間が多いリソースにアクセスする必要を減らす。
【００２７】
図４は、賭けトランザクションを処理するためのトランザクション処理システム２で使われるアカウント１０の組とマーケット１１の組とを表している。賭けは、ユーザに向けて表示された値付けスクリーン（pricing screens）を通して許可される。賭けの提起を望むユーザには、ユーザ・アカウント１０が割り当てられる。このユーザ・アカウントには、彼らは、例えばインターネットに基づく安全な現金支払いシステムを介して、お金を提供（deposit）することができる。トランザクション処理システム２は、それぞれのユーザアカウント１０に、それ自体に固有のＩＤを割り当てる。
【００２８】
ユーザは、表示された掛け率（odds）に対して彼らが賭けを提起する複数の賭けマーケット（betting markets）１１へのアクセスを持つ。賭けマーケット１１は、例えば、フットボールの試合や競馬などのスポーツ・イベントの結果を含むことができる。前記したユーザ・アカウント１０により、トランザクション処理システム２は、それぞれの賭け市場１１に、それに固有のＩＤを割り当てる。
【００２９】
ユーザ・アカウント１０のグループ１２は、それぞれのアカウント・コントローラ・アプリケーション１３により制御される。ある特定グループのユーザ・アカウント１２のためのアカウント・コントローラ１３は、ユーザ・アカウントに関連する情報をメモリ２０２内のグループに格納するサーバ２００上で動作する。単一のアカウントに関する、及び、あるアカウント・コントローラに関するアカウントのグループに関する全ての情報は、単一のサーバに格納され、あるいはこれにより所有される。それぞれのアカウント・コントローラ１３は、割り当てられたユーザ・アカウント１０ついての要求を提供することについて、及び、全てのアカウントの中枢的な機能（all account centric functions）について、責任を持つ。
【００３０】
例えば、もしユーザが、彼らのアカウント１０についての操作の実行、例えば、賭けを提起すること、彼らの賭け可能なバランスをロードすること、彼らの現在の賭けの概要を見ること、あるいは、彼らの現在の損失見込み（current exposure）すなわち最も悪い事件シナリオにおいて、彼らの賭けからどの程度損失を被るかの計算を望む場合、その操作は、割り当てられたアカウント・コントローラ１３によって提供される。この操作は、ユーザのアカウント１０が配置される単一のサーバ２００にアクセスすることによって提供される。例えば、図２を参照して、アカウント・コントローラについての別々のインスタンスは、サーバ２００ａ〜ｃのぞれぞれの上で動作し、それぞれのサーバ上で保存されたアカウントを処理する。
【００３１】
同様に、賭けマーケット１１は、多数のマーケット・コントローラ・アプリケーション１４によって制御される。ここで、それぞれのマーケット・コントローラ１４は、賭けマーケット１１のグループ１５について責任を持つ。特定の賭けマーケット１１のためのマーケット・コントローラ１４は、前記したとおり、メモリ２０２中の前記賭けマーケット１１に関する情報を格納するサーバ２００上で動作する。単一のマーケットに関する、そして、マーケット・コントローラに関連するマーケットのグループに関する全ての情報は、単一のサーバ上に保存され、あるいは、所有される。マーケット・コントローラ１４は、全てのマーケットの中枢的な機能（all market centric functions）を提供することに責任を持つ。これらの機能は、以下で説明されるような賭けのマッチングを含みうる。例えば、図２を再び参照して、マーケット・コントローラについての別々のインスタンスは、サーバ２００ｄ〜ｆのそれぞれの上で動作し、それぞれのサーバで記録されたマーケット情報を処理する。
【００３２】
各サーバ４００、２００の上で同時に動作するスレッドの数は、最小に保たれる。このことは、高いトランザクション・レートの維持に役立つ。なぜなら、各サーバ４００、２００のプロセッサ４０１、２０１は、多数のスレッドの間で処理時間（processing time）を共有することを必要としないからである。トランザクション処理システム２により使用されるスレッド数（thread count）は、主に非同期メッセージの形態（predominately asynchronous messaging style）を用いることによって、低く保たれる。したがって、メッセージがトランザクション処理システム２に持ち込まれるたびに、処理のためのスレッドを割り当てるのではなく、受領されたメッセージは、到来キューに保持され、そして、処理される前に、スレッドが他の操作の後に利用可能になることを待たなければならない。本発明におけるスレッド管理の態様は、以下においてさらに詳しく記述される。
【００３３】
本発明によるトランザクション処理システム２は、次のようなアーキテクチャを用いる。すなわち、ここでは、このシステムは、メッセージのキューにより接続された処理ステージについてのパイプラインに分割される。一般的に、あるステージは、到来イベント（inbound events）のためのソース・キューと、イベントを処理するためのイベント・ハンドラと、ステージのコンポーネントを監視し、そして、ヒューリステックス（heuristics）の処理を、ステージをホスト（host）するスレッド・マネージャに提供するためのリソース・コントローラの組と、送出キューあるいはシンク（outbound queues or sinks）の組とを備える。この、ステージに基づくアーキテクチャは、図５〜１０に関連して、以下においてさらに記述される。
【００３４】
リソース・コントローラは、バッチング・リソース・コントローラ・モジュール（batching resource controller modules）を含む。このモジュールの機能は、待ち時間及びスループット・ターゲットを、あるものと他のものと引き替えることにより、満たすことである。待ち時間は、それぞれのステージの相互作用の間に処理されるメッセージのバッチ・サイズを低くすることにより、スループットに悪影響を与えるけれども、改善されうる。スループットは、メッセージのバッチ・サイズを大きくすることにより、改善されうる。バッチング・リソース・コントローラは、各ステージの相互作用に要する時間（待ち時間）と、毎秒に処理されるメッセージの数（スループット）とを監視し、そして、これに従って、到来メッセージ・キューのバッチ・サイズを調整する。
【００３５】
バッチング・リソース・コントローラは、到来バッチ・サイズを制御するために、本システム中の全てのステージに適用される。
【００３６】
バッチング・リソース・コントローラによって提供されるバッチング（batching）に加えて、メッセージは、操作されるデータに従ってバッチングされる。各ステージは、メッセージが一緒になるようにグループ化することによって、内部的にバッチングされる。例えば、後に詳述されるブッカ・ステージ（Booker stage）は、そのメッセージが関連するアカウントに従って、メッセージをバッチングする。同じアカウント上であるいは同じマーケットで動く多数のメッセージを処理することは、各メッセージを個別に処理することに比べて、速くなりうる。
【００３７】
GB2356071Aに記載されているように、賭けの提出を望むユーザは、特定の結果が「バックする（back）」か、あるいは「レイする（lay）」、すなわち、結果が起きない方に賭けるかを選ぶことができる。特定の結果をバックする、及びレイすることへの賭けは、その後に、お互いにおけるマッチングが図られる。対向する賭けをこのようにマッチングすることにより、トランザクション処理システム２は、従来のブックメーカに対してではなく、ユーザがお互いに対して賭けることを可能にしている。このことは、賭ける人にとって、より柔軟なアプローチであり、これは、彼又は彼女が、賭けの対象にしたい的確な用語（例えば、掛け率、最大の金額）をセットできるからである。一旦提起されると、ユーザの賭けは、まだマッチしていない賭けのプールに配置される。このプールは、関連するマーケット・コントローラ１４が配置されるサーバ２００のメモリ２０１内に保存されうる。トランザクション処理システム２は、プールを探し、対向する組み合わせ（opposing match）を見つける。もし、マッチが得られなければ、すなわち、他のユーザが、ユーザによって提案された条件に対してマッチされうる賭けを提起していない場合は、その賭けは、アンマッチのプールに残される。トランザクション処理システム２における賭けマッチング（bet-matching）の手順は、以下においてさらに詳しく説明される。
【００３８】
あるユーザが、賭けマーケット１１についての特定の結果を「バックする」あるいは「レイする」ことを決定したときは、ユーザの賭けを記述するクライアント・インタフェース・サーバ４００においてメッセージが受領される。このクライアント・インタフェース・サーバ４００は、PlaceBetRequestメッセージとして参照されるメッセージを生成し、かつトランザクション処理システム２に送り込む。このメッセージは、ユーザが他の賭け者に提示したい条件の記述を与える。前記のPlaceBetRequestメッセージは、その賭けが提示されるマーケット、その賭けが特定の結果を「バックする」あるいは「レイする」ためのものかどうか、ユーザが賭けたい金額、及びユーザが賭けたい掛け率を特定する。トランザクション処理システム２は、PlaceBetRequestメッセージを処理するように、そして、好ましくは、それを、他のユーザにより提起された対向するPlaceBetRequestメッセージとマッチさせるように構成される。例えば特定の結果をバックすることを望む第１ユーザのPlaceBetRequestメッセージは、同じ結果がレイすることを望む第２ユーザのPlaceBetRequestメッセージとマッチされうる。
【００３９】
このプロセスは、図５〜１０に関連して、第１及び第２のユーザにより出された二つの対向するPlaceBetRequestメッセージの、トランザクション処理システム２を通過する流れを図示することにより、以下においてさらに詳しく説明される。
【００４０】
このプロセスは、ディレクタ３１、アカウント・コントローラ４１、６１及びマーケット・コントローラ５１としてここで参照されるいくつかのソフトウエア・モジュールに関連して記述される。アカウント・コントローラ４１、６１及びマーケット・コントローラ５１は、図４に示されるアカウント・コントローラ・モジュール１３及びマーケット・コントローラ・モジュール１４の特定のインスタンスである。
【００４１】
図５は、アカウント及びマーケット・コントローラの両者のために適用される一般的な構成を表しており、これらは、基本的なトランザクション処理アプリケーションである。これらのアプリケーションは、異なるロジックを含み、そして、異なる責任をもつけれども、それらは、共通のアプローチを共有し、トランザクションを処理する。
【００４２】
この構成は、レシーバ・スレッド・マネージャ・モジュール（レシーバ・スレッド・マネージャ）１１２の制御の下で動作するレシーバ・モジュール（レシーバ）１１０と、スケジュールド・スレッド・マネージャ１１７の制御の下で動作するアクノリッジャ・モジュール（アクノリッジャ）１１５と、ジャーナラ・モジュール（ジャーナラ）１２０と、単一のスレッド・マネージャ・モジュール（単一スレッド・マネージャ）１２２の制御の下で動作するプリプロセッサ・モジュール（プリプロセッサ）１２５と、データ・パーティション１３０と、パーティション・スレッド・マネージャ・モジュール（パーティション・スレッド・マネージャ）１４５の下で動作し、かつ、区分けされた読み取り段階１４０及び区分けされた書き込み段階１５０を備える区分けされたメッセージ・ハンドラ１４０、１５０と、スケジュールド・スレッド・マネージャ・モジュール（スケジュールド・スレッド・マネージャ）１６２の下で動作するリセンダ・モジュール（リセンダ）１６０と、単一スレッド・マネージャ１２２の下でやはり動作するディスパッチャ・モジュール（ディスパッチャ）１７０とを備えている。
【００４３】
レシーバ１１０は、ネットワークからのメッセージを読み、そしてそれらをデシリアライズ（deserialize）するように構成されている。レシーバ・スレッド・マネージャ１１２は、到来するネットワーク・イベントを待ち、そして、既定のバッチを構成するために十分なネットワーク・データが到着したときにレシーバ１１０を呼ぶ。レシーバ１１０は、メッセージの重複排除（de-duplicating）に責任を持つ。換言すると、これは、既に見たことがあるメッセージは廃棄するということである。重複排除の必要性は、後述するように、リセンダ１６０の機能から生じる。結果としてデシリアライズされたメッセージは、ジャーナラ１２０に送られる。シリアライズ（serialise）された形態のメッセージは、保持され、そして、ジャーナラ１２０に送られる。
【００４４】
ジャーナラ１２０は、サーバのハードディスク４０３又は共有ディスク６に格納されたログにメッセージを書き込むことに責任を持つ。メッセージのロギング（logging）は、失敗の場合に、ログが再生され、そして、失敗時のメモリの状態を復活できることを意味する。メッセージは、それらが処理されるのと同じ順序で再生される必要があり、これにより、確定的なリカバリを保証できる。これを達成するために、各メッセージは、ジャーナラ１２０によって一連の番号を割り当てられ、これにより、ディスパッチャに到着するメッセージは、それらがジャーナラに到着した順序に従って、再び整列（reordered）されうる。
【００４５】
プリプロセッサ１２５は、処理を区分する前に、グローバル・メッセージを単一のスレッド上で処理することによって、リカバリ・プロセスを支援する。このことは以下においてさらに説明される。もし、一つより多いジャーナラ１２０が使用されているならば、プリプロセッサ１２５は、複数のジャーナル・メッセージ・ストリームが合体して単一のシリアル・ストリームに戻る単一のポイントを提供する。プリプロセッサは、さらに、区分された全てのステージに影響する「システム・オンライン」や「システム・オフライン」のようなシリアル・メッセージを処理する。
【００４６】
ジャーナラ１２０は、プリプロセッサ１２５及びディスパッチャ１７０と同様に、単一スレッド・マネージャ１２２の下で動作する。このスレッド・マネージャは、到来キューに到着するための、バッチを形成する既定数のメッセージを待ち、その後、適切なステージを実施させる。ステージは、連続的にのみ実施され、そして、このスレッド・マネージャは、ある一時点において動作するステージについての単一のインスタンスが存在する時のみに適用される。
【００４７】
ジャーナラ１２０は、プリプロセッサ１２５を介して、区分けされた書き込み段階１５０にメッセージを送る。
【００４８】
区分けされた書き込み段階は、トランザクションのステージを扱い、そして、データ・パーティション１３０内のデータについて動作する。アカウント・コントローラの場合は、データ・パーティションは、アカウント１０を代表する。マーケット・コントローラの場合には、データ・パーティションは、マーケット１１を代表する。区分された書き込み段階は、読み取り／書き込みアプリケーション・ビジネス・ロジックを含む。例えば、図６に示されるエクスポーザ（Exposer）４４あるいはブッカ（Booker）４５は、アカウント・コントローラ・モジュールのために区分された書き込みステージであり、図６に示されるマッチャ（Matcher）５４は、マーケット・コントローラ・モジュールのための区分された書き込みステージである。
【００４９】
アカウント・コントローラ・モジュールのための他の区分された書き込みステージは、アカウント・クリエータ、アカウント・エディタ及びアカウント・デリータと、さらには賭けデリータとを含む。例えば、アカウント・クリエータは、「アカウントを作る」メッセージを受け付けて、そして、新しいアカウントを、アカウント・データ・ストラクチャの中に格納する。マーケット・コントローラに関連して、他の区分された書き込みステージは、マーケット・クリエータ、マーケット・エディタ、及びマーケット・デリータを含む。例えば、マーケット・クリエータは、「マーケットを作る」メッセージを受け付けて、そして、新しいマーケットを、マーケット・データ・ストラクチャ中に格納する。
【００５０】
パーティション・スレッド・マネージャ１４５は、区分された書き込みステージへのスレッドの割り当てを管理して、一つのアカウントあるいはマーケットあたりに割り当てられた最大のスレッドが一つであることを保証する。それは、並行性に確実性を付与することができる。つまり、このシステムは、スレッドとプロセッサにわたって規模を変化させることができる。一方で、失敗の場合における確実な応答（deterministic reply）とは、このシステムが、常に、失敗の前の状態に戻ることを意味する。
【００５１】
例えば、あるメッセージが、データＡについての読み取り／書き込み操作を実行するためのステージ１５０ａ、ｂ、ｃのうちの一つに到着すると、そのステージは、実行のためのスレッドをスレッド・プールから取得し、そして、当該データＡを、そのスレッドにおいて処理する。書き込みステージがデータＡについて操作していても、他のステージは、同じデータＡについて操作することが可能であり、それにより、変更が互いに区別され、そして、分散されたロック（distributed locks）は存在しない。データＡについての操作を実行するために到来したメッセージは、データＡについてのスレッド操作が解除されるまで、待ち行列に入れられる（queued）。区分された書き込みステージ１５０ａ、ｂ、ｃは、しかしながら、実行についての並行スレッドを用いて、他のデータについて動作することができる。これにより、同じ、あるいは異なる書き込みステージは、データＡ及びＣを、データＡと並行に操作することができる。
【００５２】
区分された読み取りステージ１４０は、レシーバ１１０からのメッセージを受け取るものであり、そして、リード・オンリー・アプリケーション・ビジネス・ロジックを含む。この場合、データ区分は、それらが区分された書き込みステージによって操作されていない限り、複数の読み取りステージによって操作されうる。例えば、パーティション・スレッド・マネージャは、もし書き込みステージがデータＡについて操作中であれば、データＡのための読み取り又は書き込み要求を待ち行列に入れる。しかしながら、もし読み取りステージがデータＡについて操作中であれば、さらなる読み取り要求は、データＡについての操作のために、スレッドを割り当てられる。同様に、受け取った書き込み要求は、現在の読み取り要求が完了するまで、待ち行列に入れられる。
【００５３】
区分された読み取りステージの例は、「ロード・アカウント（load account）」メッセージを受け付け、そして、「アカウント・ローデッド（account loaded）」メッセージを、アカウント・データ構造（account data structure）からロードされたアカウントと共に返すアカウント・ローダと、マーケットのための対応する機能を実行するマーケット・ローダとを含む。
【００５４】
リセンダ１６０は、区分された書き込みステージ１５０からメッセージを受け取る。リセンダの目的は、停止が命ぜられるまで、繰り返してメッセージをネットワークに発信することであり、これにより、下記により詳しく説明するように、メッセージを確実に引き渡すことができる。これは、失敗の場合に利点を有する。なぜなら、例えばサーバの交換によってこの失敗が修正されるまで、メッセージは、失われずに、待ち行列の中で蓄積されるからである。このメッセージは、処理されるまで持続する。リセンダは、スケジュールド・スレッド・マネージャ１６２の制御の下で動作する。このスレッド・マネージャは、その到来キューからメッセージをデキュー（dequeuing）する前に、ある程度の時間の経過を待つ。
【００５５】
ディスパッチャ１７０は、リセンダ１６０及び区分された読み取りステージ１４０からメッセージを受け取る。これは、アクノリッジャ１１５からのメッセージの場合と同じである。これらの機能については以下において説明する。それは、メッセージをシリアライズし、そして、ネットワークにそれらを書き込む。
【００５６】
ジャーナラは、失敗のイベントにおける応答のために、イベントのリドゥー・ログ（redo log）を保持しているけれども、チェックポインティング（check-pointing）が、状態を不揮発性ストレージに送る（flushing）ことにより、追加的に実行される。チェック・ポインティングは、定期的な掃除（cleaned down）をジャーナルに許可し、そして、回復時間が過大にならないために要求されるものである。失敗の場合は、状態は、最後のチェックポイントから再生されうる。
【００５７】
前記したモジュールのいずれかによって実行される操作は、並列に進行することができ、そして、レシーバから受け取ったメッセージをジャーナラが処理するのと同時に、そして、以前に受け取ったメッセージのシリアライジングをディスパッチャが行うと同時に、レシーバは、メッセージの読み取りとデシリアライジング（deserialising）とを行う。
【００５８】
サーバ間における保証されたメッセージ引き渡し（guaranteed message delivery）を提供するために使われるプロセスが、図６ａ〜ｃに表示されている。例えば、図６ａに示される正常な動作では、サーバＡのディスパッチャ１７０は、送信カウンタに従って、メッセージ・シーケンス値を設定する。例えば、シーケンス値を「１」に設定する。そして、このディスパッチャは、メッセージをサーバＢのレシーバ１１０に送り、（ステップｓ１００）そして、メッセージが再送信される必要があれば、それをバッファに保存する（ステップｓ１０１）。受け取りに際して、サーバＢのレシーバ１１０は、受け取りカウンタをインクリメントする（ステップｓ１０２）。サーバＡは、第２のメッセージ２をサーバＢに送り（ステップｓ１０３）、そして、メッセージを保存する（ステップｓ１０４）。受け取りに際して、サーバＢは、その受け取りカウンタをインクリメントする（ステップｓ１０５）。サーバＢにおけるアクノリッジャ１１５は、受け取り確認されないメッセージを定期的に取り出すことを実行し、そして、受け取り確認メッセージであるＡＣＫをメッセージのために生成する。そして、この例では、アクノリッジャ１１５は、第１のメッセージのために、サーバＡに（ディスパッチャ１７０を介して）ＡＣＫメッセージを送る（ステップｓ１０６）。サーバＡは、メッセージ１及び２を、そのバッファからクリアし、そして、送信カウンタを、２の値にインクリメントする。次の送信については、ディスパッチャは、次のシーケンス番号、このケースであれば値「３」を、メッセージに割り当てる。
【００５９】
メッセージを失った場合が図６ｂに表されている。再び、サーバＡのディスパッチャ１７０は、シーケンス番号１を有するメッセージを、サーバＢのレシーバ１１０に送り（ステップｓ１１０）、そして、メッセージが再送信されるべきものであれば、そのメッセージをバッファに保存する（ステップｓ１１１）しかしながら、メッセージは、送信中に失われる。すると、サーバＡは、メッセージ２をサーバＢに送り（ステップｓ１１２）、そして、メッセージを保存する（ステップｓ１１３）。メッセージが受領された後、サーバＢは、その受け取りカウンタが零に設定されていることに気づくが、その一方で、メッセージ番号は２である。したがって、レシーバは、「受け取っていない」ＮＡＣＫメッセージを生成する。このメッセージは、ディスパッチャによって、カウンタ「０」を含むサーバＡに戻すように送信される（ステップｓ１１４）。サーバＡのリセンダ１６０は、ＮＡＣＫメッセージに応答して、０より大きいカウンタを備える全てのメッセージを再送信する。このことは図６ａに示されている（ステップｓ１１５）。
【００６０】
図６ｃは、重複排除（de-duplication）のプロセスを表す。第１及び第２のメッセージは、図６ａのステップｓ１００〜ｓ１０５に示されているように、成功のうちに送信されている（ステップｓ１２０〜ｓ１２５）。その結果、サーバＢの受け取りカウンタは、「２」に設定されている。そして、サーバＢのアクノリッジャ１１５は、確認メッセージＡＣＫを生成し、それを（ディスパッチャ１７０を介して）サーバＡに送る（ステップｓ１２６）。しかしながら、このメッセージは、移送中に失われた。タイムアウト期間内にＡＣＫメッセージを受け取らない場合は、サーバＡは、メッセージ１を再送信する（ステップｓ１２７）。サーバＢは、このメッセージを受け取る。しかしながら、その受け取りカウンタは２であり、それは、それがこのメッセージを既に受け取っていることを認識し、それを廃棄する（ステップｓ１２８）。同様のプロセスがメッセージ２について発生する（ステップｓ１２９、ｓ１３０）。サーバＢは、カウンタ２を含むＡＣＫメッセージを送り（ステップｓ１３２）、サーバＡは、そのバッファをクリアし、そして、その送信カウンタを２に設定する（ステップｓ１３２）。それから、このプロセスは、図６ａに示されるように続く。
【００６１】
図７は、賭け要求メッセージ（bet request message）を処理するために相互作用する様々なモジュールの間の相互関係を表示する。以下に、より詳しく説明されるように、これらのモジュールは、異なるサーバ上で動作する。以下の説明から明らかなように、トランザクションは、クライアントとサーバとの間での接続が設定され、そして、通信が、それらの間において、あちこちで通過するようなクライアント−サーバ・モデルを使っては処理されていない。代わりに、クライアントは、第１のノードあるいはサーバにメッセージを渡す。もしさらなる処理が要求されていれば、第１のサーバは、そのメッセージを第２のサーバに取り次ぎ、そして、第３のサーバにと、順次取り次ぐ。これは、要求されたトランザクションに関係するメッセージがクライアントに戻されるまで行われる。
【００６２】
例えば、アカウント・コントローラ・インスタンスを実行するサーバのようなモジュールが失敗する場合、メッセージは失われないが、しかし、この欠陥が、例えばサーバの交換により修正されるまで、メッセージはキューの中に蓄積される。
【００６３】
図７及び８を参照して、第１のユーザが賭けの提起を望むときには、第１の「PlaceBetRequest」メッセージが、ここではイニシエータとして参照されるソフトウエア・モジュール２１により生成される（ステップｓ１）。この「PlaceBetRequest」メッセージは、ユーザのユーザ・アカウントのＩＤ、賭けを提起したいマーケットのＩＤ、ユーザが賭けをし、「バック」または「レイ」のいずれを望むかについての結果のＩＤ、賭けをしたい金額、そして彼らが賭けをしたい掛け率のようなデータを含む。
【００６４】
図８を参照して、イニシエータ２１は、例えばＪ２ＥＥアプリケーション・サーバのようなアプリケーション・サーバ４００ａの上で動く。それは、クライアント・インタフェース・サーバとして動作するサーバ４００のクラスタ内の一つであ。このクライアント・インタフェース・サーバ４００のクラスタは、賭け要求をトランザクション処理システム２に投入することについて責任を持つ。クライアント・インタフェース・サーバ４００のクラスタは、例えばユーザの賭け可能なバランスをロードする要求やユーザの現在有効な賭けを見る要求のような、賭けシステムに関連する他の要求及びメッセージを投入することにも責任を持つ。
【００６５】
生成された「PlaceBetRequest」メッセージが、イニシエータ２１により作られた他のメッセージあるいは要求と共に到来キューに置かれ、そして、ここでエグゼクティブ（Executive）として参照されるソフトウエア・モジュールに向けられる。ここで、このモジュールは、イニシエータ２１と同じクライアント・インタフェース・サーバ４００ａ上で動作する。これらのステージの第１は、エグゼキュータ２３として参照される処理ステージであり、これは、「PlaceBetRequest」によって実施される。エグゼクティブ２２は、レシーバ２４として参照される処理ステージと、ディスパッチャ２５として参照される処理ステージとをさらに備える。エグゼキュータ２３は、バッチ中の到来メッセージ・キューからメッセージをデキュー（dequeue）し、そして、スレッド・マネージャ・アプリケーション（図示せず）によって割り当てられたスレッドについてのメッセージを処理するように構成されている。スレッド・マネージャは、トランザクション処理サーバ２００の一つに配置されうる。スレッドが割り当てられる方法は、図５を参照しながら、上記において既に説明された。
【００６６】
トランザクション処理システム２における、非同期要求の処理についての詳しい記述が以下において提供される。
【００６７】
「PlaceBetRequest」メッセージは非同期要求である。非同期要求を使うことは、エグゼクティブ２２のエグゼキュータ２３からの確認メッセージを、計画された操作を再開する前に、イニシエータ２１が待つ必要がないことを意味する。非同期メッセージングは、以下で説明されかつ、図７〜１１に示されるトランザクション処理システム２の全てのステージで使用されうる。
【００６８】
「PlaceBetRequest」メッセージを含むメッセージのバッチ中におけるメッセージの数は、前記で言及したバッチング・リソース・コントローラ（ＢＲＣ）としてここで参照されるソフトウエア・モジュールにより制御される。
【００６９】
図７を参照して、受け取られた「PlaceBetRequest」メッセージは、エグゼキュータ２３によってディスパッチャ２５に送られる（ステップｓ２）。エグゼキュータ２３がこれを行うのは、ディスパッチャ２５の到来キューの中の「PlaceBetRequest」メッセージを、ディスパッチャ２５に向けられた他の要求あるいはメッセージと共にエンキューすること（enqueueing）によってである。これらの他の要求あるいはメッセージは、イニシエータ２１から発することもできる。「PlaceBetRequest」メッセージが非同期要求であるために、エグゼキュータ２３は、その動作を続けることができる。それは、ディスパッチャ２５からの確認メッセージを待つ必要はない。
【００７０】
ディスパッチャ２５は、到来キューからのメッセージのバッチ中における「PlaceBetRequest」メッセージをデキューする。バッチのサイズは、ここでバッチング・リソース・コントローラ（Batching Resource Controller）２５ａとして参照されるコントローラ・モジュール２５ａにより決定され及び表示される。このモジュールは、ディスパッチャ２５と関連付けられている。このコントローラ・モジュールは、ディスパッチャ２５の動作を監視し、そして、それぞれのメッセージ・バッチ中で処理される要求及びメッセージの数を調整するように構成されている。このことは、バッチング・リソース・コントローラ（Batching Resource Controller）２３ａに関連して、上記において説明した。バッチ中のメッセージ及び要求のデキューイングは、ディスパッチャ２５（及びトランザクション処理システム２における他の全てのステージ）がメッセージのスループットを最大化することを可能にする。なぜなら、バッチ中の多数の要求とメッセージの処理が、キャッシュの局在化（cache locality）とタスクの集中（task aggregation）を可能にするからである。しかしながら、上に述べたように、もしバッチング・ファクタ（batching factor）が大きすぎるならば、ユーザのための応答時間（ユーザは、彼らの賭け要求に対する応答を待っている）は、非常に長くなる。
【００７１】
トランザクション処理システム２における全てのバッチング・リソース・コントローラは、同様に動作する。しかしながら、バッチングは、到着したステージに応じて、異なる基準に基づいて実行されることもできる。例えば、レシーバ・ステージでは、バッチングは、ネットワークの待ち時間に基づくことができる。また、ジャーナラにおいては、それは、ディスクの待ち時間に基づくことができる。一方、エクスポーザでは、それは、アカウント毎の要求の数に基づくことができる。この例では、個別のバッチング・リソース・コントローラが各ステージと関連付けられている。しかしながら、他の形態では、単一のバッチング・リソース・コントローラが各サーバについて存在し、このコントローラは、そのサーバについての全てのバッチング動作の制御に責任を持つ。バッチング・リソース・コントローラは、この実施形態における各ステージと関連するので、明瞭化のために示されていない。以下の説明では、用語「送信する」（forwarding）及び「受信する」（receiving）という用語を用いて動作が説明されるけれども、理解されるべきこととして、これらの動作は、キューイング及びバッチ・コントロールを含む。
【００７２】
ディスパッチャ２５によりデキューされたメッセージは、それらがバッチにおいて処理されるように、グループに分割される。「PlaceBetRequest」メッセージは、イニシエータ２１に「PlaceBetRequest」メッセージを生成させたユーザのユーザ・アカウントに割り当てられたアカウント・コントローラ４１に向けられた他のメッセージと共に、バッチにまとめられる。バッチに割り当てられた他のメッセージは、他の「PlaceBetRequest」メッセージ、ユーザの賭け可能なバランスを見るためのリクエストなどを、既に説明したように、含みうる。
【００７３】
このステージでは、エグゼクティブ２２は、図４に示されるアカウント・コントローラ１３のうちのどれがユーザのユーザ・アカウント１０に割り当てられるかを知らず、そして、このため、「PlaceBetRequest」メッセージをどこに向けて発送すべきか知らない。ディスパッチャ２５は、したがって、正しいアカウント・コントローラ４１を確かめるために、「LocateInstanceRequest」メッセージを生成する（ステップｓ３）。その間、「PlaceBetRequest」メッセージは、その後の送信のために、エグゼクティブ２２に保存される。例えば、「PlaceBetRequest」メッセージは、クライアント・インタフェース・サーバ４００ａに配置されたメモリ４０２内に保存されうる。上で述べたように、「PlaceBetRequest」メッセージを含むバッチ中の全てのメッセージは、同じアカウント・コントローラ４１に向けられ、そして、したがって、ただ一つの「LocateInstanceRequest」メッセージが、そのバッチのために、生成される必要がある。この「LocateInstanceRequest」メッセージは、ディレクタ３１に向けられた他のメッセージ（例えば、他のユーザ・アカウントに関連する「LocateInstanceRequest」メッセージ）と共にキューにエンキューされる。
【００７４】
ディレクタ３１は、レシーバ・ステージ３２、ロケータ・ステージ３３及びディスパッチャ・ステージ３４とを備えている。それはさらに、他のモジュールの場合と同様にジャーナラ（図示せず）を備えているが、これは明瞭さのために省略されている。図８を参照して、ディレクタ３１は、サーバ２００ｇ上で動くことができ、そのサーバは、トランザクション処理サーバ２００のクラスタの一つである。レシーバ３２は、メッセージのバッチ中の「LocateInstanceRequest」メッセージをデキューする。
【００７５】
レシーバ３２は、キューの中の「LocateInstanceRequest」メッセージを、ロケータ３３に向けられた他のメッセージと共に、エンキューする（ステップｓ４）。それから、ロケータ３３は、メッセージのバッチ中におけるこのキューからの「LocateInstanceRequest」メッセージを、例えば他の「LocateInstanceRequest」メッセージと共に、バッチング・リソース・コントローラ３３ａの制御の下で、デキューする。ロケータ３３は、ディレクタ３１が配置されたサーバ２００ｇのメモリ２０２に記録されたリストからの「LocateInstanceRequest」メッセージにおいて特定されたユーザ・アカウントに割り当てられたアカウント・コントローラ４１のアドレスをルックアップするように、構成される。そして、ロケータ３３は、割り当てられたアカウント・コントローラ４１のアドレス情報を含む「LocateInstanceReply」メッセージを作り出し（ステップｓ５）、そして、そのメッセージを、ディレクタ３１のディスパッチャ・ステージ３４に向けられた他のメッセージと共にエンキューする。
【００７６】
「LocateInstanceReply」メッセージは、ディスパッチャ３４によりデキューされ、そして、エグゼクティブ２２のレシーバ２４に向けられた他のメッセージと一緒に、キューにエンキューされる（ステップｓ６）。レシーバ２４によって一旦デキューされると、「LocateInstanceReply」メッセージは、ディスパッチャ２５の到来キューに送られる（ステップｓ７）。
【００７７】
このステージでは、保留されている「LocateInstanceReply」メッセージの起因となった「PlaceBetRequest」メッセージは、クライアント・インタフェース・サーバ４００ａのメモリ４０１から引き出され、そして、「LocateInstanceReply」メッセージで特定されたアカウント・コントローラ４１に送られる。アカウント・コントローラ４１のアドレスは、さらなるルックアップを避けるために、エグゼクティブ２２によりキャッシュされる。アカウント・コントローラは、トランザクション処理サーバ２００の一つであるサーバ２００ａ上で動作することができる。サーバ２００ａは、ユーザのユーザ・アカウントに関連する全てのデータが保存されるサーバである。
【００７８】
エグゼクティブ２２及びディレクタ３１と同様に、アカウント・コントローラ４１は、レシーバ・ステージ４２及びディスパッチャ・ステージ４６を備える。アカウント・コントローラ４１は、さらに、ジャーナラ・ステージ４３と、エクスポーザ・ステージ（Exposer stage）４４と、そして、ブッカ・ステージ（Booker stage）４５とを備える。「PlaceBetRequest」メッセージは、レシーバ４２によって受け取られ（ステップｓ８）、そして、ジャーナラ４３の到来キューに向けて送られる（ステップｓ９）。
【００７９】
アカウント・コントローラ４１の処理ステージは、エグゼクティブ２２及びディレクタ３１のステージに関連して上に記載したものと同様に動作する。メッセージは、メッセージの到来キューからデキューされる。到来キューにおけるメッセージは、先行する処理ステージによって、そこに配置されている。さらに、メッセージは、処理されて、そして、次のステージの到来キューに配置されるか、あるいは、次のステージの到来キューに配置される新しいメッセージを作り出すために使われる。これらのプロセスは、エンキューイングあるいはデキューイングとしてここで一般的に言及される。
【００８０】
ジャーナラ４３において、「PlaceBetRequest」メッセージは、例えば共有ハードディスク６において保存されうる不揮発ログに追記される。あるいは、それは、各サーバ２００内のハードディスク２０３に保存されうる。これにより、各サーバ２００におけるログに保存された情報を取り出す速度が向上する。もし必要なら、応答のために、「PlaceBetRequest」メッセージには、固有のシーケンス番号が、ログにおいて付与される。
【００８１】
このようにして受領メッセージをジャーナリングすることは、次のことを意味する。すなわち、システム欠陥の場合には、トランザクション処理システム２は、確定的なポイント、すなわち、アカウント・コントローラ４１のジャーナラ４３によって受領メッセージが最後に記録されたステージに戻ることができる。「PlaceBetRequest」メッセージは、ジャーナラ４３からエクスポーザ４４に送信される（ステップｓ１０）。
【００８２】
エクスポーザ・ステージ４４では、「PlaceBetRequest」は、賭け（bet）についての最大に可能な損失（exposure）を計算するために、処理される。これは、ユーザが特定の結果をバックあるいはレイしたときのユーザの最大の責任を決定する計算である。例えば、もし、賭けが、特定の結果を、２／１の掛け率（３のデジタル掛け率）で、５ポンドの掛け金において、「バックする」ことであれば、ユーザは、もし彼らが賭けに負ければ、５ポンドを失うことになる。しかしながら、もし、賭けが、特定の結果を、２／１の掛け率で、最大５ポンドの賭けで「レイする」ことであれば、ユーザは、もし賭けに負ければ、１０ポンドを失うことになる。
【００８３】
損失の計算は、エクスポーザ４４によって実行され、そして、バッチにおいて処理される。したがって、もし、特定のユーザ・アカウントのために複数の「PlaceBetRequest」メッセージがあれば、全ての賭けの損失は、単一の操作で計算される。
【００８４】
エクスポーザ・ステージ４４は、ユーザのユーザ・アカウントにおける賭け可能なバランスに対して計算された損失をチェックする。もし、ユーザ・アカウントが、ユーザの有効な賭けについての損失をまかなうに十分な金額を含むのであれば、エクスポーザ４４は、「MatchBetRequest」メッセージを作り出し、そして、この「MatchBetRequest」メッセージをディスパッチャ４６に送り出す（ステップｓ１１）。もし、ユーザ・アカウントが、賭けの損失をまかなうに十分な金額を含まないのであれば、メッセージは、エグゼクティブ２２及びイニシエータ２１を介してユーザに戻され、これによって、ユーザは、利用できる資金が不十分であることを知らされる。
【００８５】
ディスパッチャ４６におけるプロセスは、エグゼクティブ２２のディスパッチャ２４を参照して前記したそれに類似している。アカウント・コントローラ４１は、どのマーケット・コントローラ１４が、「MatchBetRequest」により特定された賭けマーケット１１に割り当てられたかを知らない。ディスパッチャ４６は、したがって、「LocateInstanceRequest」メッセージを生成し、そして、ディレクタ３１にそれを送る（ステップｓ１２）。これは、メッセージをロケータ３３に送るものである（ステップｓ１３）。ロケータ３３は、割り当てられたマーケット・コントローラ５１をリストからルックアップする。その方法は、アカウント・コントローラ４１のルックアップに関連して前記したところと同様である。その間、「MatchBetRequest」メッセージは、アカウント・コントローラ４１中に、その後の送信のために保存される。「MatchBetRequest」は、例えば、アカウント・コントローラ４１が配置されるサーバ２００に配置されたＲＡＭ２０２中に保存されうる。割り当てられたマーケット・コントローラ５１は、ロケータ３３により配置される。そしてそれは、「LocateInstanceReply」メッセージをディスパッチャ３４に送る（ステップｓ１４）。マーケット・コントローラ５１のアドレスは、ディレクタ３１のディスパッチャ３４により生成された「LocateInstanceReply」メッセージ中のアカウント・コントローラ４１のレシーバ４２に送られる（ステップｓ１５）。
【００８６】
そして、「LocateInstanceReply」メッセージは、アカウント・コントローラ４１のレシーバ４２により、ディスパッチャ４６に送られる（ステップｓ１６）。このポイントでは、「LocateInstanceRequest」メッセージを誘起する、保留の「MatchBetRequest」は、サーバ２００上のメモリ２０１から引き出され、そして、ディスパッチャ４６により、正しいマーケット・コントローラ５１に送付される（ｓ１７）。アカウント・コントローラ４１の場合と同じように、マーケット・コントローラ５１のアドレスは、エグゼクティブ２２によりキャッシュされ、これにより、そのアドレスを再びルックアップする必要がないようにしている。
【００８７】
図８に示されるように、マーケット・コントローラ５１は、トランザクション処理サーバ２００の一つであるサーバ２００ｄ上に配置され、そして、レシーバ・ステージ５２、ジャーナラ・ステージ５３、マッチャ・ステージ（Matcher stage）５４、及びディスパッチャ・ステージ５５を備える。マーケット・コントローラ５１におけるこれらのステージは、メッセージのエンキュー及びデキューを行うものであり、これらは、エグゼクティブ２２、ディレクタ３１，及びアカウント・コントローラ４１に関連して説明したところと同様である。「MatchBetRequest」メッセージは、レシーバ５２により受け取られ、そして、ジャーナラ５３に送られる（ステップｓ１８）。ジャーナラ５３においては、「MatchBetRequest」メッセージは、例えばハードディスクに保存された不揮発性ログに追記される。このことは、アカウント・コントローラ４１のジャーナラ４３における「PlaceBetRequest」メッセージのロギングに関連して説明したところと同様である。既に説明したように、不揮発性ログは、例えば、マーケット・コントローラ５１が配置されるサーバ２００ｄ上や、あるいは、共有ディスク６や、あるいは、マーケット・コントローラ５１にネットワーク接続経由で接続された他のディスクに保存されてもよい。「MatchBetRequest」メッセージは、それから、マッチャ５４に送られる（ステップｓ１９）。
【００８８】
マッチャ５４においては、「MatchBetRequest」メッセージは、マッチャ５４を、賭けマーケット３に既に提起されていたマッチしていない賭け（unmatched bets）のプールを通しての調査へのきっかけとさせる。マッチしていない賭けは、例えば、サーバ２００ｄの一部であるメモリ２０２中に保存されうる。調査の目的は、「MatchBetRequest」メッセージにより提供された条件の賭けに対向する条件を提供する賭けを見つけることである。この例では、賭けプールは空であり、そのため、マッチできる賭けはみつからない。ユーザの賭けは、したがって、マッチしていない、未修整の（unmodified）賭けのプールに追加される。それから、マッチャ５４は、その賭けのためのマッチング・プロセスに関する情報を記述する「MatchBetReply」メッセージを生成する。このケースでは、プールが空なので、「MatchBetReply」メッセージは、その賭けのために適用可能な一致（match）はないということを記述する。
【００８９】
賭けのマッチングは、バッチにおいて実行される。もし、複数の「MatchBetRequests」が特定の賭けマーケット１１について存在するときは、全ての「MatchBetRequests」のためのマッチング・プロセスは、単一の操作で実行される。
【００９０】
「MatchBetReply」メッセージは、マッチャ５４によりディスパッチャ５５に送られ（ステップｓ２０）、それは、今度は、そのメッセージを、アカウント・コントローラ４１のレシーバ４２に送る（ステップｓ２１）。レシーバ４２は、「MatchBetReply」メッセージをジャーナラ４３に送り（ステップｓ２２）、そこでは、「MatchBetReply」メッセージは、ブッカ４５に送られる前に、不揮発性ログに付記される（ステップｓ２３）。
【００９１】
ブッカ４５においては、「MatchBetReply」メッセージに含まれる情報は、例えば、ユーザの賭けの状態を、「未処理」（unprocessed）から「処理済み」（processed）にアップデートするために使われる。さらに、ブッカ４５は、様々な一致情報を保存するように構成される。しかしながら、「MatchBetReply」メッセージの場合には、適切な「MatchBetRequests」が賭けプール内にないので、一致情報がない。ユーザの賭けの状態は、例えば、アカウント・コントローラ４１を実行させるサーバ２００ａにおけるＲＡＭのようなメモリ２０２内に保存されうる。ブッカ４５は、「PlaceBetReply」メッセージを生成し、そして、それを、ディスパッチャ４６に送る（ステップｓ２４）。ディスパッチャ４６からは、この「PlaceBetReply」が、エグゼクティブ２２のエグゼキュータ２３に、レシーバ２４を介して送られる（ステップｓ２５、ｓ２６）。
【００９２】
このポイントでは、「PlaceBetReply」メッセージが、イニシエータ２１の到来キューに置かれ、デキューを待つ（ステップｓ２７）。そして、賭けを提起した結果は、イニシエータ２１を介して、ユーザに返されうる。
【００９３】
図９及び１０を参照して、第２のユーザは、第１のユーザにより提起された賭けに対向して、ユーザ・ウエブサイトを介して、賭けを提起する。これは、第２の「PlaceBetRequest」メッセージを、エグゼクティブ２２のエグゼキュータ２３内に送り込ませる（ステップｓ１）。第２の「PlaceBetRequest」メッセージは、トランザクション処理システム２を通る経路を辿る。このことは、第１のユーザの賭けに関連する「PlaceBetRequest」メッセージの経路に関して説明したところと同様である。ステップｓ１〜ｓ１９は、前記したところと同様である。
【００９４】
マーケット・コントローラ５１内のマッチャ５４に到達すると、第２のユーザの賭けに関連する「MatchBetRequest」メッセージは、マッチャ５４が、ＲＡＭ２０２中における一致しない賭けのプール中の「MatchBetRequest」メッセージに対する可能な一致を見つけるための調査の契機となる。これは、第１のユーザの賭けに関連する「MatchBetRequest」メッセージに関して既に説明したとおりである。ここでは、前記した調査が成功し、そして、第２のユーザの賭けに関連する「MatchBetRequest」が、第１のユーザの賭けに関連する第１の「MatchBetRequest」に一致している。
【００９５】
その後、マッチャ５４は、その一致に関係する情報を記述する「MatchBetReply」メッセージを生成し、そして、この「MatchBetReply」メッセージをディスパッチャ５５に（ステップｓ２０ａ）、そして、第２のユーザのユーザ・アカウントに割り当てられたアカウント・コントローラ６１のレシーバ６２に送る（ステップｓ２１ａ）。図１１を参照して、アカウント・コントローラ６１は、サーバ２００ｂ上に配置される。このサーバは、トランザクション処理システムを形成するサーバ２００のネットワークの一つである。このサーバ２００ｂは、第２のユーザのユーザ・アカウントに関連する全ての情報が、例えばＲＡＭ２０２内に保存されるサーバである。
【００９６】
それから、「MatchBetReply」メッセージは、トランザクション処理システム２を、図９に示すようにして流れる。このことは、第１のユーザの賭けに関連する「MatchBetReply」メッセージの流れに関して説明したところに類似している。特に、「MatchBetReply」メッセージは、ジャーナラ６３により不揮発性メモリ２０３内に保存され、そして、ブッカ６５に送られる。これは、アカウント・コントローラ６１内の第２の賭けの状態を「未処理」から「処理済み」にアップデートするものである。ブッカ６５は、さらに、「MatchBetReply」メッセージに含まれる位置情報を保存し、そして、「PlaceBetReply」メッセージを構築する。このメッセージは、ディスパッチャ６６並びにエグゼクティブ２１のレシーバ２３及びエグゼキュータ２２を介して、イニシエータ２１に送られる（ステップｓ２４〜ｓ２７）。
【００９７】
それから、「PlaceBetReply」は、クライアント・インタフェース・サーバ４００ａ上のイニシエータ２１を介して中継されて、ユーザのウエブページに戻される。これは、第１及び第２のユーザに、彼らの賭けを対向する賭けに一致させることに成功したという確認を提供する。
【００９８】
前記した「MatchBetReply」メッセージを生成することに加えて、マッチャ５４は、マーケット・コントローラ５１のディスパッチャ５５に送られる「MatchedBetEvent」メッセージを追加的に生成する（ステップｓ２０ｂ）。「MatchedBetEvent」メッセージは、第１のユーザのユーザ・アカウントに割り当てられたアカウント・コントローラ４１に送られるべきものであり、これによって、それに対して、第１のユーザの賭けに関連する「PlaceBetRequest」メッセージが一致に成功したことを知らせることができる。しかしながら、このステージでは、マーケット・コントローラ５１は、第１のユーザのユーザ・アカウントに関連するアカウント・コントローラ４１のアドレスを知らない。「MatchedBetEvent」メッセージは、したがって、マーケット・コントローラ５１において、例えば、サーバ２００ｂのメモリ２０２内に保存され、そして、ディスパッチャ５５は、ディレクタ３１によりアクセスされるリストからアカウント・コントローラ４１のアドレスをルックアップするために、「LocateInstanceRequest」メッセージを生成する（ｓ２１ｂ）。このリストは、ディレクタ３１が配置されたサーバ２００ｇの一部として備えられたＲＡＭ２０２に保存されうる。
【００９９】
「LocateInstanceRequest」メッセージは、レシーバ３２により受け取られ、そして、アカウント・コントローラ４１のアドレスをルックアップするために、ロケータ３３に送られる（ｓ２２ｂ）。ロケータ３３は、アカウント・コントローラ４１のアドレスを含む「LocateInstanceReply」メッセージを生成し、そして、それを、ディスパッチャ３４を介して、レシーバ５２に送る（ステップｓ２３ｂ、ｓ２４ｂ）。マーケット・コントローラ５１のレシーバ５２は、それから、「LocateInstanceReply」メッセージをディスパッチャ５５に送る（ステップｓ２５ｂ）。この段階では、保留中の「MatchedBetEvent」メッセージが、メモリ２０１から取り出され、アカウント・コントローラ４１のレシーバ４２に送られる（ステップｓ２６ｂ）。アカウント・コントローラ４１のアドレスは、将来において再びそれをルックアップする必要を避けるために、マーケット・コントローラ５１によりキャッシュされる。
【０１００】
受け取られた「MatchedBetEvent」メッセージは、ジャーナラ４３に送られ（ステップｓ２７ｂ）、そして、それは、前記したような方法で、固有の参照番号と共に不揮発性ストレージに付記される。「MatchedBetEvent」メッセージは、それから、ブッカ４５に送られ（ステップｓ２８ｂ）そして、アカウント・コントローラ４１についての賭けの状態をアップデートするために使われる。このデータは、アカウント・コントローラ４１を実行するサーバ２００ａのＲＡＭ２０２内に保存されうる。
【０１０１】
この方法では、第１および第２のユーザにより提起された賭けは共に一致に成功している。
【０１０２】
トランザクションが処理されると、トランザクション処理システム内において保持されているデータは、速やかに変化する。新しいデータは、依頼者に通知される必要がある。例えば、マーケットの見込み（market view）は、ユーザのためにアップデートされる必要がある。これらの変更は、情報を必要とする依頼者に伝えられる。これは、依頼者の要求に応答することによってでなく、デルタ（deltas）として参照される現在のデータへの変更を依頼者にプッシュすることによる。
【０１０３】
前記した実施形態及びその変形例は、トランザクション処理システムによって提供される効果を達成するために、単独で、あるいは組み合わせて使用されうる。
【０１０４】
本発明に基づく前記したシステムは、トランザクション処理システムのＡＣＩＤ原則に従う。これらは、トランザクションが以下の特性を持つ必要があるということである：
【０１０５】
原子性（Atomicity）。最小単位（atomic）のトランザクションは、全ての操作が成功するか又はしないかという、一連の操作である。もし、このような一連の操作が、完成の前に、あるポイントで失敗すると、その失敗の前に終了しているあらゆる操作は、ロールバックされる必要がある。本発明に基づくトランザクション処理システムでは、トランザクションは前もって知られており、そして、全ては不揮発性メモリに保存されている。従来のシステムと異なり、ロギングは、操作レベルというよりもむしろ、トランザクション・レベルで発生する。そのため、全ての完了した操作がログされるＵＮＤＯロギングの必要がない。そして、ＵＮＤＯログは、不揮発性ストレージから、トランザクションが完了する前に書き込まれた変更を除去するために検査される。
【０１０６】
一例として、「賭けを提起する」（bet placement）トランザクションがログされる一方、その下にある一連の操作、例えば「古いエクスポージャを書き込む」、「新しいエクスポージャを書き込む」、「新しい賭けを書き込む」などはログされていない。
【０１０７】
トランザクションが補足され、実行が開始され、そして、トランザクションにおける全ての操作が完了する前に失敗がある場合は、その状態は捨てられ、そして、ＲＥＤＯログとしても知られるジャーナルは、状態を復元するために再生される。
【０１０８】
ログの再生による状態の復元を確実に成功させるために、これらのステージは、確定的（deterministic）とされる。例えば、賭けは、特定の注文において到着し、そしてログされる。以下を仮定する：
１．賭け１（１０ポンド）
２．賭け２（１５ポンド）
３．賭け３（２０ポンド）
【０１０９】
確定的な手法で処理した後、単一の可能な状態は以下の通りである：
１．賭け１（１０ポンドが賭け２とマッチ）
２．賭け２（１０ポンドは賭け１とマッチ、５ポンドは掛け３とマッチ）
３．賭け３（５ポンドは掛け２とマッチ、１５ポンドはマッチしない）
【０１１０】
明確なこととして、賭けマッチング・ステージは、非確定的であり、多数の状態が可能であり得る。例えば、賭け１と２とが処理される前に賭け３が処理されていたとすれば、可能な状態は以下の通りである：
１．賭け１（１０ポンドが賭け３とマッチ）
２．賭け２（１０ポンドは賭け３とマッチ、５ポンドはマッチしない）
３．賭け３（１０ポンドは掛け１とマッチ、１０ポンドは賭け２とマッチ）
【０１１１】
ログ応答は時間を消費するプロセスでありうるので、本発明におけるいくつかの形態は、例えばログ・テイリング（log tailing）のような利用性の高い機構を含む。
【０１１２】
一貫性（Consistency）。これは、アプリケーションが規定する完全性の制約について違反があってはならないことを意味する。あるトランザクションが実行される前に、あるシステムが一貫する状態（consistent state）にあるとすると、それは、その後においても、一貫した状態にある必要がある。
【０１１３】
例えば、もし、あるユーザが１０ポンドのための賭けを持つとすれば、マッチした部分とマッチしない部分の合計は１０ポンドでなければならない。
【０１１４】
本発明に基づくシステムの実施形態では、弱い一貫性が適用される。このシステムは、結局のところは一貫することになるけれども、時間的なある一瞬においては、それは不一致となりうる。例えば、あるアカウント・コントローラは、不一致である１０ポンドの賭けの記録を持ちうるし、あるマーケット・コントローラは、その掛けのうち５ポンドがマッチしたとの記録を持ちうる。このアカウント・コントローラは、５ポンドの一致あるいは不一致の記録を持たないけれども、マーケット・コントローラから移動中の、このマッチを記述するメッセージは、アカウント・コントローラが結果的に、マッチされ及びマッチしない５ポンドの価額を記録することを意味する。このことは、既に説明したように、状態及びメッセージングの保証によって保証されている。
【０１１５】
独立性（Isolation）。この特性は、複数の実行中の動作が重ならないことに言及するものであり、これにより、それらが同時に実行されたとしても、それらは順次実行されるように見える。トランザクション処理システムにおける多くの機能は、アカウント及びイベントへの排他的なアクセスを要求する。独立性を達成するためには、実行ユニットが個別のエンティティに割り当てられる。それにより、アクセスは固有的にシリアライズされ、そして、トランザクションは他のそれとは独立とされる。例えば、単一の実行ユニットは、特定データの一部への独占を取得しそして解放するクライアントのセッションに対向して、特定のアカウントあるいは特定のマーケットを持つことができる。
【０１１６】
耐久性（Durability）。トランザクションが成功して、一旦完了すると、それは、例えシステムがシャットダウンしても、失われてはならない。変更は、したがって、ディスクに書き込まれ、あるいはジャーナルされる。上において説明したように、フル・トランザクションのみがこの手法でログされるのであり、このトランザクションを構成する個別の動作はそうされない。
【０１１７】
メッセージ・カウンタは、やはりログされ、メッセージの紛失、不調あるいは重複のために提供される。
【０１１８】
前記した実施形態への変更及び変化は熟練者には明白であるが、それらは、請求の範囲の中に入る。
【技術分野】
【０００１】
本発明は、トランザクション処理（transaction processing）に関しており、特に、しかし制限的ではなく、賭け取引を処理するための方法及び装置に関連するものである。
【背景技術】
【０００２】
トランザクション処理システムは様々な環境中で使用されており、それは、株式取引システム、旅行予約システム、及び、オンライン賭け取引所（online betting exchanges）のような賭けシステムを含む。高速なトランザクション処理システムへの要求が高まるにつれて、従来のシステムは、要求される処理速度を提供しようと努力することになる。
【発明の概要】
【０００３】
本発明によれば、分散された複数のノードを備えるシステムにおけるトランザクション処理の方法が提供される。ここでは、データは、複数のデータ・パーティションの中に保持される。それぞれのパーティション中のデータは、それぞれの単一のノードに関連付けられる。このシステムは、データ・パーティションのグループを制御するための複数のコントローラを含む。それぞれのコントローラは、データ・パーティション中のデータについての処理を実行するための、複数の書き込み段階（write stage）と、実行のスレッド（threads of execution）を書き込み段階に割り当てるためのスレッド・マネージャとを備える。ここで、スレッド・マネージャは、所定のデータ・パーティション中におけるデータ操作のために、最大でも、単一のスレッドを割り当てるように構成されている。この方法は、複数のコントローラ中の第１のものにおけるメッセージを受け取るステップを含む。このメッセージは、所定のデータ・パーティションに関連するデータについて実行されるべき操作を規定する。さらに、この方法では、複数の書き込み処理の一つによる処理のためにメッセージをキューイング（queuing）し、そして、書き込み段階に、メッセージの処理を許可するが、これは、処理のスレッドが所定のデータ・パーティションのために利用可能な場合においてである。
【０００４】
本発明によれば、複数の分散されたノードを備えるシステムにおけるトランザクション処理のための装置がさらに提供される。ここでは、データは、複数のデータ・パーティション内に保持される。それぞれのパーティション内のデータは、ノードのうちのそれぞれ一つに関連付けられる。このシステムは、データ・パーティションのグループを制御するための複数のコントローラを備える。それぞれのコントローラは、データ・パーティション中のデータについての処理を実行するための、複数の書き込み段階と、処理のスレッドを書き込み段階に割り当てるためのスレッド・マネージャとを備える。ここでは、スレッド・マネージャは、所定のデータ・パーティション中におけるデータについての操作のために、最大で単一のスレッドを割り当てるように構成されている。この装置は、複数のコントローラのうちの第１のものにおいてメッセージを受け取るためのレシーバを備える。メッセージは、所定のデータ・パーティションに関連するデータについて実行されるべき操作と複数の書き込み段階とを、メッセージを処理するために規定する。ここでは、所定のデータ・パーティションのために処理のスレッドが利用可能な場合は、書き込みステージは、一つ又はそれ以上のメッセージを処理するように構成されており、そして、処理のスレッドが利用可能でない場合には、この装置は、メッセージをキュー（queue）に配置するように構成されている。
【０００５】
本発明の他の態様によると、複数の分散されたノードを備えるシステムにおけるトランザクション処理の方法が提供される。この方法は、第１のノードにおけるメッセージを受け取るステップを備える。メッセージは、エンティティに関連するデータについて実行されるべき操作を規定する。さらに、この方法は、ノード上で動いているメッセージ・ハンドラによって処理するためにメッセージをキューイングすること、他のメッセージ・ハンドラがそのデータについて操作を行っていない場合は、メッセージ・ハンドラがメッセージを処理することを許可すること、そして、その後の処理のために、メッセージを第２のノードに送ることを含む。
【０００６】
メッセージ・ハンドラは、読み取りのみ要求（read only requests）を扱う複数の第１メッセージ・ハンドラと、読み取り−書き込み要求（read-write requests）を扱う複数の第２メッセージ・ハンドラとを備える。ここで、複数の読み取りのみ要求は、並列的に動作できる（runnable in parallel）ようになっている。
【０００７】
複数の読み取りのみ要求は、エンティティに関連するデータについての操作のために実行可能としうるが、これは、読み取り−書き込み要求が前記データについて操作していない場合においてのみである。ただ一つの読み取り−書き込み要求が、ある所定の時間において、あるエンティティに関連するデータについて実行可能となることができる。
【０００８】
この方法は、受け取ったメッセージを、受け取ったときにジャーナリング（journaling）することを含む。
【０００９】
この方法は、受領した他の複数のメッセージと共に、メッセージをバッチング（batching）することを備えることができる。バッチングは、それが実行される処理ステージに依存しうる。バッチングは、ネットワーク待ち時間（network latency）、ディスク待ち時間（disk latency）、及び処理されるべきエンティティのうちの少なくとも一つに従って実行されうる。
【００１０】
メッセージ・ハンドラは、複数のエンティティと関連することができる。そして、この方法は、メッセージが向けられたメッセージ・ハンドラに従って、メッセージをグループ化（grouping）することを、さらに含むことができる。
【００１１】
メッセージ・ハンドラに関連付けられた複数のエンティティに関するデータは、いずれかの単一のノードにおいて格納されうる。単一のエンティティに関するデータは、いずれかの単一のノードにおいて格納されうる。
【００１２】
エンティティは、ユーザに関連付けられたアカウントを備えることができ、あるいは、複数のユーザが賭けを行うマーケットを備えることができる。
【００１３】
メッセージは、非同期で送信されうる。
【００１４】
ノードは、サーバを含むことができる。
【００１５】
本発明によれば、分散された複数のノードを備えるシステムでのトランザクション処理のための装置がさらに提供される。この装置は、第１のノードにおいてメッセージを受け取る手段を備える。メッセージは、エンティティに関するデータについて実行されるべき操作を規定している。さらに、この装置は、ノード上で動くメッセージ・ハンドラによる処理のためにメッセージをキューイングするための手段、他のメッセージ・ハンドラがメッセージを処理していない場合に、メッセージ・ハンドラがそのメッセージを処理することを許可するための手段、及び、その後の処理のために、第２のノードに向けてメッセージを送るための手段を備える。
【００１６】
本装置は、単一のアカウントあるいは単一のマーケットについて動作するメッセージ・ハンドラに単一のスレッドを割り当てるために、スレッド・マネージャをさらに含むことができる。また、本装置は、複数のメッセージ・ハンドラに影響するメッセージを処理するためにプリプロセッサ（pre-processor）をさらに含むことができる。プリプロセッサは、多数のジャーナル・メッセージ・ストリームから、単一のメッセージ・ストリームを生成するように構成されうる。
【００１７】
本装置は、メッセージが受け取られていないことの通知に対応して、第１のノードから第２のノードにメッセージを再送付（resending）する手段を、さらに含むことができる。
【００１８】
本装置は、大量に要求されたデータを提供するために、データ・ディストリビュータのクラスタをさらに含むことができる。
【図面の簡単な説明】
【００１９】
本発明の実施形態は、例示を用いて、以下において、添付の図面を参照しながら説明される。
【図１】一般的なトランザクション処理環境についての概略図である。
【図２】賭け交換システムとしてのトランザクション処理システムを図示する概略図である。
【図３】図２で示されたサーバのコンポーネントを図示する概略図である。
【図４】本発明によるトランザクション処理システム内での、アカウント及びマーケットに関するデータの区分け（partitioning）を示す図である。
【図５】トランザクション処理機能を提供するソフトウエア・モジュールの構成を図示する概略図である。
【図６ａ】本発明によるトランザクション処理システムの一部を構成する二つのサーバ間における、メッセージについての通常の交換を示す図である。
【図６ｂ】本発明によるトランザクション処理システムの一部を構成する二つのサーバ間におけるメッセージ交換の間でのメッセージ損失を示す図である。
【図６ｃ】本発明によるトランザクション処理システムの一部を構成する二つのサーバ間におけるメッセージ交換の間での、メッセージの重複排除（de-duplication）を示す図である。
【図７】本発明によるトランザクション処理システムを通過するトランザクションの第１の流れを示す図である。
【図８】図２に示すサーバ上で動作して、図７に示すトランザクションの流れを許可するトランザクション処理モジュールについてのインスタンス（instances）を示す概略図である。
【図９】本発明によるトランザクション処理システムを通過するトランザクションの第２の流れと、第１及び第２の賭けを共にマッチングすることに関わるマッチング・プロセスとを示す図である。
【図１０】本発明によるトランザクション処理システムを通過するトランザクションの第２の流れと、第１及び第２の賭けを共にマッチングすることに関わるマッチング・プロセスとを示す図である。
【図１１】図２に示すサーバ上で動作し、図９及び１０に示すトランザクションの流れを許可するトランザクション処理モジュールについてのインスタンスを示す概略図である。
【発明を実施するための形態】
【００２０】
図１は、一般的なトランザクション処理環境１を表している。トランザクション処理システム２は、より大きな機能システム３の一部となっており、この機能システムは、他のシステム、アプリケーション、あるいはユーザと、クライアント・インタフェース４を介して通信する。クライアント・インタフェース・モジュール４は、異なるソースからトランザクション情報を受け取るために、そして、関連するトランザクション情報をトランザクション処理システム２に送り、若しくはそこから受け取るために、複数のサブシステム４ａ、４ｂ、４ｃを持つことができる。トランザクション処理システム２は、特定の機能システム３の要求に従って、トランザクションを処理する。例えば、機能システムは、株式交換システム（stock exchange system）であり、ここでは、トランザクション処理システムは、付け値（bids）と申し込み（offers）との釣り合い（match）を取る。あるいは、機能システムは、銀行システム（banking system）であり、ここでは、トランザクション処理システムは、預金（credits）と負債（debits）を処理する。
【００２１】
図２は、賭け交換システム（betting exchange system）３の環境でのトランザクション処理システム２を表している。この賭け交換システムは、例えば米国特許出願GB2356071Aに記載されているように、対向する賭け（opposing bets）の釣り合いを取るように構成されている。
【００２２】
賭け交換システム３は、クライアント・インタフェース・モジュール４と、例えばファイアウオール５を通してリンクされたトランザクション処理システム２とを含む。クライアント・インタフェース・モジュール４は、ここにおいてクライアント・インタフェース・サーバと呼ばれる複数のサーバ４００を備える。これらは、クライアントとの、到来する（incoming）又は出ていく（outgoing）通信を扱う。クライアントは、様々なシステムとのインタフェースを行うサーバ・アプリケーションでありうる。そして、この様々なシステムは、例えば、賭け交換をとりまとめ、そして、賭けトランザクション要求をトランザクション処理システムに供給するものである。クライアント・インタフェース・サーバ４００は、ユーザから出された賭け及び／又は関連する賭け情報要求メッセージを受け取るように、そして、対応する要求メッセージをトランザクション処理システム２に導入するように構成されている。クライアント・インタフェース・サーバ４００は、例えば、彼らの賭け可能なアカウントバランス（available-to-bet account balance）を見るために、ユーザからの要求メッセージを受け取り、あるいは、彼らの現在有効な全ての賭けを見るために、ユーザからの要求メッセージを受け取ることも可能である。クライアント・インタフェース・サーバ４００は、トランザクション処理システム２からメッセージを受け取り、そして、対応するメッセージをユーザに返すようにも構成される。このクライアント・インタフェース・サーバは、サーバ４００ａ・・・ｎとしてここで個別に言及もされている。
【００２３】
トランザクション処理システム２は、複数のサーバ２００にわたって、高度に分散されている。これらのサーバは、ここでは、トランザクション処理サーバとして言及されており、そして、それは、クライアント・インタフェース・サーバ４００からのメッセージを受け取るようになっている。トランザクション処理システム２を複数のサーバ２００にわたって配置することは、もし必要なときは、さらなるサーバの追加によって、容易にそして効率的なコストでシステムを拡大できることを意味する。
【００２４】
図３を参照すると、それぞれのトランザクション処理サーバ２００及びそれぞれのクライアント・インタフェース・サーバは、少なくとも一つのプロセッサ２０１／４０１と、例えばＲＡＭであるメモリ２０２／４０２と、例えばハードディスクのような不揮発性メモリ２０３／４０３と、ネットワークインタフェースを含むＩ／Ｏシステム２０４／４０４とを備える。当業者には理解されることとして、各サーバは、その機能を発揮するために必要な全てのコンポーネントを備えている。トランザクション処理サーバは、ここでは、個別に、サーバ２００ａ・・・ｎとして参照される。トランザクション・サーバ２００ａ〜ｃ、２００ｄ〜ｆのグループは、それぞれの共有ディスク（shared disks）６と関連付けられている。
【００２５】
トランザクション処理システム２内のメッセージは、例えば、トランザクション処理システム２における特定の出来事を列挙する（detailing）イベントや特定の操作を実行するためのコマンドを含むことができる。例えば、コマンド・メッセージは、ユーザの賭け可能なアカウントバランス（available-to-bet account balance）を見るための要求でありうるし、イベント・メッセージは、ユーザに対して、彼らの賭けの提出が成功したことを報告するメッセージでありうる。
【００２６】
高いトランザクション速度を達成するために、分散されたシステムにおける各サーバ２００は、ある程度のデータ局所性（data locality）を有しており、リモートのシステムあるいはディスクへのネットワーク呼（network calls）に関連するオーバヘッドを防いでいる。これは、ユーザ・アカウントによる、そして賭けマーケット（betting market）による、トランザクション処理システム２の区分け（partitioning）により達成される。単一のユーザ・アカウントに関連する全ての情報は、単一のサーバに格納され、単一の賭けマーケットに関する全ての情報は、単一のサーバに格納される。このことは、ネットワーク中におけるハードディスクなどの不揮発ストレージやリモートのサーバへのネットワーク呼を個別のサーバが作る必要性を減少させる。このようにして、トランザクション処理システムにおける待ち時間（latencies）が減少し、そして、トランザクションのスループットは向上する。可能であれば、データは、ローカルのメモリあるいは、少なくとも、少ない待ち時間のメモリに格納され、このようにして、例えばネットワーク化されたハードディスクのように待ち時間が多いリソースにアクセスする必要を減らす。
【００２７】
図４は、賭けトランザクションを処理するためのトランザクション処理システム２で使われるアカウント１０の組とマーケット１１の組とを表している。賭けは、ユーザに向けて表示された値付けスクリーン（pricing screens）を通して許可される。賭けの提起を望むユーザには、ユーザ・アカウント１０が割り当てられる。このユーザ・アカウントには、彼らは、例えばインターネットに基づく安全な現金支払いシステムを介して、お金を提供（deposit）することができる。トランザクション処理システム２は、それぞれのユーザアカウント１０に、それ自体に固有のＩＤを割り当てる。
【００２８】
ユーザは、表示された掛け率（odds）に対して彼らが賭けを提起する複数の賭けマーケット（betting markets）１１へのアクセスを持つ。賭けマーケット１１は、例えば、フットボールの試合や競馬などのスポーツ・イベントの結果を含むことができる。前記したユーザ・アカウント１０により、トランザクション処理システム２は、それぞれの賭け市場１１に、それに固有のＩＤを割り当てる。
【００２９】
ユーザ・アカウント１０のグループ１２は、それぞれのアカウント・コントローラ・アプリケーション１３により制御される。ある特定グループのユーザ・アカウント１２のためのアカウント・コントローラ１３は、ユーザ・アカウントに関連する情報をメモリ２０２内のグループに格納するサーバ２００上で動作する。単一のアカウントに関する、及び、あるアカウント・コントローラに関するアカウントのグループに関する全ての情報は、単一のサーバに格納され、あるいはこれにより所有される。それぞれのアカウント・コントローラ１３は、割り当てられたユーザ・アカウント１０ついての要求を提供することについて、及び、全てのアカウントの中枢的な機能（all account centric functions）について、責任を持つ。
【００３０】
例えば、もしユーザが、彼らのアカウント１０についての操作の実行、例えば、賭けを提起すること、彼らの賭け可能なバランスをロードすること、彼らの現在の賭けの概要を見ること、あるいは、彼らの現在の損失見込み（current exposure）すなわち最も悪い事件シナリオにおいて、彼らの賭けからどの程度損失を被るかの計算を望む場合、その操作は、割り当てられたアカウント・コントローラ１３によって提供される。この操作は、ユーザのアカウント１０が配置される単一のサーバ２００にアクセスすることによって提供される。例えば、図２を参照して、アカウント・コントローラについての別々のインスタンスは、サーバ２００ａ〜ｃのぞれぞれの上で動作し、それぞれのサーバ上で保存されたアカウントを処理する。
【００３１】
同様に、賭けマーケット１１は、多数のマーケット・コントローラ・アプリケーション１４によって制御される。ここで、それぞれのマーケット・コントローラ１４は、賭けマーケット１１のグループ１５について責任を持つ。特定の賭けマーケット１１のためのマーケット・コントローラ１４は、前記したとおり、メモリ２０２中の前記賭けマーケット１１に関する情報を格納するサーバ２００上で動作する。単一のマーケットに関する、そして、マーケット・コントローラに関連するマーケットのグループに関する全ての情報は、単一のサーバ上に保存され、あるいは、所有される。マーケット・コントローラ１４は、全てのマーケットの中枢的な機能（all market centric functions）を提供することに責任を持つ。これらの機能は、以下で説明されるような賭けのマッチングを含みうる。例えば、図２を再び参照して、マーケット・コントローラについての別々のインスタンスは、サーバ２００ｄ〜ｆのそれぞれの上で動作し、それぞれのサーバで記録されたマーケット情報を処理する。
【００３２】
各サーバ４００、２００の上で同時に動作するスレッドの数は、最小に保たれる。このことは、高いトランザクション・レートの維持に役立つ。なぜなら、各サーバ４００、２００のプロセッサ４０１、２０１は、多数のスレッドの間で処理時間（processing time）を共有することを必要としないからである。トランザクション処理システム２により使用されるスレッド数（thread count）は、主に非同期メッセージの形態（predominately asynchronous messaging style）を用いることによって、低く保たれる。したがって、メッセージがトランザクション処理システム２に持ち込まれるたびに、処理のためのスレッドを割り当てるのではなく、受領されたメッセージは、到来キューに保持され、そして、処理される前に、スレッドが他の操作の後に利用可能になることを待たなければならない。本発明におけるスレッド管理の態様は、以下においてさらに詳しく記述される。
【００３３】
本発明によるトランザクション処理システム２は、次のようなアーキテクチャを用いる。すなわち、ここでは、このシステムは、メッセージのキューにより接続された処理ステージについてのパイプラインに分割される。一般的に、あるステージは、到来イベント（inbound events）のためのソース・キューと、イベントを処理するためのイベント・ハンドラと、ステージのコンポーネントを監視し、そして、ヒューリステックス（heuristics）の処理を、ステージをホスト（host）するスレッド・マネージャに提供するためのリソース・コントローラの組と、送出キューあるいはシンク（outbound queues or sinks）の組とを備える。この、ステージに基づくアーキテクチャは、図５〜１０に関連して、以下においてさらに記述される。
【００３４】
リソース・コントローラは、バッチング・リソース・コントローラ・モジュール（batching resource controller modules）を含む。このモジュールの機能は、待ち時間及びスループット・ターゲットを、あるものと他のものと引き替えることにより、満たすことである。待ち時間は、それぞれのステージの相互作用の間に処理されるメッセージのバッチ・サイズを低くすることにより、スループットに悪影響を与えるけれども、改善されうる。スループットは、メッセージのバッチ・サイズを大きくすることにより、改善されうる。バッチング・リソース・コントローラは、各ステージの相互作用に要する時間（待ち時間）と、毎秒に処理されるメッセージの数（スループット）とを監視し、そして、これに従って、到来メッセージ・キューのバッチ・サイズを調整する。
【００３５】
バッチング・リソース・コントローラは、到来バッチ・サイズを制御するために、本システム中の全てのステージに適用される。
【００３６】
バッチング・リソース・コントローラによって提供されるバッチング（batching）に加えて、メッセージは、操作されるデータに従ってバッチングされる。各ステージは、メッセージが一緒になるようにグループ化することによって、内部的にバッチングされる。例えば、後に詳述されるブッカ・ステージ（Booker stage）は、そのメッセージが関連するアカウントに従って、メッセージをバッチングする。同じアカウント上であるいは同じマーケットで動く多数のメッセージを処理することは、各メッセージを個別に処理することに比べて、速くなりうる。
【００３７】
GB2356071Aに記載されているように、賭けの提出を望むユーザは、特定の結果が「バックする（back）」か、あるいは「レイする（lay）」、すなわち、結果が起きない方に賭けるかを選ぶことができる。特定の結果をバックする、及びレイすることへの賭けは、その後に、お互いにおけるマッチングが図られる。対向する賭けをこのようにマッチングすることにより、トランザクション処理システム２は、従来のブックメーカに対してではなく、ユーザがお互いに対して賭けることを可能にしている。このことは、賭ける人にとって、より柔軟なアプローチであり、これは、彼又は彼女が、賭けの対象にしたい的確な用語（例えば、掛け率、最大の金額）をセットできるからである。一旦提起されると、ユーザの賭けは、まだマッチしていない賭けのプールに配置される。このプールは、関連するマーケット・コントローラ１４が配置されるサーバ２００のメモリ２０１内に保存されうる。トランザクション処理システム２は、プールを探し、対向する組み合わせ（opposing match）を見つける。もし、マッチが得られなければ、すなわち、他のユーザが、ユーザによって提案された条件に対してマッチされうる賭けを提起していない場合は、その賭けは、アンマッチのプールに残される。トランザクション処理システム２における賭けマッチング（bet-matching）の手順は、以下においてさらに詳しく説明される。
【００３８】
あるユーザが、賭けマーケット１１についての特定の結果を「バックする」あるいは「レイする」ことを決定したときは、ユーザの賭けを記述するクライアント・インタフェース・サーバ４００においてメッセージが受領される。このクライアント・インタフェース・サーバ４００は、PlaceBetRequestメッセージとして参照されるメッセージを生成し、かつトランザクション処理システム２に送り込む。このメッセージは、ユーザが他の賭け者に提示したい条件の記述を与える。前記のPlaceBetRequestメッセージは、その賭けが提示されるマーケット、その賭けが特定の結果を「バックする」あるいは「レイする」ためのものかどうか、ユーザが賭けたい金額、及びユーザが賭けたい掛け率を特定する。トランザクション処理システム２は、PlaceBetRequestメッセージを処理するように、そして、好ましくは、それを、他のユーザにより提起された対向するPlaceBetRequestメッセージとマッチさせるように構成される。例えば特定の結果をバックすることを望む第１ユーザのPlaceBetRequestメッセージは、同じ結果がレイすることを望む第２ユーザのPlaceBetRequestメッセージとマッチされうる。
【００３９】
このプロセスは、図５〜１０に関連して、第１及び第２のユーザにより出された二つの対向するPlaceBetRequestメッセージの、トランザクション処理システム２を通過する流れを図示することにより、以下においてさらに詳しく説明される。
【００４０】
このプロセスは、ディレクタ３１、アカウント・コントローラ４１、６１及びマーケット・コントローラ５１としてここで参照されるいくつかのソフトウエア・モジュールに関連して記述される。アカウント・コントローラ４１、６１及びマーケット・コントローラ５１は、図４に示されるアカウント・コントローラ・モジュール１３及びマーケット・コントローラ・モジュール１４の特定のインスタンスである。
【００４１】
図５は、アカウント及びマーケット・コントローラの両者のために適用される一般的な構成を表しており、これらは、基本的なトランザクション処理アプリケーションである。これらのアプリケーションは、異なるロジックを含み、そして、異なる責任をもつけれども、それらは、共通のアプローチを共有し、トランザクションを処理する。
【００４２】
この構成は、レシーバ・スレッド・マネージャ・モジュール（レシーバ・スレッド・マネージャ）１１２の制御の下で動作するレシーバ・モジュール（レシーバ）１１０と、スケジュールド・スレッド・マネージャ１１７の制御の下で動作するアクノリッジャ・モジュール（アクノリッジャ）１１５と、ジャーナラ・モジュール（ジャーナラ）１２０と、単一のスレッド・マネージャ・モジュール（単一スレッド・マネージャ）１２２の制御の下で動作するプリプロセッサ・モジュール（プリプロセッサ）１２５と、データ・パーティション１３０と、パーティション・スレッド・マネージャ・モジュール（パーティション・スレッド・マネージャ）１４５の下で動作し、かつ、区分けされた読み取り段階１４０及び区分けされた書き込み段階１５０を備える区分けされたメッセージ・ハンドラ１４０、１５０と、スケジュールド・スレッド・マネージャ・モジュール（スケジュールド・スレッド・マネージャ）１６２の下で動作するリセンダ・モジュール（リセンダ）１６０と、単一スレッド・マネージャ１２２の下でやはり動作するディスパッチャ・モジュール（ディスパッチャ）１７０とを備えている。
【００４３】
レシーバ１１０は、ネットワークからのメッセージを読み、そしてそれらをデシリアライズ（deserialize）するように構成されている。レシーバ・スレッド・マネージャ１１２は、到来するネットワーク・イベントを待ち、そして、既定のバッチを構成するために十分なネットワーク・データが到着したときにレシーバ１１０を呼ぶ。レシーバ１１０は、メッセージの重複排除（de-duplicating）に責任を持つ。換言すると、これは、既に見たことがあるメッセージは廃棄するということである。重複排除の必要性は、後述するように、リセンダ１６０の機能から生じる。結果としてデシリアライズされたメッセージは、ジャーナラ１２０に送られる。シリアライズ（serialise）された形態のメッセージは、保持され、そして、ジャーナラ１２０に送られる。
【００４４】
ジャーナラ１２０は、サーバのハードディスク４０３又は共有ディスク６に格納されたログにメッセージを書き込むことに責任を持つ。メッセージのロギング（logging）は、失敗の場合に、ログが再生され、そして、失敗時のメモリの状態を復活できることを意味する。メッセージは、それらが処理されるのと同じ順序で再生される必要があり、これにより、確定的なリカバリを保証できる。これを達成するために、各メッセージは、ジャーナラ１２０によって一連の番号を割り当てられ、これにより、ディスパッチャに到着するメッセージは、それらがジャーナラに到着した順序に従って、再び整列（reordered）されうる。
【００４５】
プリプロセッサ１２５は、処理を区分する前に、グローバル・メッセージを単一のスレッド上で処理することによって、リカバリ・プロセスを支援する。このことは以下においてさらに説明される。もし、一つより多いジャーナラ１２０が使用されているならば、プリプロセッサ１２５は、複数のジャーナル・メッセージ・ストリームが合体して単一のシリアル・ストリームに戻る単一のポイントを提供する。プリプロセッサは、さらに、区分された全てのステージに影響する「システム・オンライン」や「システム・オフライン」のようなシリアル・メッセージを処理する。
【００４６】
ジャーナラ１２０は、プリプロセッサ１２５及びディスパッチャ１７０と同様に、単一スレッド・マネージャ１２２の下で動作する。このスレッド・マネージャは、到来キューに到着するための、バッチを形成する既定数のメッセージを待ち、その後、適切なステージを実施させる。ステージは、連続的にのみ実施され、そして、このスレッド・マネージャは、ある一時点において動作するステージについての単一のインスタンスが存在する時のみに適用される。
【００４７】
ジャーナラ１２０は、プリプロセッサ１２５を介して、区分けされた書き込み段階１５０にメッセージを送る。
【００４８】
区分けされた書き込み段階は、トランザクションのステージを扱い、そして、データ・パーティション１３０内のデータについて動作する。アカウント・コントローラの場合は、データ・パーティションは、アカウント１０を代表する。マーケット・コントローラの場合には、データ・パーティションは、マーケット１１を代表する。区分された書き込み段階は、読み取り／書き込みアプリケーション・ビジネス・ロジックを含む。例えば、図６に示されるエクスポーザ（Exposer）４４あるいはブッカ（Booker）４５は、アカウント・コントローラ・モジュールのために区分された書き込みステージであり、図６に示されるマッチャ（Matcher）５４は、マーケット・コントローラ・モジュールのための区分された書き込みステージである。
【００４９】
アカウント・コントローラ・モジュールのための他の区分された書き込みステージは、アカウント・クリエータ、アカウント・エディタ及びアカウント・デリータと、さらには賭けデリータとを含む。例えば、アカウント・クリエータは、「アカウントを作る」メッセージを受け付けて、そして、新しいアカウントを、アカウント・データ・ストラクチャの中に格納する。マーケット・コントローラに関連して、他の区分された書き込みステージは、マーケット・クリエータ、マーケット・エディタ、及びマーケット・デリータを含む。例えば、マーケット・クリエータは、「マーケットを作る」メッセージを受け付けて、そして、新しいマーケットを、マーケット・データ・ストラクチャ中に格納する。
【００５０】
パーティション・スレッド・マネージャ１４５は、区分された書き込みステージへのスレッドの割り当てを管理して、一つのアカウントあるいはマーケットあたりに割り当てられた最大のスレッドが一つであることを保証する。それは、並行性に確実性を付与することができる。つまり、このシステムは、スレッドとプロセッサにわたって規模を変化させることができる。一方で、失敗の場合における確実な応答（deterministic reply）とは、このシステムが、常に、失敗の前の状態に戻ることを意味する。
【００５１】
例えば、あるメッセージが、データＡについての読み取り／書き込み操作を実行するためのステージ１５０ａ、ｂ、ｃのうちの一つに到着すると、そのステージは、実行のためのスレッドをスレッド・プールから取得し、そして、当該データＡを、そのスレッドにおいて処理する。書き込みステージがデータＡについて操作していても、他のステージは、同じデータＡについて操作することが可能であり、それにより、変更が互いに区別され、そして、分散されたロック（distributed locks）は存在しない。データＡについての操作を実行するために到来したメッセージは、データＡについてのスレッド操作が解除されるまで、待ち行列に入れられる（queued）。区分された書き込みステージ１５０ａ、ｂ、ｃは、しかしながら、実行についての並行スレッドを用いて、他のデータについて動作することができる。これにより、同じ、あるいは異なる書き込みステージは、データＡ及びＣを、データＡと並行に操作することができる。
【００５２】
区分された読み取りステージ１４０は、レシーバ１１０からのメッセージを受け取るものであり、そして、リード・オンリー・アプリケーション・ビジネス・ロジックを含む。この場合、データ区分は、それらが区分された書き込みステージによって操作されていない限り、複数の読み取りステージによって操作されうる。例えば、パーティション・スレッド・マネージャは、もし書き込みステージがデータＡについて操作中であれば、データＡのための読み取り又は書き込み要求を待ち行列に入れる。しかしながら、もし読み取りステージがデータＡについて操作中であれば、さらなる読み取り要求は、データＡについての操作のために、スレッドを割り当てられる。同様に、受け取った書き込み要求は、現在の読み取り要求が完了するまで、待ち行列に入れられる。
【００５３】
区分された読み取りステージの例は、「ロード・アカウント（load account）」メッセージを受け付け、そして、「アカウント・ローデッド（account loaded）」メッセージを、アカウント・データ構造（account data structure）からロードされたアカウントと共に返すアカウント・ローダと、マーケットのための対応する機能を実行するマーケット・ローダとを含む。
【００５４】
リセンダ１６０は、区分された書き込みステージ１５０からメッセージを受け取る。リセンダの目的は、停止が命ぜられるまで、繰り返してメッセージをネットワークに発信することであり、これにより、下記により詳しく説明するように、メッセージを確実に引き渡すことができる。これは、失敗の場合に利点を有する。なぜなら、例えばサーバの交換によってこの失敗が修正されるまで、メッセージは、失われずに、待ち行列の中で蓄積されるからである。このメッセージは、処理されるまで持続する。リセンダは、スケジュールド・スレッド・マネージャ１６２の制御の下で動作する。このスレッド・マネージャは、その到来キューからメッセージをデキュー（dequeuing）する前に、ある程度の時間の経過を待つ。
【００５５】
ディスパッチャ１７０は、リセンダ１６０及び区分された読み取りステージ１４０からメッセージを受け取る。これは、アクノリッジャ１１５からのメッセージの場合と同じである。これらの機能については以下において説明する。それは、メッセージをシリアライズし、そして、ネットワークにそれらを書き込む。
【００５６】
ジャーナラは、失敗のイベントにおける応答のために、イベントのリドゥー・ログ（redo log）を保持しているけれども、チェックポインティング（check-pointing）が、状態を不揮発性ストレージに送る（flushing）ことにより、追加的に実行される。チェック・ポインティングは、定期的な掃除（cleaned down）をジャーナルに許可し、そして、回復時間が過大にならないために要求されるものである。失敗の場合は、状態は、最後のチェックポイントから再生されうる。
【００５７】
前記したモジュールのいずれかによって実行される操作は、並列に進行することができ、そして、レシーバから受け取ったメッセージをジャーナラが処理するのと同時に、そして、以前に受け取ったメッセージのシリアライジングをディスパッチャが行うと同時に、レシーバは、メッセージの読み取りとデシリアライジング（deserialising）とを行う。
【００５８】
サーバ間における保証されたメッセージ引き渡し（guaranteed message delivery）を提供するために使われるプロセスが、図６ａ〜ｃに表示されている。例えば、図６ａに示される正常な動作では、サーバＡのディスパッチャ１７０は、送信カウンタに従って、メッセージ・シーケンス値を設定する。例えば、シーケンス値を「１」に設定する。そして、このディスパッチャは、メッセージをサーバＢのレシーバ１１０に送り、（ステップｓ１００）そして、メッセージが再送信される必要があれば、それをバッファに保存する（ステップｓ１０１）。受け取りに際して、サーバＢのレシーバ１１０は、受け取りカウンタをインクリメントする（ステップｓ１０２）。サーバＡは、第２のメッセージ２をサーバＢに送り（ステップｓ１０３）、そして、メッセージを保存する（ステップｓ１０４）。受け取りに際して、サーバＢは、その受け取りカウンタをインクリメントする（ステップｓ１０５）。サーバＢにおけるアクノリッジャ１１５は、受け取り確認されないメッセージを定期的に取り出すことを実行し、そして、受け取り確認メッセージであるＡＣＫをメッセージのために生成する。そして、この例では、アクノリッジャ１１５は、第１のメッセージのために、サーバＡに（ディスパッチャ１７０を介して）ＡＣＫメッセージを送る（ステップｓ１０６）。サーバＡは、メッセージ１及び２を、そのバッファからクリアし、そして、送信カウンタを、２の値にインクリメントする。次の送信については、ディスパッチャは、次のシーケンス番号、このケースであれば値「３」を、メッセージに割り当てる。
【００５９】
メッセージを失った場合が図６ｂに表されている。再び、サーバＡのディスパッチャ１７０は、シーケンス番号１を有するメッセージを、サーバＢのレシーバ１１０に送り（ステップｓ１１０）、そして、メッセージが再送信されるべきものであれば、そのメッセージをバッファに保存する（ステップｓ１１１）しかしながら、メッセージは、送信中に失われる。すると、サーバＡは、メッセージ２をサーバＢに送り（ステップｓ１１２）、そして、メッセージを保存する（ステップｓ１１３）。メッセージが受領された後、サーバＢは、その受け取りカウンタが零に設定されていることに気づくが、その一方で、メッセージ番号は２である。したがって、レシーバは、「受け取っていない」ＮＡＣＫメッセージを生成する。このメッセージは、ディスパッチャによって、カウンタ「０」を含むサーバＡに戻すように送信される（ステップｓ１１４）。サーバＡのリセンダ１６０は、ＮＡＣＫメッセージに応答して、０より大きいカウンタを備える全てのメッセージを再送信する。このことは図６ａに示されている（ステップｓ１１５）。
【００６０】
図６ｃは、重複排除（de-duplication）のプロセスを表す。第１及び第２のメッセージは、図６ａのステップｓ１００〜ｓ１０５に示されているように、成功のうちに送信されている（ステップｓ１２０〜ｓ１２５）。その結果、サーバＢの受け取りカウンタは、「２」に設定されている。そして、サーバＢのアクノリッジャ１１５は、確認メッセージＡＣＫを生成し、それを（ディスパッチャ１７０を介して）サーバＡに送る（ステップｓ１２６）。しかしながら、このメッセージは、移送中に失われた。タイムアウト期間内にＡＣＫメッセージを受け取らない場合は、サーバＡは、メッセージ１を再送信する（ステップｓ１２７）。サーバＢは、このメッセージを受け取る。しかしながら、その受け取りカウンタは２であり、それは、それがこのメッセージを既に受け取っていることを認識し、それを廃棄する（ステップｓ１２８）。同様のプロセスがメッセージ２について発生する（ステップｓ１２９、ｓ１３０）。サーバＢは、カウンタ２を含むＡＣＫメッセージを送り（ステップｓ１３２）、サーバＡは、そのバッファをクリアし、そして、その送信カウンタを２に設定する（ステップｓ１３２）。それから、このプロセスは、図６ａに示されるように続く。
【００６１】
図７は、賭け要求メッセージ（bet request message）を処理するために相互作用する様々なモジュールの間の相互関係を表示する。以下に、より詳しく説明されるように、これらのモジュールは、異なるサーバ上で動作する。以下の説明から明らかなように、トランザクションは、クライアントとサーバとの間での接続が設定され、そして、通信が、それらの間において、あちこちで通過するようなクライアント−サーバ・モデルを使っては処理されていない。代わりに、クライアントは、第１のノードあるいはサーバにメッセージを渡す。もしさらなる処理が要求されていれば、第１のサーバは、そのメッセージを第２のサーバに取り次ぎ、そして、第３のサーバにと、順次取り次ぐ。これは、要求されたトランザクションに関係するメッセージがクライアントに戻されるまで行われる。
【００６２】
例えば、アカウント・コントローラ・インスタンスを実行するサーバのようなモジュールが失敗する場合、メッセージは失われないが、しかし、この欠陥が、例えばサーバの交換により修正されるまで、メッセージはキューの中に蓄積される。
【００６３】
図７及び８を参照して、第１のユーザが賭けの提起を望むときには、第１の「PlaceBetRequest」メッセージが、ここではイニシエータとして参照されるソフトウエア・モジュール２１により生成される（ステップｓ１）。この「PlaceBetRequest」メッセージは、ユーザのユーザ・アカウントのＩＤ、賭けを提起したいマーケットのＩＤ、ユーザが賭けをし、「バック」または「レイ」のいずれを望むかについての結果のＩＤ、賭けをしたい金額、そして彼らが賭けをしたい掛け率のようなデータを含む。
【００６４】
図８を参照して、イニシエータ２１は、例えばＪ２ＥＥアプリケーション・サーバのようなアプリケーション・サーバ４００ａの上で動く。それは、クライアント・インタフェース・サーバとして動作するサーバ４００のクラスタ内の一つであ。このクライアント・インタフェース・サーバ４００のクラスタは、賭け要求をトランザクション処理システム２に投入することについて責任を持つ。クライアント・インタフェース・サーバ４００のクラスタは、例えばユーザの賭け可能なバランスをロードする要求やユーザの現在有効な賭けを見る要求のような、賭けシステムに関連する他の要求及びメッセージを投入することにも責任を持つ。
【００６５】
生成された「PlaceBetRequest」メッセージが、イニシエータ２１により作られた他のメッセージあるいは要求と共に到来キューに置かれ、そして、ここでエグゼクティブ（Executive）として参照されるソフトウエア・モジュールに向けられる。ここで、このモジュールは、イニシエータ２１と同じクライアント・インタフェース・サーバ４００ａ上で動作する。これらのステージの第１は、エグゼキュータ２３として参照される処理ステージであり、これは、「PlaceBetRequest」によって実施される。エグゼクティブ２２は、レシーバ２４として参照される処理ステージと、ディスパッチャ２５として参照される処理ステージとをさらに備える。エグゼキュータ２３は、バッチ中の到来メッセージ・キューからメッセージをデキュー（dequeue）し、そして、スレッド・マネージャ・アプリケーション（図示せず）によって割り当てられたスレッドについてのメッセージを処理するように構成されている。スレッド・マネージャは、トランザクション処理サーバ２００の一つに配置されうる。スレッドが割り当てられる方法は、図５を参照しながら、上記において既に説明された。
【００６６】
トランザクション処理システム２における、非同期要求の処理についての詳しい記述が以下において提供される。
【００６７】
「PlaceBetRequest」メッセージは非同期要求である。非同期要求を使うことは、エグゼクティブ２２のエグゼキュータ２３からの確認メッセージを、計画された操作を再開する前に、イニシエータ２１が待つ必要がないことを意味する。非同期メッセージングは、以下で説明されかつ、図７〜１１に示されるトランザクション処理システム２の全てのステージで使用されうる。
【００６８】
「PlaceBetRequest」メッセージを含むメッセージのバッチ中におけるメッセージの数は、前記で言及したバッチング・リソース・コントローラ（ＢＲＣ）としてここで参照されるソフトウエア・モジュールにより制御される。
【００６９】
図７を参照して、受け取られた「PlaceBetRequest」メッセージは、エグゼキュータ２３によってディスパッチャ２５に送られる（ステップｓ２）。エグゼキュータ２３がこれを行うのは、ディスパッチャ２５の到来キューの中の「PlaceBetRequest」メッセージを、ディスパッチャ２５に向けられた他の要求あるいはメッセージと共にエンキューすること（enqueueing）によってである。これらの他の要求あるいはメッセージは、イニシエータ２１から発することもできる。「PlaceBetRequest」メッセージが非同期要求であるために、エグゼキュータ２３は、その動作を続けることができる。それは、ディスパッチャ２５からの確認メッセージを待つ必要はない。
【００７０】
ディスパッチャ２５は、到来キューからのメッセージのバッチ中における「PlaceBetRequest」メッセージをデキューする。バッチのサイズは、ここでバッチング・リソース・コントローラ（Batching Resource Controller）２５ａとして参照されるコントローラ・モジュール２５ａにより決定され及び表示される。このモジュールは、ディスパッチャ２５と関連付けられている。このコントローラ・モジュールは、ディスパッチャ２５の動作を監視し、そして、それぞれのメッセージ・バッチ中で処理される要求及びメッセージの数を調整するように構成されている。このことは、バッチング・リソース・コントローラ（Batching Resource Controller）２３ａに関連して、上記において説明した。バッチ中のメッセージ及び要求のデキューイングは、ディスパッチャ２５（及びトランザクション処理システム２における他の全てのステージ）がメッセージのスループットを最大化することを可能にする。なぜなら、バッチ中の多数の要求とメッセージの処理が、キャッシュの局在化（cache locality）とタスクの集中（task aggregation）を可能にするからである。しかしながら、上に述べたように、もしバッチング・ファクタ（batching factor）が大きすぎるならば、ユーザのための応答時間（ユーザは、彼らの賭け要求に対する応答を待っている）は、非常に長くなる。
【００７１】
トランザクション処理システム２における全てのバッチング・リソース・コントローラは、同様に動作する。しかしながら、バッチングは、到着したステージに応じて、異なる基準に基づいて実行されることもできる。例えば、レシーバ・ステージでは、バッチングは、ネットワークの待ち時間に基づくことができる。また、ジャーナラにおいては、それは、ディスクの待ち時間に基づくことができる。一方、エクスポーザでは、それは、アカウント毎の要求の数に基づくことができる。この例では、個別のバッチング・リソース・コントローラが各ステージと関連付けられている。しかしながら、他の形態では、単一のバッチング・リソース・コントローラが各サーバについて存在し、このコントローラは、そのサーバについての全てのバッチング動作の制御に責任を持つ。バッチング・リソース・コントローラは、この実施形態における各ステージと関連するので、明瞭化のために示されていない。以下の説明では、用語「送信する」（forwarding）及び「受信する」（receiving）という用語を用いて動作が説明されるけれども、理解されるべきこととして、これらの動作は、キューイング及びバッチ・コントロールを含む。
【００７２】
ディスパッチャ２５によりデキューされたメッセージは、それらがバッチにおいて処理されるように、グループに分割される。「PlaceBetRequest」メッセージは、イニシエータ２１に「PlaceBetRequest」メッセージを生成させたユーザのユーザ・アカウントに割り当てられたアカウント・コントローラ４１に向けられた他のメッセージと共に、バッチにまとめられる。バッチに割り当てられた他のメッセージは、他の「PlaceBetRequest」メッセージ、ユーザの賭け可能なバランスを見るためのリクエストなどを、既に説明したように、含みうる。
【００７３】
このステージでは、エグゼクティブ２２は、図４に示されるアカウント・コントローラ１３のうちのどれがユーザのユーザ・アカウント１０に割り当てられるかを知らず、そして、このため、「PlaceBetRequest」メッセージをどこに向けて発送すべきか知らない。ディスパッチャ２５は、したがって、正しいアカウント・コントローラ４１を確かめるために、「LocateInstanceRequest」メッセージを生成する（ステップｓ３）。その間、「PlaceBetRequest」メッセージは、その後の送信のために、エグゼクティブ２２に保存される。例えば、「PlaceBetRequest」メッセージは、クライアント・インタフェース・サーバ４００ａに配置されたメモリ４０２内に保存されうる。上で述べたように、「PlaceBetRequest」メッセージを含むバッチ中の全てのメッセージは、同じアカウント・コントローラ４１に向けられ、そして、したがって、ただ一つの「LocateInstanceRequest」メッセージが、そのバッチのために、生成される必要がある。この「LocateInstanceRequest」メッセージは、ディレクタ３１に向けられた他のメッセージ（例えば、他のユーザ・アカウントに関連する「LocateInstanceRequest」メッセージ）と共にキューにエンキューされる。
【００７４】
ディレクタ３１は、レシーバ・ステージ３２、ロケータ・ステージ３３及びディスパッチャ・ステージ３４とを備えている。それはさらに、他のモジュールの場合と同様にジャーナラ（図示せず）を備えているが、これは明瞭さのために省略されている。図８を参照して、ディレクタ３１は、サーバ２００ｇ上で動くことができ、そのサーバは、トランザクション処理サーバ２００のクラスタの一つである。レシーバ３２は、メッセージのバッチ中の「LocateInstanceRequest」メッセージをデキューする。
【００７５】
レシーバ３２は、キューの中の「LocateInstanceRequest」メッセージを、ロケータ３３に向けられた他のメッセージと共に、エンキューする（ステップｓ４）。それから、ロケータ３３は、メッセージのバッチ中におけるこのキューからの「LocateInstanceRequest」メッセージを、例えば他の「LocateInstanceRequest」メッセージと共に、バッチング・リソース・コントローラ３３ａの制御の下で、デキューする。ロケータ３３は、ディレクタ３１が配置されたサーバ２００ｇのメモリ２０２に記録されたリストからの「LocateInstanceRequest」メッセージにおいて特定されたユーザ・アカウントに割り当てられたアカウント・コントローラ４１のアドレスをルックアップするように、構成される。そして、ロケータ３３は、割り当てられたアカウント・コントローラ４１のアドレス情報を含む「LocateInstanceReply」メッセージを作り出し（ステップｓ５）、そして、そのメッセージを、ディレクタ３１のディスパッチャ・ステージ３４に向けられた他のメッセージと共にエンキューする。
【００７６】
「LocateInstanceReply」メッセージは、ディスパッチャ３４によりデキューされ、そして、エグゼクティブ２２のレシーバ２４に向けられた他のメッセージと一緒に、キューにエンキューされる（ステップｓ６）。レシーバ２４によって一旦デキューされると、「LocateInstanceReply」メッセージは、ディスパッチャ２５の到来キューに送られる（ステップｓ７）。
【００７７】
このステージでは、保留されている「LocateInstanceReply」メッセージの起因となった「PlaceBetRequest」メッセージは、クライアント・インタフェース・サーバ４００ａのメモリ４０１から引き出され、そして、「LocateInstanceReply」メッセージで特定されたアカウント・コントローラ４１に送られる。アカウント・コントローラ４１のアドレスは、さらなるルックアップを避けるために、エグゼクティブ２２によりキャッシュされる。アカウント・コントローラは、トランザクション処理サーバ２００の一つであるサーバ２００ａ上で動作することができる。サーバ２００ａは、ユーザのユーザ・アカウントに関連する全てのデータが保存されるサーバである。
【００７８】
エグゼクティブ２２及びディレクタ３１と同様に、アカウント・コントローラ４１は、レシーバ・ステージ４２及びディスパッチャ・ステージ４６を備える。アカウント・コントローラ４１は、さらに、ジャーナラ・ステージ４３と、エクスポーザ・ステージ（Exposer stage）４４と、そして、ブッカ・ステージ（Booker stage）４５とを備える。「PlaceBetRequest」メッセージは、レシーバ４２によって受け取られ（ステップｓ８）、そして、ジャーナラ４３の到来キューに向けて送られる（ステップｓ９）。
【００７９】
アカウント・コントローラ４１の処理ステージは、エグゼクティブ２２及びディレクタ３１のステージに関連して上に記載したものと同様に動作する。メッセージは、メッセージの到来キューからデキューされる。到来キューにおけるメッセージは、先行する処理ステージによって、そこに配置されている。さらに、メッセージは、処理されて、そして、次のステージの到来キューに配置されるか、あるいは、次のステージの到来キューに配置される新しいメッセージを作り出すために使われる。これらのプロセスは、エンキューイングあるいはデキューイングとしてここで一般的に言及される。
【００８０】
ジャーナラ４３において、「PlaceBetRequest」メッセージは、例えば共有ハードディスク６において保存されうる不揮発ログに追記される。あるいは、それは、各サーバ２００内のハードディスク２０３に保存されうる。これにより、各サーバ２００におけるログに保存された情報を取り出す速度が向上する。もし必要なら、応答のために、「PlaceBetRequest」メッセージには、固有のシーケンス番号が、ログにおいて付与される。
【００８１】
このようにして受領メッセージをジャーナリングすることは、次のことを意味する。すなわち、システム欠陥の場合には、トランザクション処理システム２は、確定的なポイント、すなわち、アカウント・コントローラ４１のジャーナラ４３によって受領メッセージが最後に記録されたステージに戻ることができる。「PlaceBetRequest」メッセージは、ジャーナラ４３からエクスポーザ４４に送信される（ステップｓ１０）。
【００８２】
エクスポーザ・ステージ４４では、「PlaceBetRequest」は、賭け（bet）についての最大に可能な損失（exposure）を計算するために、処理される。これは、ユーザが特定の結果をバックあるいはレイしたときのユーザの最大の責任を決定する計算である。例えば、もし、賭けが、特定の結果を、２／１の掛け率（３のデジタル掛け率）で、５ポンドの掛け金において、「バックする」ことであれば、ユーザは、もし彼らが賭けに負ければ、５ポンドを失うことになる。しかしながら、もし、賭けが、特定の結果を、２／１の掛け率で、最大５ポンドの賭けで「レイする」ことであれば、ユーザは、もし賭けに負ければ、１０ポンドを失うことになる。
【００８３】
損失の計算は、エクスポーザ４４によって実行され、そして、バッチにおいて処理される。したがって、もし、特定のユーザ・アカウントのために複数の「PlaceBetRequest」メッセージがあれば、全ての賭けの損失は、単一の操作で計算される。
【００８４】
エクスポーザ・ステージ４４は、ユーザのユーザ・アカウントにおける賭け可能なバランスに対して計算された損失をチェックする。もし、ユーザ・アカウントが、ユーザの有効な賭けについての損失をまかなうに十分な金額を含むのであれば、エクスポーザ４４は、「MatchBetRequest」メッセージを作り出し、そして、この「MatchBetRequest」メッセージをディスパッチャ４６に送り出す（ステップｓ１１）。もし、ユーザ・アカウントが、賭けの損失をまかなうに十分な金額を含まないのであれば、メッセージは、エグゼクティブ２２及びイニシエータ２１を介してユーザに戻され、これによって、ユーザは、利用できる資金が不十分であることを知らされる。
【００８５】
ディスパッチャ４６におけるプロセスは、エグゼクティブ２２のディスパッチャ２４を参照して前記したそれに類似している。アカウント・コントローラ４１は、どのマーケット・コントローラ１４が、「MatchBetRequest」により特定された賭けマーケット１１に割り当てられたかを知らない。ディスパッチャ４６は、したがって、「LocateInstanceRequest」メッセージを生成し、そして、ディレクタ３１にそれを送る（ステップｓ１２）。これは、メッセージをロケータ３３に送るものである（ステップｓ１３）。ロケータ３３は、割り当てられたマーケット・コントローラ５１をリストからルックアップする。その方法は、アカウント・コントローラ４１のルックアップに関連して前記したところと同様である。その間、「MatchBetRequest」メッセージは、アカウント・コントローラ４１中に、その後の送信のために保存される。「MatchBetRequest」は、例えば、アカウント・コントローラ４１が配置されるサーバ２００に配置されたＲＡＭ２０２中に保存されうる。割り当てられたマーケット・コントローラ５１は、ロケータ３３により配置される。そしてそれは、「LocateInstanceReply」メッセージをディスパッチャ３４に送る（ステップｓ１４）。マーケット・コントローラ５１のアドレスは、ディレクタ３１のディスパッチャ３４により生成された「LocateInstanceReply」メッセージ中のアカウント・コントローラ４１のレシーバ４２に送られる（ステップｓ１５）。
【００８６】
そして、「LocateInstanceReply」メッセージは、アカウント・コントローラ４１のレシーバ４２により、ディスパッチャ４６に送られる（ステップｓ１６）。このポイントでは、「LocateInstanceRequest」メッセージを誘起する、保留の「MatchBetRequest」は、サーバ２００上のメモリ２０１から引き出され、そして、ディスパッチャ４６により、正しいマーケット・コントローラ５１に送付される（ｓ１７）。アカウント・コントローラ４１の場合と同じように、マーケット・コントローラ５１のアドレスは、エグゼクティブ２２によりキャッシュされ、これにより、そのアドレスを再びルックアップする必要がないようにしている。
【００８７】
図８に示されるように、マーケット・コントローラ５１は、トランザクション処理サーバ２００の一つであるサーバ２００ｄ上に配置され、そして、レシーバ・ステージ５２、ジャーナラ・ステージ５３、マッチャ・ステージ（Matcher stage）５４、及びディスパッチャ・ステージ５５を備える。マーケット・コントローラ５１におけるこれらのステージは、メッセージのエンキュー及びデキューを行うものであり、これらは、エグゼクティブ２２、ディレクタ３１，及びアカウント・コントローラ４１に関連して説明したところと同様である。「MatchBetRequest」メッセージは、レシーバ５２により受け取られ、そして、ジャーナラ５３に送られる（ステップｓ１８）。ジャーナラ５３においては、「MatchBetRequest」メッセージは、例えばハードディスクに保存された不揮発性ログに追記される。このことは、アカウント・コントローラ４１のジャーナラ４３における「PlaceBetRequest」メッセージのロギングに関連して説明したところと同様である。既に説明したように、不揮発性ログは、例えば、マーケット・コントローラ５１が配置されるサーバ２００ｄ上や、あるいは、共有ディスク６や、あるいは、マーケット・コントローラ５１にネットワーク接続経由で接続された他のディスクに保存されてもよい。「MatchBetRequest」メッセージは、それから、マッチャ５４に送られる（ステップｓ１９）。
【００８８】
マッチャ５４においては、「MatchBetRequest」メッセージは、マッチャ５４を、賭けマーケット３に既に提起されていたマッチしていない賭け（unmatched bets）のプールを通しての調査へのきっかけとさせる。マッチしていない賭けは、例えば、サーバ２００ｄの一部であるメモリ２０２中に保存されうる。調査の目的は、「MatchBetRequest」メッセージにより提供された条件の賭けに対向する条件を提供する賭けを見つけることである。この例では、賭けプールは空であり、そのため、マッチできる賭けはみつからない。ユーザの賭けは、したがって、マッチしていない、未修整の（unmodified）賭けのプールに追加される。それから、マッチャ５４は、その賭けのためのマッチング・プロセスに関する情報を記述する「MatchBetReply」メッセージを生成する。このケースでは、プールが空なので、「MatchBetReply」メッセージは、その賭けのために適用可能な一致（match）はないということを記述する。
【００８９】
賭けのマッチングは、バッチにおいて実行される。もし、複数の「MatchBetRequests」が特定の賭けマーケット１１について存在するときは、全ての「MatchBetRequests」のためのマッチング・プロセスは、単一の操作で実行される。
【００９０】
「MatchBetReply」メッセージは、マッチャ５４によりディスパッチャ５５に送られ（ステップｓ２０）、それは、今度は、そのメッセージを、アカウント・コントローラ４１のレシーバ４２に送る（ステップｓ２１）。レシーバ４２は、「MatchBetReply」メッセージをジャーナラ４３に送り（ステップｓ２２）、そこでは、「MatchBetReply」メッセージは、ブッカ４５に送られる前に、不揮発性ログに付記される（ステップｓ２３）。
【００９１】
ブッカ４５においては、「MatchBetReply」メッセージに含まれる情報は、例えば、ユーザの賭けの状態を、「未処理」（unprocessed）から「処理済み」（processed）にアップデートするために使われる。さらに、ブッカ４５は、様々な一致情報を保存するように構成される。しかしながら、「MatchBetReply」メッセージの場合には、適切な「MatchBetRequests」が賭けプール内にないので、一致情報がない。ユーザの賭けの状態は、例えば、アカウント・コントローラ４１を実行させるサーバ２００ａにおけるＲＡＭのようなメモリ２０２内に保存されうる。ブッカ４５は、「PlaceBetReply」メッセージを生成し、そして、それを、ディスパッチャ４６に送る（ステップｓ２４）。ディスパッチャ４６からは、この「PlaceBetReply」が、エグゼクティブ２２のエグゼキュータ２３に、レシーバ２４を介して送られる（ステップｓ２５、ｓ２６）。
【００９２】
このポイントでは、「PlaceBetReply」メッセージが、イニシエータ２１の到来キューに置かれ、デキューを待つ（ステップｓ２７）。そして、賭けを提起した結果は、イニシエータ２１を介して、ユーザに返されうる。
【００９３】
図９及び１０を参照して、第２のユーザは、第１のユーザにより提起された賭けに対向して、ユーザ・ウエブサイトを介して、賭けを提起する。これは、第２の「PlaceBetRequest」メッセージを、エグゼクティブ２２のエグゼキュータ２３内に送り込ませる（ステップｓ１）。第２の「PlaceBetRequest」メッセージは、トランザクション処理システム２を通る経路を辿る。このことは、第１のユーザの賭けに関連する「PlaceBetRequest」メッセージの経路に関して説明したところと同様である。ステップｓ１〜ｓ１９は、前記したところと同様である。
【００９４】
マーケット・コントローラ５１内のマッチャ５４に到達すると、第２のユーザの賭けに関連する「MatchBetRequest」メッセージは、マッチャ５４が、ＲＡＭ２０２中における一致しない賭けのプール中の「MatchBetRequest」メッセージに対する可能な一致を見つけるための調査の契機となる。これは、第１のユーザの賭けに関連する「MatchBetRequest」メッセージに関して既に説明したとおりである。ここでは、前記した調査が成功し、そして、第２のユーザの賭けに関連する「MatchBetRequest」が、第１のユーザの賭けに関連する第１の「MatchBetRequest」に一致している。
【００９５】
その後、マッチャ５４は、その一致に関係する情報を記述する「MatchBetReply」メッセージを生成し、そして、この「MatchBetReply」メッセージをディスパッチャ５５に（ステップｓ２０ａ）、そして、第２のユーザのユーザ・アカウントに割り当てられたアカウント・コントローラ６１のレシーバ６２に送る（ステップｓ２１ａ）。図１１を参照して、アカウント・コントローラ６１は、サーバ２００ｂ上に配置される。このサーバは、トランザクション処理システムを形成するサーバ２００のネットワークの一つである。このサーバ２００ｂは、第２のユーザのユーザ・アカウントに関連する全ての情報が、例えばＲＡＭ２０２内に保存されるサーバである。
【００９６】
それから、「MatchBetReply」メッセージは、トランザクション処理システム２を、図９に示すようにして流れる。このことは、第１のユーザの賭けに関連する「MatchBetReply」メッセージの流れに関して説明したところに類似している。特に、「MatchBetReply」メッセージは、ジャーナラ６３により不揮発性メモリ２０３内に保存され、そして、ブッカ６５に送られる。これは、アカウント・コントローラ６１内の第２の賭けの状態を「未処理」から「処理済み」にアップデートするものである。ブッカ６５は、さらに、「MatchBetReply」メッセージに含まれる位置情報を保存し、そして、「PlaceBetReply」メッセージを構築する。このメッセージは、ディスパッチャ６６並びにエグゼクティブ２１のレシーバ２３及びエグゼキュータ２２を介して、イニシエータ２１に送られる（ステップｓ２４〜ｓ２７）。
【００９７】
それから、「PlaceBetReply」は、クライアント・インタフェース・サーバ４００ａ上のイニシエータ２１を介して中継されて、ユーザのウエブページに戻される。これは、第１及び第２のユーザに、彼らの賭けを対向する賭けに一致させることに成功したという確認を提供する。
【００９８】
前記した「MatchBetReply」メッセージを生成することに加えて、マッチャ５４は、マーケット・コントローラ５１のディスパッチャ５５に送られる「MatchedBetEvent」メッセージを追加的に生成する（ステップｓ２０ｂ）。「MatchedBetEvent」メッセージは、第１のユーザのユーザ・アカウントに割り当てられたアカウント・コントローラ４１に送られるべきものであり、これによって、それに対して、第１のユーザの賭けに関連する「PlaceBetRequest」メッセージが一致に成功したことを知らせることができる。しかしながら、このステージでは、マーケット・コントローラ５１は、第１のユーザのユーザ・アカウントに関連するアカウント・コントローラ４１のアドレスを知らない。「MatchedBetEvent」メッセージは、したがって、マーケット・コントローラ５１において、例えば、サーバ２００ｂのメモリ２０２内に保存され、そして、ディスパッチャ５５は、ディレクタ３１によりアクセスされるリストからアカウント・コントローラ４１のアドレスをルックアップするために、「LocateInstanceRequest」メッセージを生成する（ｓ２１ｂ）。このリストは、ディレクタ３１が配置されたサーバ２００ｇの一部として備えられたＲＡＭ２０２に保存されうる。
【００９９】
「LocateInstanceRequest」メッセージは、レシーバ３２により受け取られ、そして、アカウント・コントローラ４１のアドレスをルックアップするために、ロケータ３３に送られる（ｓ２２ｂ）。ロケータ３３は、アカウント・コントローラ４１のアドレスを含む「LocateInstanceReply」メッセージを生成し、そして、それを、ディスパッチャ３４を介して、レシーバ５２に送る（ステップｓ２３ｂ、ｓ２４ｂ）。マーケット・コントローラ５１のレシーバ５２は、それから、「LocateInstanceReply」メッセージをディスパッチャ５５に送る（ステップｓ２５ｂ）。この段階では、保留中の「MatchedBetEvent」メッセージが、メモリ２０１から取り出され、アカウント・コントローラ４１のレシーバ４２に送られる（ステップｓ２６ｂ）。アカウント・コントローラ４１のアドレスは、将来において再びそれをルックアップする必要を避けるために、マーケット・コントローラ５１によりキャッシュされる。
【０１００】
受け取られた「MatchedBetEvent」メッセージは、ジャーナラ４３に送られ（ステップｓ２７ｂ）、そして、それは、前記したような方法で、固有の参照番号と共に不揮発性ストレージに付記される。「MatchedBetEvent」メッセージは、それから、ブッカ４５に送られ（ステップｓ２８ｂ）そして、アカウント・コントローラ４１についての賭けの状態をアップデートするために使われる。このデータは、アカウント・コントローラ４１を実行するサーバ２００ａのＲＡＭ２０２内に保存されうる。
【０１０１】
この方法では、第１および第２のユーザにより提起された賭けは共に一致に成功している。
【０１０２】
トランザクションが処理されると、トランザクション処理システム内において保持されているデータは、速やかに変化する。新しいデータは、依頼者に通知される必要がある。例えば、マーケットの見込み（market view）は、ユーザのためにアップデートされる必要がある。これらの変更は、情報を必要とする依頼者に伝えられる。これは、依頼者の要求に応答することによってでなく、デルタ（deltas）として参照される現在のデータへの変更を依頼者にプッシュすることによる。
【０１０３】
前記した実施形態及びその変形例は、トランザクション処理システムによって提供される効果を達成するために、単独で、あるいは組み合わせて使用されうる。
【０１０４】
本発明に基づく前記したシステムは、トランザクション処理システムのＡＣＩＤ原則に従う。これらは、トランザクションが以下の特性を持つ必要があるということである：
【０１０５】
原子性（Atomicity）。最小単位（atomic）のトランザクションは、全ての操作が成功するか又はしないかという、一連の操作である。もし、このような一連の操作が、完成の前に、あるポイントで失敗すると、その失敗の前に終了しているあらゆる操作は、ロールバックされる必要がある。本発明に基づくトランザクション処理システムでは、トランザクションは前もって知られており、そして、全ては不揮発性メモリに保存されている。従来のシステムと異なり、ロギングは、操作レベルというよりもむしろ、トランザクション・レベルで発生する。そのため、全ての完了した操作がログされるＵＮＤＯロギングの必要がない。そして、ＵＮＤＯログは、不揮発性ストレージから、トランザクションが完了する前に書き込まれた変更を除去するために検査される。
【０１０６】
一例として、「賭けを提起する」（bet placement）トランザクションがログされる一方、その下にある一連の操作、例えば「古いエクスポージャを書き込む」、「新しいエクスポージャを書き込む」、「新しい賭けを書き込む」などはログされていない。
【０１０７】
トランザクションが補足され、実行が開始され、そして、トランザクションにおける全ての操作が完了する前に失敗がある場合は、その状態は捨てられ、そして、ＲＥＤＯログとしても知られるジャーナルは、状態を復元するために再生される。
【０１０８】
ログの再生による状態の復元を確実に成功させるために、これらのステージは、確定的（deterministic）とされる。例えば、賭けは、特定の注文において到着し、そしてログされる。以下を仮定する：
１．賭け１（１０ポンド）
２．賭け２（１５ポンド）
３．賭け３（２０ポンド）
【０１０９】
確定的な手法で処理した後、単一の可能な状態は以下の通りである：
１．賭け１（１０ポンドが賭け２とマッチ）
２．賭け２（１０ポンドは賭け１とマッチ、５ポンドは掛け３とマッチ）
３．賭け３（５ポンドは掛け２とマッチ、１５ポンドはマッチしない）
【０１１０】
明確なこととして、賭けマッチング・ステージは、非確定的であり、多数の状態が可能であり得る。例えば、賭け１と２とが処理される前に賭け３が処理されていたとすれば、可能な状態は以下の通りである：
１．賭け１（１０ポンドが賭け３とマッチ）
２．賭け２（１０ポンドは賭け３とマッチ、５ポンドはマッチしない）
３．賭け３（１０ポンドは掛け１とマッチ、１０ポンドは賭け２とマッチ）
【０１１１】
ログ応答は時間を消費するプロセスでありうるので、本発明におけるいくつかの形態は、例えばログ・テイリング（log tailing）のような利用性の高い機構を含む。
【０１１２】
一貫性（Consistency）。これは、アプリケーションが規定する完全性の制約について違反があってはならないことを意味する。あるトランザクションが実行される前に、あるシステムが一貫する状態（consistent state）にあるとすると、それは、その後においても、一貫した状態にある必要がある。
【０１１３】
例えば、もし、あるユーザが１０ポンドのための賭けを持つとすれば、マッチした部分とマッチしない部分の合計は１０ポンドでなければならない。
【０１１４】
本発明に基づくシステムの実施形態では、弱い一貫性が適用される。このシステムは、結局のところは一貫することになるけれども、時間的なある一瞬においては、それは不一致となりうる。例えば、あるアカウント・コントローラは、不一致である１０ポンドの賭けの記録を持ちうるし、あるマーケット・コントローラは、その掛けのうち５ポンドがマッチしたとの記録を持ちうる。このアカウント・コントローラは、５ポンドの一致あるいは不一致の記録を持たないけれども、マーケット・コントローラから移動中の、このマッチを記述するメッセージは、アカウント・コントローラが結果的に、マッチされ及びマッチしない５ポンドの価額を記録することを意味する。このことは、既に説明したように、状態及びメッセージングの保証によって保証されている。
【０１１５】
独立性（Isolation）。この特性は、複数の実行中の動作が重ならないことに言及するものであり、これにより、それらが同時に実行されたとしても、それらは順次実行されるように見える。トランザクション処理システムにおける多くの機能は、アカウント及びイベントへの排他的なアクセスを要求する。独立性を達成するためには、実行ユニットが個別のエンティティに割り当てられる。それにより、アクセスは固有的にシリアライズされ、そして、トランザクションは他のそれとは独立とされる。例えば、単一の実行ユニットは、特定データの一部への独占を取得しそして解放するクライアントのセッションに対向して、特定のアカウントあるいは特定のマーケットを持つことができる。
【０１１６】
耐久性（Durability）。トランザクションが成功して、一旦完了すると、それは、例えシステムがシャットダウンしても、失われてはならない。変更は、したがって、ディスクに書き込まれ、あるいはジャーナルされる。上において説明したように、フル・トランザクションのみがこの手法でログされるのであり、このトランザクションを構成する個別の動作はそうされない。
【０１１７】
メッセージ・カウンタは、やはりログされ、メッセージの紛失、不調あるいは重複のために提供される。
【０１１８】
前記した実施形態への変更及び変化は熟練者には明白であるが、それらは、請求の範囲の中に入る。
【特許請求の範囲】
【請求項１】
複数の分散されたノードを備えるシステムにおけるトランザクション処理方法であって、前記ノード中では、データが、複数のデータ・バーティション中に保持されており、各パーティション中のデータは、ノードのそれぞれ一つと関連付けられており、このシステムは、以下を備える：
データ・パーティションのグループを制御するための複数のコントローラ、ここで、各コントローラは、前記データ・パーティション中の前記データについての操作を実行するための複数の書き込みステージを備える；そして
実行のスレッドを前記書き込み段階に割り当てるためのスレッド・マネージャ、ここで、前記スレッド・マネージャは、所定のデータ・パーティション中のデータについて操作するために、最大で一つのスレッドを割り当てるようになっている、
さらに、前記方法は、以下のステップを備える：
前記複数のコントローラのうちの第１のものにおいてメッセージを受け取ること、ここで、前記メッセージは、所定のデータ・パーティションに関連するデータについて実行されるべき操作を規定している；
前記複数の書き込みステージの一つによる処理のためにメッセージをキューイングすること；そして
実行のスレッドが前記所定のデータ・パーティションのために利用可能な場合には、前記書き込み段階による前記メッセージの処理を許可すること。
【請求項２】
請求項１に記載の方法であって、さらに以下を備える：
前記複数のコントローラのうちの第２のものに向けて、その後の処理のために、前記メッセージを送ること。
【請求項３】
請求項１又は２に記載の方法であって、前記第１又は第２のコントローラに前記メッセージを送る前に、前記メッセージが向けられた前記所定のデータ・パーティションに割り当てられた前記コントローラのアドレスを決定することを備える。
【請求項４】
先行するいずれかの請求項に記載の方法であって、複数の読み取りステージが所定のパーティション中の前記データについて並行して操作することを許可することをさらに備える。
【請求項５】
請求項４に記載の方法であって、ここでは、もし書き込みステージが前記所定のパーティション中の前記データについて操作していないときにおいてのみ、複数の読み取りステージが前記所定のパーティション中の前記データについて操作することを許可されている。
【請求項６】
先行するいずれかの請求項に記載の方法であって、受け取ったメッセージを、その受領に際してジャーナリングすることを備える。
【請求項７】
請求項６に記載の方法であって、受け取ったメッセージに連続番号を割り当てることを備える。
【請求項８】
先行するいずれかの請求項に記載の方法であって、受け取ったメッセージを、他の複数の受け取りメッセージと共にバッチングすることを含む。
【請求項９】
請求項８に記載の方法であって、ここでは、前記バッチングは、バッチングが実行されている処理ステージに依存する基準に基づいて実行される。
【請求項１０】
請求項８又は９に記載の方法であって、ここでは、前記バッチングは、ネットワーク待ち時間、ディスク待ち時間、及び処理されるべき前記データのうちの少なくとも一つに従って実行される。
【請求項１１】
請求項８〜１０のいずれか１項に記載の方法であって、さらに、前記メッセージが向けられた前記データ・パーティションに関連する前記コントローラに従ってメッセージをグループ化することを備える。
【請求項１２】
先行するいずれかの請求項に記載の方法であって、ここでは、単一のコントローラに関連する複数のデータ・パーティション中の前記データは、前記ノードのうちの一つに格納されている。
【請求項１３】
先行するいずれかの請求項に記載の方法であって、ここでは、第１のデータ・パーティション中の前記データは、あるユーザに関連するアカウントを規定している。
【請求項１４】
請求項１３に記載の方法であって、ここでは、第１のコントローラは、複数のアカウントに関連する操作を制御するためのアカウント・コントローラを備える。
【請求項１５】
請求項１３又は１４に記載の方法であって、ここでは、第２のデータ・パーティション中の前記データは、複数のユーザが賭けを提起できるマーケットを備える。
【請求項１６】
請求項１５に記載の方法であって、ここでは、第２のコントローラは、複数のマーケットに関連する操作を制御するためのマーケット・コントローラを備える。
【請求項１７】
先行するいずれかの請求項に記載の方法であって、ここでは、前記メッセージは、非同期で送信される。
【請求項１８】
先行するいずれかの請求項に記載の方法であって、ここでは、前記ノードがサーバを含む。
【請求項１９】
複数の分散されたノードを備えるシステムにおいてトランザクション処理方法を実行するためのコンピュータ可読命令を備えるコンピュータ可読媒体であって、前記ノードにおいては、複数のデータ・パーティション中にデータが保持されており、それぞれのパーティション中のデータは、対応する単一の前記ノードに関連付けられており、
前記システムは以下を含む：
データ・パーティションのグループを制御するための複数のコントローラ、ここで、各コントローラは、前記データ・パーティション中における前記データについての操作を実行するための複数の書き込みステージを備えており；そして、
実行スレッドを前記書き込みステージに割り当てるためのスレッド・マネージャ、ここで、前記スレッド・マネージャは、所定のデータ・パーティション中のデータについて操作するために、最大でも一つのスレッドを割り当てるようになっており、
前記コンピュータ可読命令は、以下を備える：
前記複数のコントローラのうちの第１のものにおいてメッセージを受け取るための第１の命令、ここで、前記メッセージは、所定のデータ・パーティションに関連するデータについて実行されるべき操作を規定する；
前記複数の書き込みステージの一つによって処理するために前記メッセージをキューイングするための第２の命令；そして、
前記所定のデータ・パーティションのために実行スレッドが利用可能な場合において、前記書き込みステージが前記メッセージを処理することを許可するための第３の命令。
【請求項２０】
請求項１９に記載のコンピュータ可読媒体であって、以下をさらに備える：
その後の処理のために、前記複数のコントローラのうちの第２のものに前記メッセージを送付するための第４の命令。
【請求項２１】
複数の分散されたノードを備えるシステムにおけるトランザクション処理のための装置であって、前記ノードにおいては、データは、複数のデータ・パーティション内に保持されており、対応するパーティション内のデータは、対応する単一の前記ノードに関連付けられており、
前記システムは、以下を備える：
データ・パーティションのグループを制御するための複数のコントローラ、ここで、各コントローラは、前記データ・パーティション中の前記データについての操作を実行するための複数の書き込みステージを備えており；そして、
実行のスレッドを前記書き込みステージに割り当てるためのスレッド・マネージャ、ここでは、前記スレッド・マネージャは、所定のデータ・パーティション中のデータの操作のために、最大で一つのスレッドを割り当てるようになっており、
前記装置は、以下を備える：
前記複数のコントローラのうちの第１のものにおいてメッセージを受け取るレシーバ、ここで、前記メッセージは、所定のデータ・パーティションに関連するデータについて実行されるべき操作を規定しており；そして、
前記メッセージを処理するための複数の書き込みステージ、ここでは、実行スレッドが前記所定のデータ・パーティションのために利用可能な場合には、書き込みステージは、一つ又は複数のメッセージを処理し、実行スレッドが利用できない場合には、前記装置は、前記メッセージをキューに配置するようになっている。
【請求項２２】
請求項２１に記載の装置であって、その後の処理のために、前記複数のコントローラのうちの第２のものに前記メッセージを送るためのディスパッチャを備える。
【請求項２３】
請求項２１又は２２に記載の装置であって、ここでは、あるアカウントに関係するデータは、単一のサーバ内に保存されている。
【請求項２４】
請求項２３に記載の装置であって、ここでは、アカウントのグループを制御するためのアカウント・コントローラをさらに備えている。
【請求項２５】
請求項１２〜２４のいずれか１項に記載の装置であって、ここでは、あるマーケットに関係するデータは、単一のサーバ内に保存されている。
【請求項２６】
請求項２５に記載の装置であって、ここでは、マーケットのグループを制御するためのマーケット・コントローラをさらに備えている。
【請求項２７】
請求項２３〜２６のいずれか１項に記載の装置であって、ここでは、単一のスレッドを、ある単一のアカウントあるいは単一のマーケットについて操作している第１の書き込みステージに割り付けるためのスレッド・マネージャをさらに備えている。
【請求項２８】
請求項２７に記載の装置であって、ここでは、前記単一のアカウントあるいは前記単一のマーケットへのアクセスを要求する第２の書き込みステージは、前記単一のスレッドが解放されるまで、アクセスを拒否される。
【請求項２９】
請求項２７又は２８に記載の装置であって、ここでは、前記第１の及び／又は前記第２の書き込みステージは、ある単一のアカウントあるいはマーケットに関係するメッセージのバッチを、単一の操作において処理するように構成されている。
【請求項３０】
請求項２１〜２９のいずれか１項に記載の装置であって、ここでは、複数の書き込みステージに影響するメッセージを処理するためのプリプロセッサをさらに備えている。
【請求項３１】
請求項３０に記載の装置であって、ここでは、前記プリプロセッサは、単一のメッセージ・ストリームを、複数のジャーナルされたメッセージ・ストリームから生成するようになっている。
【請求項３２】
請求項２１〜３１のいずれか１項に記載の装置であって、ここでは、メッセージが受け取られていないという通知に対応して、第１のノードから第２のノードにメッセージを再送信する手段をさらに備える。
【請求項３３】
請求項２１〜３２のいずれか１項に記載の装置であって、ここでは、大量に要求されたデータを提供するためのデータ・ディレクタのクラスタをさらに備える。
【請求項３４】
請求項２１〜３３のいずれか１項に記載の装置であって、ここでは、トランザクションを不揮発性メモリにジャーナルし、そして、トランザクションを作る操作を揮発性メモリにジャーナルする構成となっている。
【請求項１】
複数の分散されたノードを備えるシステムにおけるトランザクション処理方法であって、前記ノード中では、データが、複数のデータ・バーティション中に保持されており、各パーティション中のデータは、ノードのそれぞれ一つと関連付けられており、このシステムは、以下を備える：
データ・パーティションのグループを制御するための複数のコントローラ、ここで、各コントローラは、前記データ・パーティション中の前記データについての操作を実行するための複数の書き込みステージを備える；そして
実行のスレッドを前記書き込み段階に割り当てるためのスレッド・マネージャ、ここで、前記スレッド・マネージャは、所定のデータ・パーティション中のデータについて操作するために、最大で一つのスレッドを割り当てるようになっている、
さらに、前記方法は、以下のステップを備える：
前記複数のコントローラのうちの第１のものにおいてメッセージを受け取ること、ここで、前記メッセージは、所定のデータ・パーティションに関連するデータについて実行されるべき操作を規定している；
前記複数の書き込みステージの一つによる処理のためにメッセージをキューイングすること；そして
実行のスレッドが前記所定のデータ・パーティションのために利用可能な場合には、前記書き込み段階による前記メッセージの処理を許可すること。
【請求項２】
請求項１に記載の方法であって、さらに以下を備える：
前記複数のコントローラのうちの第２のものに向けて、その後の処理のために、前記メッセージを送ること。
【請求項３】
請求項１又は２に記載の方法であって、前記第１又は第２のコントローラに前記メッセージを送る前に、前記メッセージが向けられた前記所定のデータ・パーティションに割り当てられた前記コントローラのアドレスを決定することを備える。
【請求項４】
先行するいずれかの請求項に記載の方法であって、複数の読み取りステージが所定のパーティション中の前記データについて並行して操作することを許可することをさらに備える。
【請求項５】
請求項４に記載の方法であって、ここでは、もし書き込みステージが前記所定のパーティション中の前記データについて操作していないときにおいてのみ、複数の読み取りステージが前記所定のパーティション中の前記データについて操作することを許可されている。
【請求項６】
先行するいずれかの請求項に記載の方法であって、受け取ったメッセージを、その受領に際してジャーナリングすることを備える。
【請求項７】
請求項６に記載の方法であって、受け取ったメッセージに連続番号を割り当てることを備える。
【請求項８】
先行するいずれかの請求項に記載の方法であって、受け取ったメッセージを、他の複数の受け取りメッセージと共にバッチングすることを含む。
【請求項９】
請求項８に記載の方法であって、ここでは、前記バッチングは、バッチングが実行されている処理ステージに依存する基準に基づいて実行される。
【請求項１０】
請求項８又は９に記載の方法であって、ここでは、前記バッチングは、ネットワーク待ち時間、ディスク待ち時間、及び処理されるべき前記データのうちの少なくとも一つに従って実行される。
【請求項１１】
請求項８〜１０のいずれか１項に記載の方法であって、さらに、前記メッセージが向けられた前記データ・パーティションに関連する前記コントローラに従ってメッセージをグループ化することを備える。
【請求項１２】
先行するいずれかの請求項に記載の方法であって、ここでは、単一のコントローラに関連する複数のデータ・パーティション中の前記データは、前記ノードのうちの一つに格納されている。
【請求項１３】
先行するいずれかの請求項に記載の方法であって、ここでは、第１のデータ・パーティション中の前記データは、あるユーザに関連するアカウントを規定している。
【請求項１４】
請求項１３に記載の方法であって、ここでは、第１のコントローラは、複数のアカウントに関連する操作を制御するためのアカウント・コントローラを備える。
【請求項１５】
請求項１３又は１４に記載の方法であって、ここでは、第２のデータ・パーティション中の前記データは、複数のユーザが賭けを提起できるマーケットを備える。
【請求項１６】
請求項１５に記載の方法であって、ここでは、第２のコントローラは、複数のマーケットに関連する操作を制御するためのマーケット・コントローラを備える。
【請求項１７】
先行するいずれかの請求項に記載の方法であって、ここでは、前記メッセージは、非同期で送信される。
【請求項１８】
先行するいずれかの請求項に記載の方法であって、ここでは、前記ノードがサーバを含む。
【請求項１９】
複数の分散されたノードを備えるシステムにおいてトランザクション処理方法を実行するためのコンピュータ可読命令を備えるコンピュータ可読媒体であって、前記ノードにおいては、複数のデータ・パーティション中にデータが保持されており、それぞれのパーティション中のデータは、対応する単一の前記ノードに関連付けられており、
前記システムは以下を含む：
データ・パーティションのグループを制御するための複数のコントローラ、ここで、各コントローラは、前記データ・パーティション中における前記データについての操作を実行するための複数の書き込みステージを備えており；そして、
実行スレッドを前記書き込みステージに割り当てるためのスレッド・マネージャ、ここで、前記スレッド・マネージャは、所定のデータ・パーティション中のデータについて操作するために、最大でも一つのスレッドを割り当てるようになっており、
前記コンピュータ可読命令は、以下を備える：
前記複数のコントローラのうちの第１のものにおいてメッセージを受け取るための第１の命令、ここで、前記メッセージは、所定のデータ・パーティションに関連するデータについて実行されるべき操作を規定する；
前記複数の書き込みステージの一つによって処理するために前記メッセージをキューイングするための第２の命令；そして、
前記所定のデータ・パーティションのために実行スレッドが利用可能な場合において、前記書き込みステージが前記メッセージを処理することを許可するための第３の命令。
【請求項２０】
請求項１９に記載のコンピュータ可読媒体であって、以下をさらに備える：
その後の処理のために、前記複数のコントローラのうちの第２のものに前記メッセージを送付するための第４の命令。
【請求項２１】
複数の分散されたノードを備えるシステムにおけるトランザクション処理のための装置であって、前記ノードにおいては、データは、複数のデータ・パーティション内に保持されており、対応するパーティション内のデータは、対応する単一の前記ノードに関連付けられており、
前記システムは、以下を備える：
データ・パーティションのグループを制御するための複数のコントローラ、ここで、各コントローラは、前記データ・パーティション中の前記データについての操作を実行するための複数の書き込みステージを備えており；そして、
実行のスレッドを前記書き込みステージに割り当てるためのスレッド・マネージャ、ここでは、前記スレッド・マネージャは、所定のデータ・パーティション中のデータの操作のために、最大で一つのスレッドを割り当てるようになっており、
前記装置は、以下を備える：
前記複数のコントローラのうちの第１のものにおいてメッセージを受け取るレシーバ、ここで、前記メッセージは、所定のデータ・パーティションに関連するデータについて実行されるべき操作を規定しており；そして、
前記メッセージを処理するための複数の書き込みステージ、ここでは、実行スレッドが前記所定のデータ・パーティションのために利用可能な場合には、書き込みステージは、一つ又は複数のメッセージを処理し、実行スレッドが利用できない場合には、前記装置は、前記メッセージをキューに配置するようになっている。
【請求項２２】
請求項２１に記載の装置であって、その後の処理のために、前記複数のコントローラのうちの第２のものに前記メッセージを送るためのディスパッチャを備える。
【請求項２３】
請求項２１又は２２に記載の装置であって、ここでは、あるアカウントに関係するデータは、単一のサーバ内に保存されている。
【請求項２４】
請求項２３に記載の装置であって、ここでは、アカウントのグループを制御するためのアカウント・コントローラをさらに備えている。
【請求項２５】
請求項１２〜２４のいずれか１項に記載の装置であって、ここでは、あるマーケットに関係するデータは、単一のサーバ内に保存されている。
【請求項２６】
請求項２５に記載の装置であって、ここでは、マーケットのグループを制御するためのマーケット・コントローラをさらに備えている。
【請求項２７】
請求項２３〜２６のいずれか１項に記載の装置であって、ここでは、単一のスレッドを、ある単一のアカウントあるいは単一のマーケットについて操作している第１の書き込みステージに割り付けるためのスレッド・マネージャをさらに備えている。
【請求項２８】
請求項２７に記載の装置であって、ここでは、前記単一のアカウントあるいは前記単一のマーケットへのアクセスを要求する第２の書き込みステージは、前記単一のスレッドが解放されるまで、アクセスを拒否される。
【請求項２９】
請求項２７又は２８に記載の装置であって、ここでは、前記第１の及び／又は前記第２の書き込みステージは、ある単一のアカウントあるいはマーケットに関係するメッセージのバッチを、単一の操作において処理するように構成されている。
【請求項３０】
請求項２１〜２９のいずれか１項に記載の装置であって、ここでは、複数の書き込みステージに影響するメッセージを処理するためのプリプロセッサをさらに備えている。
【請求項３１】
請求項３０に記載の装置であって、ここでは、前記プリプロセッサは、単一のメッセージ・ストリームを、複数のジャーナルされたメッセージ・ストリームから生成するようになっている。
【請求項３２】
請求項２１〜３１のいずれか１項に記載の装置であって、ここでは、メッセージが受け取られていないという通知に対応して、第１のノードから第２のノードにメッセージを再送信する手段をさらに備える。
【請求項３３】
請求項２１〜３２のいずれか１項に記載の装置であって、ここでは、大量に要求されたデータを提供するためのデータ・ディレクタのクラスタをさらに備える。
【請求項３４】
請求項２１〜３３のいずれか１項に記載の装置であって、ここでは、トランザクションを不揮発性メモリにジャーナルし、そして、トランザクションを作る操作を揮発性メモリにジャーナルする構成となっている。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６ａ】
【図６ｂ】
【図６ｃ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６ａ】
【図６ｂ】
【図６ｃ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公表番号】特表２０１０−５１２５９１（Ｐ２０１０−５１２５９１Ａ）
【公表日】平成２２年４月２２日（２０１０．４．２２）
【国際特許分類】
【出願番号】特願２００９−５４０７６８（Ｐ２００９−５４０７６８）
【出願日】平成１９年１２月１２日（２００７．１２．１２）
【国際出願番号】ＰＣＴ／ＥＰ２００７／０６３８４２
【国際公開番号】ＷＯ２００８／０７１７４８
【国際公開日】平成２０年６月１９日（２００８．６．１９）
【出願人】（５０２３５９９７６）ザ・スポーティング・エクスチェンジ・リミテッド (1)
【Ｆターム（参考）】
【公表日】平成２２年４月２２日（２０１０．４．２２）
【国際特許分類】
【出願日】平成１９年１２月１２日（２００７．１２．１２）
【国際出願番号】ＰＣＴ／ＥＰ２００７／０６３８４２
【国際公開番号】ＷＯ２００８／０７１７４８
【国際公開日】平成２０年６月１９日（２００８．６．１９）
【出願人】（５０２３５９９７６）ザ・スポーティング・エクスチェンジ・リミテッド (1)
【Ｆターム（参考）】
[ Back to top ]