各領域がアカウントに対応する複数の領域のあるデータキャッシュを使用してアカウント情報を処理する方法であって、前記方法は、ユーザからクエリー及びアカウント番号を受信するステップと、アカウント番号に対応するキャッシュ領域において、第1サブキャッシュでクエリーを検索するステップと、第1サブキャッシュでクエリーが発見されない場合には処理Aを行うステップと、第1サブキャッシュでクエリーが発見されない場合には第1サブキャッシュ内のクエリーとともに格納されるレコードデータをユーザに返すステップと、からなり、前記処理Aは、データストアにクエリーを送信し、データストアからクエリーに対する少なくとも1つのプライマリーキーを受信し、少なくとも1つのプライマリーキーの各々について、キャッシュ領域内の第2サブキャッシュでプライマリーキー及び対応するレコードデータを検索し、第2サブキャッシュでプライマリーキーが発見されない場合には、データストアからプライマリーキーに対応するレコードデータを取得し第2サブキャッシュにレコードデータ及びプライマリーキーを格納し、プライマリーキーに対応するレコードデータをユーザに返し、第1サブキャッシュに、クエリーとともにプライマリーキー及び対応するレコードデータを格納する、ことを特徴とする方法。データストア内のマスタデータが変更した場合のデータキャッシュを更新するための方法であって、前記方法は、データストア内のマスタデータを変更するための、プライマリーキー及び変更の種類を含む要求を受信するステップと、データストア内のテーブルにプライマリーキーを含む行を配置するステップと、行からセレクタキーを検索するステップと、行を含むテーブルをロックするステップと、実行中のキャッシュサーバのテーブルに一覧表示される各キャッシュサーバにメッセージを送信するステップと、各キャッシュサーバから肯定応答が受信されると、行を含むテーブルをアンロックし、要求を承認するステップと、からなることを特徴とする方法。メッセージがプライマリーキー、セレクタキー、及び変更の種類を含むことを特徴とする請求項2に記載の方法。各キャッシュサーバから応答を受信するために、予め定められた時間待機することをさらに備えることを特徴とする請求項2に記載の方法。セレクタキーがアカウント番号であることを特徴とする請求項2に記載の方法。トランザクションを処理するための、データストアを備えるシステムであって、前記データストアは、メモリと、プログラムを実行するように構成されたプロセッサとを備え、前記メモリは、複数のアカウントに該当するマスタデータを含む複数のテーブルと、方法を実行するプログラムとを格納するように構成され、前記方法は、プライマリーキー及び変更の種類を含む、データストア内のマスタデータを変更するための要求を受信し、データストア内のテーブルにプライマリーキーを含む行を配置し、行からセレクタキーを検索し、行を含んだテーブルをロックし、実行中のキャッシュサーバのテーブルに一覧表示される各キャッシュサーバにメッセージを送信し、各キャッシュサーバからの肯定応答受信時に行を含むテーブルをアンロックする、ことを特徴とするシステム。メッセージがプライマリーキー、セレクタキー、及び変更の種類を含むことを特徴とする請求項6に記載のシステム。方法が、各キャッシュサーバから応答を受信するために、予め定められた時間待機することを更に備えることを特徴とする請求項6に記載のシステム。セレクタキーがアカウント番号であることを特徴とする請求項6に記載のシステム。データストア内のアカウントデータが変更した場合のデータキャッシュを更新するための方法であって、前記方法は、格納されているアカウントデータを変更するための、プライマリーキーと変更の種類を含む要求を受信するステップと、データストア内のテーブルにプライマリーキーを含む行を配置するステップと、行からセレクタキーを検索するステップと、行をロックするステップと、セレクタキーに対応するデータキャッシュを決定するステップと、プライマリーキー、セレクタキー、及び変更の種類を含むメッセージを、決定されたデータキャッシュに送信するステップと、決定されたサーバから肯定の応答が受信されると、行をアンロックし、要求を承認するステップと、を備えることを特徴とする方法。決定されたサーバから応答を受信するために、予め定められた時間待機することをさらに備えることを特徴とする請求項10に記載の方法。変更の種類がデータストアからレコードを削除することであることを特徴とする請求項10に記載の方法。変更の種類がデータストアのレコードを更新することであることを特徴とする請求項10に記載の方法。変更の種類がデータストアにレコードを追加することであることを特徴とする請求項10に記載の方法。トランザクションを処理するための、データストアを備えるシステムであって、前記データストアは、メモリと、プログラムを実行するように構成されたプロセッサとを備え、前記メモリは、各テーブルがアカウントに対応する複数のテーブルと、方法を実行するプログラムとを格納するように構成され、前記方法は、格納されているアカウントデータを変更するための、プライマリーキー及び変更の種類を含む要求を受信し、データストア内のテーブルの中にプライマリーキーを含む行を配置し、行からセレクタキーを検索し、行をロックし、セレクタキーに対応するデータキャッシュを決定し、プライマリーキー、セレクタキー、及び変更の種類を含むメッセージを決定されたデータキャッシュに送信し、決定されたサーバからの肯定応答の受信時に行をアンロックする、ことを特徴とするシステム。方法が、決定されたサーバから応答を受信するために、予め定められた時間待機することをさらに備えることを特徴とする請求項15に記載のシステム。変更の種類がデータストアからレコードを削除することであることを特徴とする請求項15に記載のシステム。変更の種類がデータストアのレコードを更新することであることを特徴とする請求項15に記載のシステム。変更の種類がデータストアにレコードを追加することであることを特徴とする請求項15に記載のシステム。各領域がアカウントに対応する複数の領域を有するデータキャッシュであって、前記データキャッシュは、少なくとも1つのクエリーを、少なくとも1つのクエリーに対する結果とともに格納するように構成され、アカウント番号に対応する領域内の第1サブキャッシュと、プライマリーキーを含む少なくとも1つのエントリを、プライマリーキーに対応するレコードデータとともに格納するように構成され、アカウント番号に対応する領域内の第2サブキャッシュと、プロセッサとからなり、前記プロセッサは、アカウント番号、ターゲットプライマリーキー、及び変更の種類を含むメッセージを受信し、アカウント番号に対応する領域において、変更の種類が削除である場合にターゲットプライマリーキーを含む第2サブキャッシュからエントリを削除し、変更の種類が更新である場合に、ターゲットプライマリーキーを含む第2サブキャッシュからエントリを削除し、第1サブキャッシュのコンテンツを削除する、ことを特徴とするデータキャッシュ。プロセッサが、エントリが第1サブキャッシュから削除された後に、成功メッセージを送信するようにさらに構成されることを特徴とする請求項20に記載のデータキャッシュ。プロセッサが、エントリが第2サブキャッシュから削除された後に、成功メッセージを送信するようにさらに構成されることを特徴とする請求項20に記載のデータキャッシュ。プロセッサが、エントリが第1サブキャッシュから削除され、エントリが第2サブキャッシュから削除された後に、成功メッセージを送信するようにさらに構成されることを特徴とする請求項20に記載のデータキャッシュ。データストア内のデータが変更した場合にデータキャッシュを更新するための方法であって、前記方法は、アカウント番号に対応する領域内の第1サブキャッシュに、少なくとも1つのクエリーを、少なくとも1つのクエリーに対応する結果とともに格納するステップと、アカウント番号に対応するキャッシュ領域内の第2サブキャッシュに、プライマリーキーを含む少なくとも1つのエントリを、プライマリーキーに対応するレコードデータとともに格納するステップと、アカウント番号、ターゲットプライマリーキー、及び変更の種類を含むメッセージを受信するステップと、アカウント番号に対応する領域において、変更の種類が削除である場合にターゲットプライマリーキーを含む第2サブキャッシュからエントリを削除し、変更の種類が更新である場合にターゲットプライマリーキーを含む第2サブキャッシュからエントリを削除し、第1サブキャッシュのコンテンツを削除するステップと、を備えることを特徴とする方法。エントリが第1サブキャッシュから削除された後に成功メッセージを送信することをさらに備えることを特徴とする請求項24に記載の方法。エントリが第2サブキャッシュから削除された後に成功メッセージを送信することをさらに備えることを特徴とする請求項24に記載の方法。エントリが第1サブキャッシュから削除され、エントリが第2サブキャッシュから削除された後に、成功メッセージを送信することをさらに備えることを特徴とする請求項24に記載の方法。データストア内のマスタデータが変更した場合にデータキャッシュを更新するための方法であって、前記方法は、データストア内のマスタデータを変更するための、プライマリーキー及び変更の種類を含む要求を受信するステップと、データストア内のデータ構造にプライマリーキーを含むエントリからセレクタキーを検索するステップと、エントリを含むデータ構造をロックするステップと、実行中のキャッシュサーバ群で特定される各キャッシュサーバにメッセージを送信するステップと、各キャッシュサーバからの肯定応答受信時に、エントリを含むデータ構造をアンロックし、要求を承認するステップと、を備えることを特徴とする方法。メッセージがプライマリーキー、セレクタキー、及び変更の種類を含むことを特徴とする請求項28に記載の方法。各キャッシュサーバから応答を受信するために、予め定められた時間待機することをさらに備えることを特徴とする請求項28に記載の方法。セレクタキーがアカウント番号であることを特徴とする請求項28に記載の方法。詳細な説明本発明における以下の実施形態の説明は、添付図面を参照する。該当する場合、さまざまな図面の同じ参照番号は、同じ要素または類似要素を示す。図1は、本発明を実施するためのシステムの全体的なブロック図の一例である。図示されるように、複数のユーザ102がネットワーク106を介してトランザクション処理システム104と通信するためにコンピュータを使用する。ネットワーク106は、インターネット、WAN広域ネットワーク、またはLANローカルエリアネットワーク等の任意の種類の通信媒体であってよい。ユーザ102は、トランザクション処理システム104にトランザクション要求を送信可能である。株式取引や電子マネーによる支払いを含む、任意の種類のトランザクションが本発明の原理によって処理できる。この要求を処理するために、トランザクション処理システム104は、持続性のあるデータソース108に格納されるデータにアクセスする。図1には3人のユーザ102が示されているが、任意の数のユーザが、本発明におけるトランザクション処理システム104と通信可能である。同様に、複数のデータソース108が使用されてもよい。図2は、本発明を実施するためのシステムの詳細なブロック図の一例である。トランザクション処理システム104は、ユーザ202からの要求を処理するためのいくつかの構成要素を有している。これらの構成要素は、要求ディストリビュータ204、1台または複数台のアプリケーションサーバ206、1つまたは複数のデータキャッシュ208、及び1つのデータソース108である。要求ディストリビュータ204は、ユーザ202から要求を受信し、処理のためにその要求をアプリケーションサーバに割り当てる。要求ディストリビュータ204は、要求の結果をユーザ202に返すこともできる。複数のアプリケーションサーバが使用される場合には、要求ディストリビュータ204は、公知の分散技法を使用して複数台のアプリケーションサーバの間で要求を分散することによって、負荷バランシングを実行する。更に、要求ディストリビュータ204が、アプリケーションサーバが適切に機能していないと判断する場合、要求ディストリビュータ204は、他のアプリケーションサーバに要求を送り直してよい。要求ディストリビュータ204の機能が、プロキシサーバによって実行されてもよい。更に、ユーザ202とトランザクション処理システム104間の他の通信方法が、本発明に於いて使用されてもよい。トランザクション処理システム104は、データソース108からのデータを用いて、ユーザの要求を処理するためにアプリケーションサーバ206を使用する。性能を向上させるために、アプリケーションサーバ206は、直接的にデータソース108にアクセスしなくても、1つまたは複数のデータキャッシュ208にアクセスし、データを取得できる。このプロセスは、図7Aと図7Bに詳細に後述する。1つまたは複数のデータソース、1つまたは複数のデータキャッシュ、及び1台または複数台のアプリケーションサーバが、本発明に於いて使用されても良い。図3は、本発明における、データソースの詳細なブロック図である。データソース108は、ユーザからの要求を処理するために必要なデータを格納する。例えば、オンライン株式取引システムや他のトランザクションシステムでは、一般的に、ユーザは、そのユーザに一意であるアカウント番号アカウント番号は、口座番号、顧客番号、課金番号等を含むを有する。本発明の1つの実施形態では、データストア108はその一意のアカウント番号に基づいて、独自のアカウントテーブル302の中に各アカウントのデータを格納する。製品やサービスに関係するデータなどの全てのアカウントに該当するデータは、マスタテーブル104に格納される。1つのアカウントテーブル302と1つのマスタテーブル304が図3に示されているが、複数のアカウントテーブル及び/またはマスタテーブルが、本発明に於いて使用出来る。データソース108は、全ての実行中のデータキャッシュのテーブル308、及びアカウントを実行中のデータキャッシュと関連づける関連リスト310も含む。これらは、後述するように、データキャッシュ206との同期を維持するために使用される。本発明の1つの実施形態では、一人のアカウントについてのデータは、1つのアカウントテーブルの中に格納され、1つのデータキャッシュの中にキャッシュされる。この実施形態を実現するために、関連リスト310は、各アカウントテーブルのリストを、そのアカウントテーブルからのデータのコピーを格納するデータキャッシュ208に対するリファレンスとともに格納する。それから、関連リスト310は、アカウントテーブル中のデータが変更すると、適切なデータキャッシュに通知するために用いられる。関連リスト310は、アカウントがデータキャッシュに割り当てられるたびに、要求ディストリビュータ204によって更新できる。この割り当ては、ユーザがシステムにログオンすると開始し、ユーザがシステムをログアウトするまで続行される。関連リスト310は、図7Aと図7Bで後述するように、クエリーをどのキャッシュに送るのかを決定するために要求ディストリビュータ204によってアクセスされる。テーブル308は、トランザクション処理システム104内で実行中である全てのデータキャッシュに対するリファレンスを有する。マスタテーブル中のデータが変更されると、それは全てのアカウントに影響を及ぼす可能性があるため、このような変更はテーブル308に一覧表示される全てのデータキャッシュ208に伝達できる。テーブル308は、新しいデータキャッシュが追加されるたびに、トランザクション処理システム208によって更新できる。このようにしてデータを格納すると、本発明は、例えばアカウント番号ごとにデータを領域化できるトランザクションシステムで特に役に立つ。本発明の1つの実施形態では、データソース108は、アカウント番号などのセレクタキーのロックを動作可能にするセレクタロックテーブルを有する。セレクタキーはセレクタロックテーブルを使用してロックされるが、そのセレクタキーに対応するデータに変更を加えることはできない。データソース108は、トランザクション処理システム104などのクライアントプロセスと通信するために、プロセス間通信チャネル306を用いる。プロセス間通信チャネル306は、例えば、Oracle登録商標DMBS-PIPE、Java登録商標RMI、またはデータソース108とデータキャッシュ208間での確実な情報の転送を実現する任意の他の技法を使用して実現できる。データソース108の追加機能は、リレーショナル方式でデータを格納することと、コミットされたデータを読み取ることと、プライマリーキーのクエリーを処理することと、必要に応じて行またはテーブルをロックすることと、データが変更するときにイベントを生成することとを有しても良い。これらは、数多くのデータベース管理システムの公知の機能である。従って、データソース108は、Java登録商標DatabaseConnectivityJDBC、SQL、及びOracle登録商標DatabaseManagementSystemDBMSなどの利用可能なソフトウェアを使用して実現できる。説明を容易にするために、本説明では、データソース108をこれらの特徴を持つデータベースとして扱う。ただし、これらの機能を実現する確立されたプロトコルに準拠するリモートサーバなどの、任意の持続性のあるデータソースが本発明を実施するには十分である。図4は、本発明における、サンプルアカウントテーブル402を示す。サンプルアカウントテーブル402に格納されるデータは、各行がプライマリーキーで特定される行で編成される。各プライマリーキーに対応するのは、レコードデータと行ロックである。アカウントテーブルの中では、プライマリーキーと、その対応するレコードデータは、以下のように定義されても良い。すなわち、プライマリーキー=アカウント番号、レコードデータ=現在残高、銀行支店番号である。行ロックが動作可能とされると、行の中の情報に変更を加えることはできない。他の実施形態では、テーブルロックや別個のロックテーブルが使用できるか、あるいは行ロックは完全に省略できる。レコードデータは、サンプルアカウントテーブル402に対応するデータセットを特定するセレクタキーも有する。例えば、アカウントに基づくシステムでは、セレクタキーがアカウント番号となる場合がある。他の実施形態では、テーブルがプライマリーキーを有していなくても良い。このような実施形態では、データソース108内の行を特定するために、データソースに特殊な識別子を使用できる。図5は、本発明における、サンプルマスタテーブルを示す。サンプルマスタテーブル502に格納されるデータは、プライマリーキーによって行で編成される。各プライマリーキーに対応するのはレコードデータである。マスタテーブルでは、プライマリーキー及びそれに対応するレコードデータは、以下のように定義されても良い。すなわち、プライマリーキー=製品SKU在庫維持単位数、レコードデータ=製品名、製造メーカ識別子である。サンプルマスタテーブルは、テーブルロックを有する。テーブルロックが動作可能とされると、テーブルの中の情報に変更を加えることはできない。他の実施形態では、このロックは、行ロック、別個のロックテーブを使用して実現できるか、あるいは完全に省略できる。レコードデータは、サンプルマスタテーブル502に対応するデータセットを特定するセレクタキーを有する。アカウントに基づくシステムでは、マスタデータは、全てのアカウントに当てはまるデータである場合がある。従って、マスタデータにとっては、セレクタキーは、データが全てのアカウントに当てはまることを示すための1または0などの公知の数である場合がある。図6は、データキャッシュを詳細に示すブロック図である。データキャッシュ602は、1つまたは複数の領域に分割される。本発明の1つの実施形態では、各領域は、データソース108に格納されるアカウントテーブルに相当する。この実施形態では、単一のデータキャッシュは、多くのアカウントをサポートすることができ、システムが追加アカウントをサポートする必要があるときには、追加のデータキャッシュを追加できる。データキャッシュ602の中の各領域は、その領域内のデータセットを特定するセレクタキー604を有する。例えば、ユーザのアカウントに対応するデータが領域に格納される場合、セレクタキーはアカウント番号となっても良い。セレクタキー604に加えて、データキャッシュの各領域は2つのサブキャッシュを有する。すなわち、Implキャッシュ806とEnumキャッシュ608である。これらのサブキャッシュは、データソース108から検索されるデータのコピーを格納する。Implキャッシュ606内のエントリは、プライマリーキー610と対応するレコードデータ612を有する。Implキャッシュ606は、データソース108にアクセスしなくてもデータアイテムに対する要求を容易にするために使用できる。例えば、ユーザが自分の口座残高の要求を送信すると、その要求を処理するアプリケーションサーバは、プライマリーキーアカウント番号口座番号で、適切なImplキャッシュ606から検索をし、対応するレコードデータ例えば、現在残高、銀行支店番号を返す。クエリーの処理は、図7Aと図7Bに詳述する。Enumキャッシュ608内のエントリは、クエリー614及びそのクエリーを満たすレコードが対応するリスト616を有する。Enumキャッシュ608は、データソース108にアクセスしなくても、より複雑なクエリーを容易にするために使用できる。例えば、ユーザが、自分の最も最近の株式購入のリストに対する要求を送信すると、その要求を処理するアプリケーションサーバは、クエリー最新の株式購入を、適切なEnumキャッシュ608から検索し、そのクエリーを満たすレコードが対応するリストを返す。クエリーの処理は、図7Aと図7Bに詳述する。図7Aと図7Bは、本発明における、データキャッシュ方式を使用してクエリーを処理するためのフローチャート図を示す。プロセスは、アプリケーションサーバ206が、ユーザ202からセレクタキーを含むクエリーを受信すると開始するステップ702。このクエリーは、要求ディストリビュータ204によって、アプリケーションサーバ206に送信される。1つの実施形態では、要求ディストリビュータ204は、各アカウントが割り当てられているアプリケーションサーバ及び/またはデータキャッシュのレコードを維持する。従って、要求ディストリビュータ204はクエリーを受信すると、要求ディストリビュータ204は、適切なアプリケーションサーバ及び/またはデータキャッシュにクエリーを送信する。他にも、要求ディストリビュータ204及びアプリケーションサーバ206は、データストア108内の関連リスト310にアクセス可能である。クエリーを処理するために、アプリケーションサーバ206はクエリーからのセレクタキーを使用し、必要な情報を、どのデータキャッシュが格納している可能性があるのか、すなわちこのセレクタキーによって特定されるデータのサブセットを、どのデータキャッシュが格納しているのかを判断する。アカウントに基づく実施では、セレクタキーがユーザのアカウント番号となっても良く、アプリケーションサーバ206は、ユーザのアカウントのデータを、どのデータキャッシュ領域が格納するのかを判断するために、アカウント番号を使用する。そのデータキャッシュ内では、アプリケーションサーバ206が、クエリーからの、セレクタキーを含む領域内で1つまたは複数の検索を実行する。クエリー処理を開始する前に、セレクタキーについてセレクタロックを獲得するステップ703。セレクタロックが入手できない場合、すなわち、他のプロセスがセレクタキーをロックしている場合は、クエリーはデータソースを使用して処理することができ、結果はキャッシュされない。このようにして、クエリーは、キャッシュが利用できなくても処理することができる。セレクタロックを獲得するとステップ703、アプリケーションサーバ206は、セレクタキーステップ704を含むキャッシュ領域内で、Enumキャッシュ内のクエリーを検索する。クエリーを満たすレコードのリストがEnumキャッシュ内に存在する場合にはステップ706、アプリケーションサーバ206はレコードのそのリストをユーザに返すステップ708。存在しない場合は、アプリケーションサーバ206はデータソース108にクエリーを送信するステップ710。データソース108は、公知のデータベースツールを使用してクエリーを処理し、クエリーの結果を示す1つまたは複数のプライマリーキーを返すステップ712。従って、この処理を完了するためには、アプリケーションサーバ206は、1つまたは複数のプライマリーキーの各々に対応するレコードデータを取得しなければならない。これを行うために、アプリケーションサーバ206は、Implキャッシュで、次のプライマリーキーを検索するステップ714。次のプライマリーキーがImplキャッシュ内で発見されると、アプリケーションサーバ206は、対応するレコードデータを、Implキャッシュからクエリーの結果に追加するステップ716。次のプライマリーキーが発見されない場合、アプリケーションサーバ206は、データソース108から、対応するレコードデータを取得するステップ718。データソースは、公知のデータベースツールを使用して検索要求を処理し、次のプライマリーキーに対応するレコードデータを返す。その後、アプリケーションサーバ206は、次のプライマリーキー及びその対応するレコードデータをImplキャッシュの中に格納しステップ720、レコードデータをクエリーの結果ステップ716に追加する。このようにして、Implキャッシュは、将来のクエリーの処理を改良するために更新される。ステップ712に於いて、データソース108によって複数のプライマリーキーが返されると、各プライマリーキーに対応するレコードデータが取得され、クエリーの結果に追加されるまで、プロセスを繰り返すステップ722。次に、アプリケーションサーバ206は、クエリーを含むエントリ及びクエリーの結果をEnumキャッシュに追加しステップ724、ユーザ202にクエリーの結果を返すステップ726。このようにして、Enumキャッシュは、将来のクエリーの処理を改良するために更新される。最後に、セレクタロックが解放されるステップ727。上述したように、データソース108及びデータキャッシュ208内でのアカウントに従ったデータの領域化により、アプリケーションサーバ206は、基礎をなすデータについての知識がなくても非常に迅速にクエリーを処理することができる。このデータ領域化の他の利点は、データストア108内に格納されるデータに対するあらゆる変更が、図8、図9及び図10に関して後述するように、シームレス且つ効率的にデータキャッシュ208と共用されるように、データキャッシュ208をデータソース108と同期させることである。他の利点としては、データソースに対する変更が、図8に関して後述するように、データキャッシュから削除される項目の数を最小にするという点である。図8は、データソース108内のマスタデータが変更するときに、データキャッシュを更新するためのプロセスを示すフローチャート図である。このプロセスは、あるプロセスが、マスタテーブル内のプライマリーキーに対応する行でマスタデータすなわち、全てのアカウントに影響を及ぼすデータを変更しようとするときに開始するステップ802。これは、例えば、システム管理者がトランザクション処理システムに新製品を付加するときに発生する可能性がある。データソース108は、変更する行を含むテーブルをロックしステップ804、変更する行からセレクタキーを検索するステップ806。ロックが使用できない場合、データソースは、ロックが使用できるようになるまで待機するか、あるいはトランザクションを打ち切ることができる。上述したように、マスタデータのセレクタキーは、例えば、データが全てのアカウントに影響を及ぼすことを示すために、0または-1などの予め定められた番号であってよい。変更をデータキャッシュ208に警告するために、データストア108は、全ての実行中のデータキャッシュのテーブル308内に一覧表示される全てのデータキャッシュに無効メッセージを送信するステップ808。この無効メッセージは、変更している行のプライマリーキー、セレクタキー、及び行の変更の種類すなわち、追加、変更、または削除を有している。データストア108は、プロセス間通信チャネル306を介してデータキャッシュに無効メッセージを送信する。データストア108は、各データキャッシュから応答を受信するために、予め定められた時間待機するステップ810。データキャッシュの全てが無事に応答するとステップ812、キャッシュを無効にし、データストア108は、変更可能とするためにテーブルをアンロックするステップ814。データキャッシュの全てが無事に応答しない場合には、トランザクションを打ち切るステップ816。例えば、データキャッシュがクラッシュした場合に、データキャッシュは無事に応答できない。図9は、データソース108内のアカウントデータが変更するときに、データキャッシュを更新するためのプロセスを示すフローチャート図である。このプロセスは、あるプロセスが、アカウントテーブル内のプライマリーキーに対応する行の中のアカウントデータを変更しようとするときに開始するステップ902。これは、例えば、株式取引が実行されるとき、または電子マネーによる支払いが素早く処理されたときに発生する可能性がある。データソース108は、変更している行をロックしステップ904、変更している行からセレクタキーを検索するステップ906。ロックが使用できない場合、データソース108は、ロックが使用できるようになるまで待機するか、あるいはトランザクションを打ち切る。行がロックされると、他のプロセスは行の中のデータを修正することはできない。データソース108は、関連リスト310を使用して、どのデータキャッシュがセレクタキーに対応するのかすなわち、どのデータキャッシュがこのアカウントのためのデータを格納するのかを判断する。適切なデータキャッシュに変更を警告するため、データストア108は、判断されたデータキャッシュに無効メッセージを送信するステップ910。無効メッセージは、プライマリーキー、セレクタキー、及び変更の種類すなわち、追加、変更、または削除を有する。データストア108は、プロセス間通信チャネル306を介してデータキャッシュに無効メッセージを送信する。データストア108は、データキャッシュから応答を受信するために、予め定められた時間待機するステップ912。データキャッシュが無事に応答するとステップ914、キャッシュは無効にされ、データストア108が、変更可能とするために行をアンロックするステップ916。データキャッシュが無事に応答しない場合には、トランザクションを打ち切るステップ918。例えば、データキャッシュがクラッシュすると、データキャッシュは無事に応答できない。図10は、データソースの変更に対してキャッシュを無効にするプロセスを示したフローチャート図である。このプロセスは、無効メッセージがデータキャッシュによって受信されると開始するステップ1002。上述したように、無効メッセージは、基礎をなすデータソースの中のデータが変更した旨を示す。無効メッセージはプライマリーキー、セレクタキーを有する。変更の種類が削除または更新のどちらかである場合にはステップ1004、プライマリーキーに対応する、基礎をなすレコードデータが変更され、データキャッシュはこのデータの全ての古い期限切れのコピーを削除する。これを実行するために、セレクタキーに対応するデータキャッシュの領域の中では、プライマリーキーを含む全てのエントリが削除されるステップ1006。これにより、プライマリーキーを含む、それ以降の要求で古いレコードデータが検索されないこととなる。更に、いったん基礎をなすレコードデータが変更されると、格納されるクエリーの結果が影響を受ける可能性がある。従って、セレクタキーに対応するキャッシュ領域内の全ての格納されるクエリーの結果が削除される。これを行うためには、セレクタキーに対応するデータキャッシュの領域内のEnumキャッシュから、全てのエントリが削除されるステップ1010。変更の種類が挿入である場合にはステップ1008、Implキャッシュ内の公知のレコードデータを変更する必要はないが、格納されているクエリーの結果は正確であると信頼できなくなる。従って、セレクタキーに対応するキャッシュ領域内の全ての格納されるクエリー結果は削除される。これを行うために、セレクタキーに対応するデータキャッシュの領域内のEnumキャッシュから、全てのエントリが削除されるステップ1010。ここに説明したように、本発明は、データサイズが極端に大きくなるにつれ、性能は劣化しないことを意味する、極めて拡張性の高いデータをキャッシュに入れるための技法を実現する。更に、上述の方法を使用して、データキャッシュは、基礎をなすデータソースと同期し、その結果データがコミットされるときと、それが最初にキャッシュ内で入手可能になるときの間に遅延はない。この技法は、ユーザごとのアカウント情報及びユーザ全体の製品情報がおもに分離できる、オンライン株式取引システムなどの高負荷高容量トランザクションシステムで特に役立つ。しかしながら、本発明は、容易に領域化されないデータを格納するためのシステムでもその効果を発揮する。本発明の実施形態の上述の説明は、図解及び説明の為に示している。それは全ての例ではなく、ここで開示した実施形態に限定するものではない。変型やバリエーションは、上述の記載から可能であり、あるいは本発明の実施から得られる。本発明の追加の変型やバリエーションは、例えば、説明した実施形態ではソフトウェアを含むが、本発明は、ハードウェアとソフトウェアの組み合わせ、あるいはハードウェアだけで実現されてもよい。本発明は、オブジェクト指向型と非オブジェクト指向型の両方のプログラミングシステムにより実現可能である。更に、当業者は他の構成により、本発明を実現可能である。例えば、データキャッシュは、性能向上を実現する為に、アプリケーションサーバと組み合わせることができる。他の実施形態では、無効メッセージは、アカウントデータが変更するのか、マスタデータが変更するのかに関係なく、全てのデータキャッシュに一斉送信できても良い。この場合、データのアカウントに特殊な領域かを用いることは必要ない場合もある。他の実施形態は、同時複数領域化方式を用いることも可能である。更に、本発明の態様はメモリに格納されると説明したが、これらの態様が、ハードディスク、磁気ディスク、またはCD-ROMのような二次格納装置などの他の種類のコンピュータ読取可能な媒体、インターネットや他の搬送媒体からの搬送波、あるいは他の形式のRAMまたはROMに格納できる。発明の範囲は、クレーム及びその同等物により定義される。