JP5844333B2 - 持続的データ記憶技術 - Google Patents

Description

発明の詳細な説明

分野

本発明は、持続的データ記憶技術に関する。

背景

大規模データベースシステムは、何百万人ものユーザーがアクセスできる何百万もの記録を収納する可能性がある。潜在的に、記録に対する何万件ものデータアクセスが毎秒発生する可能性がある。データベースシステムは、多数のプロセッサ上で実行するプロセスによってアクセスされるデータ記憶デバイスを内含することができる。記憶デバイス及びプロセッサは、ネットワークを介して接続されたさまざまな場所に分散されていてよい。例えば大型小売りビジネスは、その顧客の氏名及び住所を維持する第１の記憶デバイス、在庫リストを維持する第２の記憶デバイス及びその顧客の購買履歴を維持する第３の記憶デバイスを有することが可能である。第１の記憶デバイスはボストンに、第２の記憶デバイスはロサンゼルスにそして第３の記憶デバイスはシカゴに置かれている。各記憶デバイスは、広域ネットワーク（ＷＡＮ）によってその他と接続されているそれぞれ異なる１台のプロセッサによって管理される。１人の顧客 リーサ(Lisa) が、例えば小売りビジネスによって操作される呼出し処理センター内の１人の社員を通してコーヒーテーブルを発注した場合、その社員は、ＷＡＮを介して、そのコーヒーテーブルがロサンゼルスの記憶デバイスから入手可能であるか否かをチェックしなくてはならない。この社員は、出荷のための リーサの住所を検索し彼女の購買履歴を更新するためその他の場所にある記憶デバイスにアクセスする必要があるかもしれない。同時に、もう１人の顧客 ロビン(Robyn)が、呼出し処理センター内でもう１人の社員を通して同じコーヒーテーブルを注文する可能性がある。両方の社員共、同じ記憶デバイスから読取り、そのコーヒーテーブルについての同じ在庫記録を更新しようとすることになる。

上述の例では、３つの異なる記憶デバイスは、通常独立した形でアクセスされうる異なるタイプのデータ記録を収納している。上述の例におけるように、多数のプロセッサを使用すると、データアクセスが独立しており、各アクセスが異なるプロセッサ上で並行して実行できるかぎりにおいて、スループット及びロードバランシングに関するデータベースシステムの性能を改善させることが可能である。

分散データベースシステムは、多数のプロセスによってアクセス可能であることから、プロセスが適切に調和されない場合、矛盾が発生する可能性がある。矛盾の例としては、２つのプロセスが２つの異なる値で同時に同じ記録を更新しようとしている（コーヒーテーブルの例のように）；１つのプロセスがもう１つのプロセスにより削除されている記録を読みとろうとしている；及び１つのプロセスがもう１つのプロセスによって更新されつつある関連記録にリンクする記録を更新しようとしている、といったものがある。矛盾が発生した場合、同じ又は関連データ記録にアクセスするプロセスの動作は予測不可能な形でインターリーブし、従ってオペレーションの結果は不正なものとなり、データベースシステムのデータの一貫性を破壊する可能性がある。

矛盾を解決するための１つのアプローチでは、プロセスが、１つのデータピース内のデータ入力にアクセスしているときそのデータピース（例えば変数、顧客記録又は、部門データベース）をロックし、プロセスがアクセスを終了した時点でロックを解除するセマフォが使用される。その他のプロセスは全て、いずれかのプロセスが現在それを使用しているか否かを見るためデータピースにアクセスする前にこのセマフォをチェックしなければならない。このアプローチは、ロックできるデータピースの細分性が小さい場合何百万ものデータピースについての何百万ものロックを必要とする可能性があり、そうでなければ、例えば部門データベース全体をロックすることで同じ部門データベース内に偶然記憶されることになった共通の要素をもたないデータセットにアクセスするジョブの効率の良い並行実行が妨げられることから、データベースの細分性が大きい場合には数多くのアクセスをブロックする可能性がある。

矛盾に加えて、大規模なデータベースシステムは同様に不充分なデータアクセスにも苦しめられる可能性がある。記憶デバイス内の１つのデータ記録の位置を特定するためだけにデータベースシステム全体を探索することを避けるため、データ記録の要約情報（例えば目次、インデックス又はクロスリファレンス）が通常、容易に探索できる書式で提供される。ただし、要約情報では、データ記録との一貫性がつねに強化されていないかぎり破損する可能性がある。その上、要約情報を更新するタスクも同様に矛盾を作り出す可能性があり、従って効果的にスケジュールされなければならない。

一般に、１つの態様においては、本発明は、データを持続的に記憶するデータベースを維持すること；一部分がそのデータベースの領域の使用のための競合する必要条件をもつタスクをタスクソースから受諾することであって、領域の各々は、一定の与えられた時点で全てが書込みについてロックされるか又はロックされていないかのいずれかであるデータを内含していること；利用可能なプロセッサと各領域を結びつけること；プロセッサのうちのわずか１つによりアクセスされるべき領域に対する書込みアクセスを各々が必要とするジョブを、各タスクについて定義すること；及び、結びつけられたプロセッサによる同調実行のためジョブを分散させること；を含んで成る方法に関する。

本発明の実施には以下の特長のうちの１つ以上のものが内含されていてよい。記憶されたデータには、オブジェクトデータベース内にオブジェクトを含むデータベースのデータ項目が内含されている。記憶されたデータには、オブジェクト指向アプリケーションに対するオブジェクトとして提供されるデータ項目が内含されている。オブジェクト関係ブローカが、オブジェクト指向アプリケーションのためのオブジェクトの持続的記憶を提供する。データは、オブジェクト指向の拡張との関係データベース内に記憶されている。データベースは、データを持続的に記憶するファイルを含んで成る。タスクソースから受諾されたタスクの数は、恣意的に多い。受諾されるタスクが由来するタスクソースの数は、恣意的に多い。領域は、コンテンションスペースの形に組織され、コンテンションスペースの数は、利用可能なプロセッサの数と同様である。各々のジョブは、わずか１つのコンテンションスペース内のデータへの書込みアクセスを必要としている。コンテンションスペースの数は、利用可能なプロセッサの数に等しい。コンテンションスペースへの領域の組織は、ジョブの実行において利用可能なプロセッサのスループットを最大限にする。コンテンションスペースは、利用可能なプロセッサのスループットを最大限にするべくプロセッサに対し動的に割当てされている。タスクは、非同期的に受諾される。タスクは同時に受諾される。プロセッサは、共用メモリを使用しない。

各タスクのためのジョブを定義することには、階層の最も低いレベルにジョブが収納されるサブタスク階層を定義することが含まれている。タスクのうちの少なくとも１つは、単一ジョブを含んで成る。１つのジョブでは、実施すべきタスクを生成する。タスクの各々は、要求されたデータベーストランザクション内で更新されたデータが、そのトランザクションがひとたびコミットされた時点で喪失されないという確実性と少なくとも同じ位高い確実性で完成される。領域は、単一のデータ項目を含む。領域は、少なくとも１００万個のデータ項目を含む。ジョブは、いずれかの領域上の何らかの書込みロックの解除を待つ必要なく同時に実行される。コンテンションスペースのうちの１つ以上のものがプロセッサの１つと結びつけられている。各々のプロセッサは、少なくとも１つのプロセスをランする物理的プロセッサを含む。各々のタスクは、ユーザー要求によって生成される。コンテンションスペースの各々は、ジョブを実行するもの及び結びつけられたコンテンションスペースに関して管理機能を実行するものという少なくとも２つのプロセッサと結びつけられている。

ジョブの分散には、実行を必要とするものであると予測されているジョブの数に比例してプロセッサを付加することにより、恣意的に大きい速度での実行のためジョブを受取る能力をもつ待ち行列システムを維持することが含まれている。待ち行列システムには、各々がジョブを受理できる概念上の行が内含されている。各々の行は、ジョブが行内に受入れられつつあるときにロックされる。ロックされていない行のいずれからでも、実行のため対応するプロセッサによりジョブが受諾され得る。多数の領域がコンテンションスペースに属する。付加的なジョブが、ジョブの実行と関連して新規作成される。さらなるジョブが付加的ジョブにより新規作成される。付加的ジョブの新規作成は、ジョブを実行する上でデータベースから読取られるデータによって左右される。付加的ジョブは、ジョブの実行と関連して新規作成され、プロセッサの１つの上でランしているプロセスがジョブを実行し付加的なジョブを新規作成し、かつ付加的ジョブのうちの少なくともいくつかが、その他のプロセッサによりサービス提供されているコンテンションスペースの間で分散されている。タスクは、商取引に関するものである。

ジョブの各々には、対応するコンテンションスペースと結びつけられたインデックスが割当てられる。インデックスは、プロセッサ間でジョブをロードバランシングするために使用される。データベースは、異なる物理的場所の間で分散されているデータベース単位を内含する。各々のジョブは、ステップを含んでいる。ジョブの実行には、ステップの一部分を実行すること、これらのステップを表わすデータベーストランザクションをコミットすること及びジョブが完了するまで反復することが含まれる。ステップのいずれかの部分が完了できなかった時点で、要求されたトランザクション内に書込まれたデータはそのトランザクションが一旦コミットされたならば喪失しないという確実性と少なくとも同レベルの確実性で、不履行部分の第１ステップにおいて実行が再開される。プロセッサがその行からジョブを受諾している時は読取りについてのみ行がロックされている。

ジョブの分散には、いずれかの恣意的に大きい速度での実行のためにジョブを受取る能力をもつ待ち行列システムを維持することが含まれている。待ち行列システムには、各々がジョブを受理できる概念的行及びそれぞれのコンテンションスペースと結びつけられた概念的列が含まれている。待ち行列システムは、行と列の交差点にセルの概念的マトリックスを含んで成り、各々のセルは、その他のセルに対する読取り及び書込みと矛盾することなく読取り又は書込みが可能である。行は、ジョブソースと結びつけられ、行の数は、全てのジョブソースが同時にキューの中にジョブをロードできるようにするのに充分なものである。行の数は、全ての列から実行のためにジョブを同時に取出しできるようにするのに充分なものである。

ジョブの同期化グループの実行は、結果の正しさを確保するため同期化される。同期化には、同期化グループの各々のジョブに対して、それらをそのグループのメンバーとして識別するタグを割当てることが内含されている。同期化には、同期化グループの各々のジョブに対し、そのグループ内のそのジョブの参加割合を表わす定数分数を割当てることが含まれる。同期化グループ内の全てのジョブがいつでもプロセッサにより実行できる状態になるまでジョブは実行されない。

一般に、もう１つの態様では、本発明は、次のものを内含する方法に関する：データを持続的に記憶するデータベース；（ａ）一定の与えられた時点で書込みについて全てロックされているか又はされていないかのいずれかであるデータを各々含むデータベースの複数の領域を使用するための競合する必要条件を有するものを少なくともいくつか含む恣意的に数の多いタスクを、恣意的に数の多いタスクソースから非同期的に受諾し、（ｂ）各々が利用可能な異なるプロセッサと結びつけられた矛盾しないコンテンションスペースの形に領域を組織し、（ｃ）わずか１つのコンテンションスペースに属する領域への書込みアクセスを各々が必要とするジョブの形に各々のタスクを分割し、かつ（ｄ）結びつけられたプロセッサによる同時実行のため対応するコンテンションスペースに対してジョブを分散するジョブ処理機構。オブジェクト関係ブローカーが、オブジェクト指向アプリケーションのためのオブジェクトの持続的記憶を提供する。データは、オブジェクト指向拡張と共に関係データベース内に記憶される。

一般に、もう１つの態様では、本発明は、機械上で実行されるように構成されたソフトウエアオブジェクトにおいて、データを持続的に記憶するデータベースの領域に対するアクセスを必要とし、データベースの領域内のデータに対する命令及びポインタを含む実行すべきジョブ、及びデータベースの領域内に書込むべき競合する必要条件を有するジョブのコンテンションスペースを識別し、データベースの領域内に書込むべき競合する必要条件をもたないジョブのその他のコンテンションスペースから該コンテンションスペースを区別するインデックスを含んで成るオブジェクトに関する。

本発明の実現には、以下のような特長のうちの１つ以上のものが内含されていてよい。すなわち記憶されたデータには、オブジェクトデータベース内にオブジェクトを含むデータベースのデータ項目が内含されている。記憶されたデータには、オブジェクト指向アプリケーションに対するオブジェクトとして提供されるデータ項目が内含されている。オブジェクト関係ブローカが、オブジェクト指向アプリケーションのためのオブジェクトの持続的記憶を提供する。データは、オブジェクト指向の拡張との関係データベース内に記憶されている。行及び列の形に配置されたセルを含むキューにおいて、行内のセルは持続的データベース内にデータを書込むためジョブを受理するように構成されており、列内のセルはプロセッサによる処理のためジョブを送達するべく構成されており、さらにジョブが行内に書込まれているとき、書込みについてのみ行のセルの全てをロックし、ジョブが列から送達されつつあるとき書込みについて列のセルのうち１つのみをロックするキュー制御機構を含んで成り、キュー内の行の数は、一度にジョブを少なくとも１つの行に書込むことができ全てのプロセッサが列の１つからジョブを受けとることができるのに充分なものであるキュー。書込みには、更新又は挿入が含まれる。データは、オブジェクトデータベース内にオブジェクトを含むデータベースのデータ項目を内含する。データは、オブジェクト指向アプリケーションに対するオブジェクトとして提供されるデータ項目を含む。オブジェクト関係ブローカーがオブジェクト指向アプリケーションのためのオブジェクトの持続的記憶を提供する。データは、オブジェクト指向の拡張と共に関係データベース内に記憶される。

一般に、もう１つの態様においては、本発明は、（ａ）データを持続的に記憶し、要求されたトランザクション内で書込まれたデータはそのトランザクションがひとたびコミットされた時点で喪失しないという一次レベルの保証を提供するデータベースを維持すること、（ｂ）データベースの同じ要領域内に書込むべき矛盾する必要条件をその少なくとも一部が有しているタスクを、多数のプロセッサによる同時実行のためタスクソースから受諾すること及び、（ｃ）データ喪失がなくかつデータベースの領域に関していかなる実際の矛盾も発生することなくそのタスクが実行されることになるということを、少なくとも一次的保証レベルまで保証するソフトウエア機構を提供すること、を含んで成る方法に関する。

本発明の実現には、以下のような特長の１つ以上のものが含まれていてよい。この方法には、タスクソースに対しタスク受諾の肯定応答及び受諾されたタスクの完了後の通知を送ることが内含されている。タスクは、ジョブ間の実際の矛盾をことごとく妨げるような形で多重プロセッサのうちの異なるプロセッサによって実行されるジョブへと分割される。ジョブは、タスクの完了を見極めることができるようにする同期化機構に付される。この同期化機構には、一群のジョブ内に参加するものとしてジョブを識別するタグが含まれている。同期化機構には、グループ内のジョブの参入割合を表わす定数分数が含まれる。この方法は、１グループの全てのジョブの定数分数が合計で１つの完成した定数となるか否かを見極めることを含んでいる。タスクには、全てのジョブが完了した時点で完了の通知が与えられる。タスクはコンテンションスペースに割当てられる。完了通知ジョブは、タスクと同じコンテンションスペース内での実行のため割当てられる。データベースは、オブジェクト指向のデータベースを含む。

一般に、もう１つの態様においては、本発明は、データを持続的に記憶するデータベースを維持すること、プロセッサによる同時実行のためジョブを受諾することであって、ジョブがデータベース内のデータへのアクセスを必要とし、ジョブの少なくともいくつかはグループとしての実行を必要とし、１グループのジョブの各々が、該グループ内へのその参加を定義する結びつけられた情報を有していること、を含んで成る方法において、１つのプロセッサが、結びつけられた情報から該グループのジョブの全てについて処理が進行しうることを見極めるまで、グループのジョブのいずれも実行することを控えている方法に関する。

本発明の実現には、以下の特長のうちの１つ以上のものが含まれていてよい；すなわち、グループとしての実行のために受諾されているショブは、その他のジョブを分岐することによって新規作成される。その他のジョブの分岐は、恣意的に深い一連のことを経て発生する。１グループのジョブと結びつけられた情報は、ジョブの新規作成時点で生成される。情報には、グループ内に参加するものとしてジョブを識別するタグが含まれる。情報には、そのグループ内におけるジョブの参入割合を表わす定数分数が含まれ、１グループの全てのジョブの定数分数が合計して１つの完成した定数となるか否かを見極めることも含まれる。

一般に、もう１つの態様においては、本発明は、データを持続的に記憶するデータベースを維持すること、データベース内のデータに対するアクセスを必要とするジョブを、プロセッサによる同時実行のため受諾すること、及び、ジョブが実行のために受理される順序以外でジョブのうちの少なくともいくつかを各々のプロセッサに実行させることを含んで成る方法に関する。

本発明の実現には、以下の特長が１つ以上含まれていてよい。すなわち記憶されたデータには、オブジェクトデータベース内にオブジェクトを含むデータベースのデータ項目が内含されている。記憶されたデータには、オブジェクト指向アプリケーションに対するオブジェクトとして提供されるデータ項目が含まれているが、あるいは、プロセッサのうちの１つによって実行されるべきジョブのうちの少なくともいくつかは、単一の集約されたジョブによって置換される。置換されるジョブは、結果の正しさを保証するべく同期化グループとしての実行を必要とするものとして予め識別されており、同期化グループの全てのジョブは、それらをグループのメンバーとして識別し１つの定数のうちのそれぞれの分数を定義する情報と結びつけられている。各々のプロセッサは、ジョブによりアクセスされなくてはならないデータのディスク上にある物理的場所に基づきジョブのうち少なくともいくつかを処理するための順序を決定する。処理順序は、ディスク上のデータのページ構造に基づいて決定される。ジョブは、ディスクの一定の与えられた物理的部分に対するアクセスがクラスタ化されるような形で、処理のためにクラスタ化される。プロセッサにより実行されるべきジョブのうちの少なくともいくつかは冗長なものであり、プロセッサは冗長なジョブを実行しない。冗長なジョブは同一であり、同一ジョブの全てよりも少ないジョブが実行される。冗長なジョブのうちのいくつかは、その他の冗長なジョブに取って替わり、取って替わったジョブのみが実行される。冗長なジョブは、結びつけられたタイムスタンプをもち、取って替ったジョブは取って替わられたジョブよりも遅いタイムスタンプを有する。

一般にもう１つの態様においては本発明は、データを持続的に記憶するデータベースを維持すること、タスクソースからタスクを受諾することであって、タスクがそれらの各々を実行のための少なくとも２つの異なる優先性レベルのうちの１つを有するものとして識別する優先性情報と結びつけられていること、各々のタスクについて、タスクを完了するために実行されるべきジョブを定義すること、プロセッサによる同時実行のためジョブを分散させること、及び結びつけられたタスクの優先順に基づく順序で実行するためのジョブを選択すること、を含んで成る方法に関する。

本発明の実現には、以下のような特長のうちの１つ以上のものが含まれていてよい。すなわち、タスクのうちの少なくともいくつかは、データベースの領域の使用のための競合する必要条件を有し、その各々の領域には、一定の与えられた時点で書込みのために全てロックされているか又はロックされていないかのいずれかであるデータが含まれ、各々の領域には、プロセッサの１つが結びつけられている。ジョブは、タスクの新規作成とそのタスクのために定義されたジョブの実行の間の予め定められた平均的な短かい遅延だけを保証するような順序で実行される。１つの優先性をもつジョブは、第２の優先性をもつジョブを予め定められた平均遅延時間以上遅延させないような形で実行されることが保証される。タスクは、実時間での実行のためユーザーにより生成されるより優先性の高いタスク及びソフトウエアプロセスにより生成されるより優先性の低いタスクを内含する。より優先性の低いタスクは、バッチタイプの更新タスクを含む。ジョブは、そのプロセッサに分散され実行を待機している１つのステージングされたジョブセットから各々のプロセッサにより予め定められたサイズの実行セットへと選択される。実行セットが満たされるまでより高い優先性をもつジョブのみが、ステージングされたセットから選択され、実行セットがより高い優先性のジョブにより満たされ得ない場合には、実行セット内に含み入れるためステージングされたセットの中から、低い方の優先性をもつジョブが選択される。

一般に、もう１つの態様においては、本発明は、データを持続的に記憶すること、データの一部の持続的複製を記憶すること及び、データ又は複製が更新されるにつれてデータと複製との間の一貫性を維持することを含んで成る方法に関する。

本発明の実現には、以下の特長のうち１つ以上のものが含まれていてよい。すなわち一貫性は少なくとも２つの異なるプロセッサ上での同時処理によって維持される。異なるプロセッサは同時処理のため共用メモリを使用しない。複製の１つが更新されつつある間、データの関連部分も同時に更新され得る。少なくとも２つの異なるプロセッサにより、複製を同時に更新することができる。各々の複製の中に内含されるデータの項目は、ユーザーにより特定される。各複製の中に内含されるデータの項目は選択される。選択はデータの項目に適用される。選択は、データの項目の要素に適用される。選択は、データ項目及びデータの項目要素に適用される。複製中の全ての項目には同じデータ要素が内含されている。複製中の全ての異なる項目は、異なるデータ要素を有する。選択は、データを探索するために使用されることになるパターンに対応する。選択は、データに適用される少なくとも１つのアルゴリズムに対応する。選択は、異なる複製セットのための異なる規準に基づいている。複製は、記憶装置内で物理的にクラスタ化されている。選択された複製はそれぞれ、物理的にクラスタ化され、セットの中の複製は全て合わせて物理的にクラスタ化されている。要素を自動的に選択するために１つのアルゴリズムが使用される。複製はインデックスと結びつけられる。インデックスはアルゴリズムによって使用されるための複製されたデータを内含する。インデックスは記憶装置内で物理的にクラスタ化されている。データ及び複製はアルゴリズムにより操作され、複製及びデータは、アルゴリズムが、複製のそれぞれの区画上で同時に実行されるサブアルゴリズムへと分解されうるように区画化されている。各々の複製は、サブアルゴリズムの１つにより必要とされるデータのみを含んでいる。各複製のためのデータの選択は、データ項目又は項目要素又はそれらの両方の選択である。複製は、オブジェクト指向アプリケーションに対しオブジェクトとして持続的に提供される。オブジェクト関係ブローカが、オブジェクト指向アプリケーションのためのオブジェクトの持続的記憶を提供する。データは、オブジェクト指向拡張と共に関係データベース内に記憶される。同時処理は、記憶されたデータ及びその複製に関して予め定められた相対的順序で行なわれる。

一般に、もう１つの態様において、本発明は、データベース内で持続的にデータを記憶すること、及び記憶媒体内にデータの項目の少なくとも２つの物理的クラスタを新規作成すること、を含む方法において、クラスタのうちの少なくとも１つは、もう１つのクラスタ内のデータ項目の１つの複製である少なくとも１つのデータ項目を含み、クラスタは２つの異なる規準により組織されている、方法に関する。

本発明の実現には、以下の特長のうちの１つ以上のものが内含されていてよい。すなわち、少なくとも２つの異なるプロセッサ上での同時処理により、データと複製の間の一貫性が維持される。２つの異なるプロセッサは、同時処理のために共有メモリを使用しない。複製が更新されつつある一方で、データの関連部分を同時に更新できる。各複製に内含されるデータの一部分はユーザーにより特定される。複製には１つのインデックスが結びつけられる。インデックスは、記憶装置内で物理的にクラスタ化されている。データ及び複製はアルゴリズムにより操作され、複製及びデータは、アルゴリズムが、複製のそれぞれの区画上で同時に実行されるサブアルゴリズムへと分解されうるように区画化されている。各々の複製は、サブアルゴリズムの１つにより必要とされるデータのみを含んでいる。各複製のためのデータの選択は、データ項目又は項目要素又はそれらの両方の選択である。同時処理は、記憶されたデータ及びその複製に関して予め定められた相対的順序で行なわれる。

一般にもう１つの態様において、本発明は、データを持続的に記憶すること、データの一部分の持続的複製を記憶すること、及び同時に処理され得るサブアルゴリズムの形に、データを使用する１つのアルゴリズムを分割できるようにする区画へと、記憶された複製を区画化すること、を含んで成る方法に関する。

本発明の実現は、以下の特長のうちの１つ以上のものを内含することができる。複製は少なくとも２つの異なるプロセッサにより同時に更新され得る。各々の複製内に内含されるデータの部分が選択される。選択はデータ項目及びデータの項目要素に適用される。選択は、異なる複製されたセットについて異なる規準に基づいている。複製は記憶装置内で物理的にクラスタ化されている。複製は、それぞれに物理的にクラスタ化されている。複製はインデックスと結びつけられる。インデックスはアルゴリズムによって使用されるための複製されたデータを内含する。インデックスは記憶装置内で物理的にクラスタ化されている。各々の複製は、サブアルゴリズムの１つにより必要とされるデータのみを含んでいる。各複製のためのデータの選択は、データ項目又は項目要素又はそれらの両方の選択である。同時処理は、記憶されたデータ及びその複製に関して予め定められた相対的順序で行なわれる。

一般に、もう１つの態様において、本発明は、データを持続的に記憶すること、データベース内のデータに対する参照を内含する少なくとも１つのインデックスを維持すること、記憶されたデータ及びインデックスに対する同時更新を処理すること、及び同時更新中、インデックスと記憶されたデータとの間の一貫性を維持すること、を含んで成る方法に関する。

本発明の実現には、以下の特長のうちの１つ以上のものが含まれていてよい。すなわち、インデックスが更新されつつある一方で、データの関連部分も同時に更新され得る。インデックス及びデータを少なくとも２つの異なるプロセッサにより同時更新することができる。各々のインデックスの中に内含されるデータの部分は、ユーザーにより特定される。インデックスの中に内含されるデータの部分は選択される。選択はデータ項目及びデータの項目要素に適用される。選択は、データを探索するのに使用されることになるアルゴリズムに対応する。インデックスエントリは、記憶装置内で物理的にクラスタ化されている。インデックスはアルゴリズムによる使用のための複製されたデータを内含する。データ及びインデックスはアルゴリズムにより操作され、インデックス及びデータは、アルゴリズムがインデックスのそれぞれの区画上で同時に実行されるサブアルゴリズムへと分解され得るように区画化されている。インデックスは、サブアルゴリズムの１つにより必要とされるデータのみを含んでいる。インデックスのためのデータの選択は、データ項目又は項目要素又はそれらの両方の選択である。同時処理は、記憶されたデータ及びそのインデックスに関して予め定められた相対的順序で行なわれる。

一般に１つの態様においては、本発明は、データを持続的に記憶すること、２つの異なる矛盾しない領域又は２つの異なる物理的クラスタ内にデータの少なくとも２つの異なる項目を記憶すること、２つの異なるデータ項目の間に、プロセスがそのデータ項目のうちのいずれか一方にもう１つのデータ項目から到達できるようにする関係を維持すること、及びいずれか一方又は両方の項目の更新にもかかわらず関係の一貫性を維持すること、を含んで成る方法に関する。

本発明の実現には、以下の特長のうちの１つ以上のものが含まれていてよい。関係の一貫性を維持することには、２つの項目の間の一時的に不完全な状態に関する情報を維持し利用可能にすることが含まれる。状態の不完全性は、２つの項目のうちの少なくとも１つを更新しようとするプロセスに伝達される。データはオブジェクトデータベース内に記憶される。データは、オブジェクト指向アプリケーションからアクセスされる。２つのデータ項目は、２つの異なるクラスタ内に記憶され、関係の一貫性は、２つの項目とそれぞれ結びつけられた関係ロール（役割）を維持することによって保証される。２つより多いデータ項目が存在し、該関係は２進、３進又はＮ進である。２つより多いデータ項目が存在し、該関係は、１対１又は１対多数又は多数対多数である。該関係は双方向である。該関係は、各々１つのデータ項目に結びつけられたロールによって関係を表現することによって維持される。関係は、２つの項目に関して同時処理することによって確立される。関係は、それが新規作成されるべきデータ項目各々について１つずつの１組のロールオブジェクトを新規作成することによって新規作成され、これらのロールオブジェクトは互いに対するポインタを内含する。ロールオブジェクトの新規作成は同期化される。ロールオブジェクトは、それと結びつけられたデータ項目が関係をもつデータ項目についての複製された情報を内含する。ロールオブジェクトは、結びつけられたデータ項目が更新される毎に増分されるバージョン番号を内含する。この方法にはさらに、ロールオブジェクト間で複製されたデータ及びバージョン番号情報を現行のものに保つため、ロールオブジェクト間でメッセージを送ることも含まれている。関係のロールオブジェクトは、それらが関係をもつその他のロールオブジェクトのバージョン番号を記憶する。関係をもつロールオブジェクトは、それらが関係をもつその他のロールオブジェクトのための欠落したバージョンについての情報を記憶する。当該方法は同様に、関係が削除されるとき、その関係内の異なるオブジェクトからの多数の未決定の削除要求にもかかわらずその削除が正しいものであることを保証することをも内含している。

一般に、もう１つの態様においては、本発明は、データ持続性を記憶すること、メモリ内にデータの複製を記憶すること、及びメモリ内の複製及び持続的に記憶されたデータの両方を更新することによって、データを更新する要求に応答すること、を含んで成る方法に関する。

本発明の実現には、以下の特長のうちの１つ以上が内含されていてよい。すなわち、該方法はメモリー内の複製にアクセスすることによってデータにアクセスする要求に応答することをも内含する。複製は、メモリー内の複製が更新された後、しかも対応する持続的に記憶されたデータが更新される前に、メモリー内でアクセスされる。データの１つの要素を更新するための要求には、データのその要素にアクセスする要求に対しサービス提供するものと同じプロセッサがサービス提供する。先行する更新要求は、より優先性の低いタスクとして取扱われ、アクセス要求は、より優先性の高いタスクとして取扱われる。データに対する参照のインデックスがメモリ内に記憶され、これにはデータの複製が内含される。参照インデックスは同じく持続的に記憶される。インデックスを更新するタスクは、持続的に記憶されたインデックス及びメモリ内に記憶されたインデックスの更新をひき起こす。メモリ内に記憶されたインデックスは、持続的に記憶されたインデックスよりも前に更新され得る。インデックスにアクセスする要求は、メモリー内のインデックスが更新された後でかつ、持続的に記憶されたインデックスが更新される前に、メモリーからサービス提供され得る。同じプロセッサは、両方のインデックスの更新を行なう。該方法にはさらに、持続的に記憶されているインデックスからメモリー内に記憶されているインデックスを必要に応じて再構築することも含まれている。データの複製は、アルゴリズムにより使用される。データはアルゴリズムにより操作され、データは、データのそれぞれの区画上で同時に実行されるサブアルゴリズムの形にアルゴリズムが分解され得るように区画化される。データの複製は、サブアルゴリズムの１つが必要とするデータのみを含む。インデックスのためのデータの選択は、データ項目又は項目要素又はその両方の選択である。

図１を参照すると、データ処理センタ１９１は、トランザクションシステム１９２、ビジネスデータユニット（ＢＤＵ）２２及び更新ストリームプロセッサ（ＵＳＰ）２３を内含している。トランザクションシステム１９２は、（インターネットのような）公衆網１９５及びローカルエリアネットワーク（ＬＡＮ）１８１を含むネットワークを介して、例えばコンピュータをもつ顧客１８９又はデータ処理センタ１９１を操作する大規模小売りビジネスのコールセンターオペレータ１９９であり得る潜在的に何百万人ものユーザーによってアクセス可能なものである。ユーザーは例えばそのそれぞれのワークステーションを通して、商品注文又は住所更新であり得る要求を提出する。

トランザクションシステム１９２には、ワークステーションと通信し、ユーザーから要求を受理し、その要求を自動的にタスク又はジョブ命令１９８へと翻訳するアプリケーションプログラム（図示せず）を実行する１つ以上のサーバー１９６が内含されている。例えば要求というのは、ビル(Bill)という名の人物のための青のセーターの購買注文であるかもしれない。要求は予め定義された電子書式であり、ジョブ命令１９８は、ジョブを新規作成するＵＳＰ２３内のプロセスにとって認識可能な形をしたものである。ＵＳＰ２３のためのジョブを新規作成するプロセスはジョブ新規作成プロセス（ＪＣＰ）３５０又はプロジューサと呼ばれる。

ＪＣＰ３５０によって新規作成されたジョブは、ジョブオブジェクトの形をしている。１つのジョブオブジェクトは、ＢＤＵ２２内に記憶された１つ以上のオブジェクトを指すデータ構造を内含する。ジョブオブジェクトは、ＢＤＵオブジェクトに作用するジョブ実行プロセス（ＪＥＰ）によって実行される命令をも包含している。ジョブとジョブオブジェクトの間には１対１の関係が存在することから、以下ではジョブオブジェクトをジョブと呼ぶことにする。

タスクというのは、それがＪＥＰにより実行されるべき命令を包含するオブジェクトであるという点でジョブと同じであるが、それは必ずしもＢＤＵ内に記憶されたオブジェクトを指すわけではない。タスクは必要とあらばジョブを産生することができ、また、タスク及び全ての産生されたジョブが完全であるときアプリケーションプログラムに査定応答を送り戻すことができる。タスクが肯定応答を提供するものである場合には、その肯定応答を伝送するための必要なパラメータ及びメカニズムはタスクオブジェクト内に記録される。タスクは、それが受信されたこと及び実行が保証されていることの肯定応答を提供することもできる。

１つのジョブの実行がもう１つのジョブの実行と矛盾しないことを確認する上で重要な１つのステップとして、トランザクションシステム１９２のアプリケーションプログラムは、ジョブに対して、ジョブ命令１９８内に含まれたコンテンションインデックスとよばれる整数を割当てる。各々のコンテンションインデックスは、例えばデータセット１８０といった共通要素のない予備区画化されたＢＤＵ２２のデータセットを表わしている。予備区画化には、いかなるオブジェクトもＢＤＵ２２に付加されないうちに定義されるアルゴリズムが使用される。アルゴリズムはＢＤＵオブジェクト上でのジョブ実行のために最適なロードバランシングを達成するように設計されている。タスクは、直接ＢＤＵオブジェクトをアクセスしないことから、任意のコンテンションスペースに割当てされ得る。

各々のデータセット１８０内では、ＪＥＰ３００がデータセット内の１つのオブジェクトにアクセスしたときもう１つのプロセスがそのデータセット内のもう１つのオブジェクトにアクセスした場合に矛盾が発生し得るという意味でＢＤＵオブジェクトは互いに関係している。同じコンテンションインデックスのジョブが、同じデータセット１８０内の関連オブジェクトへのアクセスを要求する可能性があり、従ってこれらのジョブではシリアルで実行されなくてはならない；異なるコンテンションインデックスのジョブは、スループットを増大させるべく並行して（同時に）実行することができる。

大型ジョブは、１つ以上のステップに分割することができる。例えば、１つのジョブがＢＤＵ２２内に１００万の記録を包含するバルクファイルをロードすると仮定する。ジョブは１００万個のステップに分割でき、各々のステップは１００万個の記録のうちの１つをロードする。標準的には、１ステップ内には多くの計算はない。従って１つのステップは、全ジョブについての実行時間に比べわずかな時間で実行可能である。ジョブは、障害の後連続的オペレーションを確実に行なうため、全てのステップの後にファイル位置を包含する変数を更新することを含め、充分な状態を維持することを担当する。周期的に、ただしステップの間で、ＪＥＰ３００は、完了したステップの結果を包含するトランザクションをコミットし、新しいトランザクションを開始する。１つのトランザクションは、完了したステップの結果がＢＤＵ２２内にうまく書込まれ記憶された時点でコミットされる。ＪＥＰ３００が現行トランザクションをコミットする時間の間、ファイル位置を内含する実行中のジョブの状態が更新される。障害が発生した場合、ジョブは、回復手順において最後に記録された位置にファイルを置くための充分な情報を有することになる。

既存のジョブが、ＪＥＰ３００により新しいジョブが産生されることを要求する可能性もある。セーターの例における産生されたジョブは、衣服部門の月毎の総所得を更新すること及び青色セーターの在庫を更新することを内含する可能性がある。１つのジョブがＪＥＰ３００によって産生された後、ジョブはＵＳＰ２３内にロードされる。データベースの一貫性を維持するためには、ジョブＪの実行に起因して産生された全てのジョブが同じトランザクション内で、その産生されたジョブが効果を出すようジョブＪが意図しているコンテンションスペース内のステージングセルに対して付加されることになる。ステージングセル及びコンテンションスペースについては後述する。

ＵＳＰ２３は、ジョブの流れを管理して、適切な時点での実行のためＪＥＰ３００に対しそれを誘導する。この流れは、高い全体的システムのスループット及びデータ処理効率を達成し、同時に実行されるジョブが矛盾しないようにするべく管理される。並行プロセスを多数のプロセッサが実行している場合、ＵＳＰ２３は、多数のプロセスにより一定の与えられたデータセット１８０内のオブジェクトに対する同時アクセスを回避しながら、できるかぎり数多くのプロセスを使用状態に保つことを担当する。矛盾のない並行実行を可能にするため、同じデータセット１８０にアクセスするジョブは、ＪＥＰ３００の１つに割当てられた特定のキュー１８４の中に置かれる。通常キューよりも多いデータセットが存在することから、一定の与えられたキュー１８４は、複数のデータセットにアクセスするジョブを包含する可能性がある。１つのジョブが割当てられるキューは、ジョブのコンテンションインデックスから計算される。例えば、Ｎをキューの数として、０〜Ｎ−１までの整数が各キューに割当てられると想定する。コンテンションインデックスＱを伴うジョブが、割当てられた数をもつキューに割当てられることになる（ＱモジュロＮ）。こうして、比較的より小さい数のキューに対し、潜在的に多数のコンテンションインデックスをマッピングすることができる。

各キューは論理的に１つの列として見ることができる。その列内には、同じデータセット１８０にアクセスするジョブすなわち矛盾しうるジョブが存在する可能性がある。潜在的に矛盾するジョブに対し同じコンテンションインデックスを割当てると、それらは、単一のＪＥＰ３００によって実行される一定の与えられたキュー１８４にマッピングされる。このようにして、ジョブは、シリアルに実行されることが保証され、従って、いかなる矛盾も発生し得ない。

一方、ジョブを生成するプロセスの効率を高めるために、ＵＳＰ２３は同様に、各々が図１に全てのキューにわたる縞として例示されている行３０４の形に論理的に組織される。各々の行は、その行が１つのプロセスによってアクセスされていることを表示するためにロックされ得る行制御オブジェクトを有する。プロセスが、１本の行にジョブを付加することを望むとき、書込みロックが要求される。この行は、代替的には、実行のための行内のジョブを取出すことを望む場合にＪＥＰ３００によってロックされた状態で読取られる可能性もある。ロックを用いたジョブの付加及び取出しのオペレーションについて、以下で記述する。充分な行が提供される場合、１つが利用可能な状態となるのを待つことなく、未ロック行を見い出すことが常に可能となる。

ジョブは、生成後一度に１本の行内へとロードされる。ジョブのプロジューサは、未ロック行を発見し、その行をロックし、ジョブをその行内にロードし、次にロックを解除しなければならない。行３０４内で、ジョブは、それぞれのコンテンションインデックスによって決定されたキューの中に置かれる。このようにして、充分な行が存在する限りにおいて全てのプロジューサが、矛盾をひき起こすことなく同時にキュー内にジョブを書き込むことができる。

いくつかの実施においては、ＵＳＰ２３及びＢＤＵ２２は、連合データベースと呼ばれるデータベース組織の一部を成す（Objectivity/ＤＢ Administration、リリース５、１９９８年２月、Objectivity Incorporated）ここで図２を参照すると、連合データベース１０は、一定数のデータベース単位（２つの単位１００及び１１０が示されている）を包含している。各々のデータベース単位は、一定数のコンテナ１２０、１３０及び１４０を有する。連合データベース１０、データベース単位（１００及び１１０）及びコンテナ（１２０、１３０及び１４０）は、オブジェクテビティ社(Objectivity Incorporated)から市販されているObjectivity/ＤＢ（登録商標）と呼ばれる分散型スケーラブルオブジェクトデータベースの基本的構成である。

連合データベース１０は、Objectivity/ＤＢ（登録商標）の論理的記憶階層の中で最高のレベルである。連合データベース１０は、図２では１つのエンティティとして現われているが、ネットワークを介して接続される異なる場所で多重のデータ記憶デバイスを横断して分散されていてもよい。

物理的には、連合データベース１０は、連合データベースファイル（図示せず）として存在する。連合データベース１０は、連合を構成する付加的なデータベース１００、１１０のカタログ１３と同様に、連合データベース１０のためのスキーマ１５を記憶するシステムデータベース１２を包含する。連合データベース１０には、例えばロックサーバープロセス（データベース内のオブジェクトのロッキングを調整するために Objectivity/ＤＢ（登録商標）のクライアントが接続するサービス）といった Objectivity/ＤＢ（登録商標）プロセス（図示せず）に対しそれを識別する一意的整数が割当てられる。

各々のデータベース１００、１１０は、Objectivity/ＤＢ（登録商標）論理記憶階層内で２番目に高いレベルにある。データベース１００が、小売りビジネスのための顧客住所データといったようなユーザーアプリケーションの持続性データを記憶する。データベース１００は、物理的にはデータベースファイル（図示せず）によって表わされる。各々のデータベースは、正確に１つの連合データベースに付加され、その連合データベースのカタログ１３内にリストアップされる。データベースファイル及びそれに付随する連合データベースファイルは、異なる機械の上に存在し得る。物理的ファイル名を有することに加えて、データベース１００は、連合データベース１０のシステムマネージャによって規定されるシステム名をも有する。データベース１００のシステム名は、連合データベース１０内の論理名である。

データベース１００内のコンテナ１２０は、オブジェクトと呼ばれる持続性データの基本単位を保持している（例えば１４５）。コンテナ１２０はオブジェクトの物理的クラスタ化を決定する。コンテナ１２０はロッキングの基本単位でもある。コンテナ１２０内のいずれかのオブジェクトがロックされた時点で、ロックは全コンテナに適用され、コンテナ内の全てのオブジェクトを有効にロックする。

コンテナレベルの細分性は、ロック管理プロセスが、潜在的に何百万又は何十億のオブジェクトレベルのロックではなく比較的少ないコンテナレベルのロックを管理する必要しかないため、全体的性能のためになり得る。図２は、オブジェクトが別々のコンテナ内にクラスタ化されしかもなお互いに参照し合うことができるということを示している（１４８）。

例えば、図１及び図２のデータセット１８０は、一定数のＢＤＵデータベース１００を含むことができ、各々のＢＤＵデータベース１００は何万ものＢＤＵコンテナ１２０を含むことができる。各々のＢＤＵコンテナ１２０は、個人又はビジネス記録を保持するオブジェクト１４５ならびにオブジェクト間のリンク１４８を記憶する。

あるいは、オブジェクト１４５は、ＢＤＵ２２内のオブジェクトを新規作成する、削除する又は修正するといったような書込みオペレーションを実施するジョブを表わすことができる。書込みオペレーションを受理する（すなわちこれによる影響を受ける）ＢＤＵオブジェクトは、オブジェクト１４５と同じコンテンションインデックスを有していなくてはならない。一方、その活動の一部分として読取りオペレーションを実行するジョブを、任意のデータベースから読取ることが可能である。書込みオペレーションと矛盾することなく読取りオペレーションを管理するための機構は、Objectivity ＭＲＯＷ¹（多重読取り装置単一書込み装置）から容易に入手可能である。

図３は、システムデータベース１２、ＢＤＵ２２及びＵＳＰ２３を内含する連合データベース１０の一実施態様を示す。ＵＳＰ２３は、（ｎ＋１）個の論理列と（ｍ＋１）個の論理行をもつ行列として組織される。つねに矛盾を回避するためＵＳＰ２３に必要とされる行及び列の数については後述する。

ＵＳＰ２３の論理列及び対応するＢＤＵ２２のデータセット１８０が１つのデータベース（２０１、２０２、…２０ｎ）を形成し、各々のデータベースがコンテンションスペース（２１１、２１２、…２１ｎ）を表わす。論理列の１つ、すなわち図３中の最も左側の列は、ルートデータベース２４内に記憶されている。ルートデータベース２４を表わすものを除く各々の論理列には、実行セル（ＥＣ）と呼ばれる１つの論理セルとステージングセル（ＳＣ）と呼ばれるｍ個の論理セルが内含されている。

ＵＳＰ２３の論理行３０４は、その行の構成セルに対するアクセスを管理するための論理単位である。図３では、行３０４は、ステージングセルＳＣ₁₂、ＳＣ₂₂…ＳＣ_n2を保持している。

各々の論理セルは、実行セルであれステージングセルであれ、ジョブオブジェクトを保持する１つのコンテナである。ステージングセルは、ＪＣＰ３５０が、新規作成された後のジョブを置く場所であり、また実行セルまで転送するためにＪＥＰ３００がジョブを受理する場所でもある。実行セルは、準備完了状態のジョブ、実行中のジョブそして待機中のジョブを保持する。ステージングセルは、ＪＣＰ３５０からロードされたジョブを保持する。

ルートデータベース２４は、１つのジョブスケジューラ（ＪＳ）コンテナとｍ個の行コンテナ（Ｒ₁、Ｒ₂、…Ｒ_m）を内含する。各々の行コンテナは、その行の構成ステージングセルのリストを保持する行制御オブジェクト２９２を有する。行制御オブジェクト２９２が、その行の１つの書込みロック又は一定数の読取りロックのためのハンドルとして使用される。各々のコンテンションスペースのための構成セルのリストが、そのコンテンションスペースの実行セルコンテナ内に記憶されたコンテンションスペースオブジェクト２９１の中に保たれている。行制御オブジェクト２９２及びコンテンションスペースオブジェクト２９１の全てについての情報は、ＪＳコンテナ内に保持されている。

データベース（例えば２０１）は、それぞれのプロセッサ（例えばプロセッサ３２１）によってアクセス可能であるデータ記憶デバイス（例えばディスク３１１）の中にある。好ましくは、各々の列データベースは別々のディスク上に記憶され、各プロセッサは、単一のＪＥＰ３００のみを実行する。例えば、データベース２０１は、ＪＥＰ３００を実行するプロセッサ３２１によってアクセス可能なディスク３１１上に存在する。この配列は、ネットワーク通信量を低く保ち、ディスクスラッシングを低減させ、こうしてネットワークの待ち時間を改善し、スループットを増大させる。

ルートデータベース２４内のコンテナは読取り又は書込み頻度が少ないことから、ルートデータベース２４の物理的配置は、性能にとって非常に重要なことではない。

１対１のマッピングを用いて、すなわち１列につき１つのＪＥＰの割合でＵＳＰ２３の論理列内のジョブを処理するべくＪＥＰ３００を割当てることが可能である。しかしながら、スケーラビリティ及びロードバランシングを可能にするべくその他のタイプのマッピングを実施することもできる。例えば、多数の列に対して１つのＪＥＰを許容することにより、プロセッサ、プロセス又は列の数に関してＵＳＰ２３のスケーラビリティを増強することができる。多数の列に対して１つのＪＥＰという配置は、プロセッサの数が変わった場合に、ＵＳＰ内の列の数及びプロセッサあたりのＪＥＰの数を同じままにすることができ、そのためＵＳＰ２３により使用されるプロセッサの数をスケーリングするのに必要な努力が少なくてすむという利点をもつ。その上、同じＪＥＰ、同じプロセッサ上で実行中の多数のＪＥＰ又はその両方の組合せに割当てられた多数の列を横断してジョブロードを平衡させることができる。その一方で、１本の列に対して多数のＪＥＰを可能にすることより、ＵＳＰ２３の性能を改善させることができる。１本の列に対して多数のＪＥＰを配置する場合、矛盾を防ぐため実行プロセスとして１つのＪＥＰのみが指定され、その他のＪＥＰは、実行をスピードアップするための補助（例えば予備取出しジョブ）を提供するにすぎない。

全てのコンテンションを避け、ロックされた行上でいかなるプロセスも待機していないようにするためには、Ｃ個のＪＥＰとＰ個のＪＣＰをもつＵＳＰについて少なくともＣ＋Ｐ本の行とＣ本の列が必要とされる。一定の与えられた時点で利用可能なショブを各ＪＥＰが確実に有するようにするためには、Ｃ本の列が必要とされる。中に新しいジョブをロードするために任意の与えられた時点で利用可能な行を全てのＪＣＰ及び全てのＪＥＰが発見できるような形で、Ｃ＋Ｐ本の行が必要とされる。ＪＳコンテナ、行コンテナ及び列コンテナを考慮に入れると、コンテンションを回避しロック上の待機をなくするために必要とされる合計コンテナ数は(Ｃ＋Ｐ＋１)(Ｃ＋１)である。新しいジョブをロードするためにいかなるプロセスもロック上で待機する必要がないことから、新しいジョブは、それらが生成又は産生されると直ちにＵＳＰ２３によって受入れられる。

ＵＳＰ２３は、Visual Works Smalltalk、Java又はＣ++を含む一定数のコンピュータ言語で実施できる。実施例には、各機械が物理的ディスク及びプロセッサを有している状態で、複数の機械を接続する中速度のネットワークが必要とされる。各機械のディスクは、その機械のプロセッサにとってアクセス可能なものであるＵＳＰ２３の列を保持している。

ＵＳＰ２３のオペレーションにおいて、ＪＥＰ３００は、ＵＳＰ２３内でジョブを実行し次に削除する消費者プロセスを表わす。周期的にか又はＪＥＰの実行セルがすぐに実行できるジョブを全くもたなくなった時点のいずれかで、ＪＥＰ３００は、行のランダム順列からラウンドロビンスキームを用いて行を走査する。選択された行をロックできない場合、行のうちの１つの上で読取りロックが獲得されるまで順列により選択された次の行が試みられる。読取りロックが獲得された後、ＪＥＰ３００は、指定されたコンテンションスペース内でロックされた行に位置づけされたステージングセル内の全てのジョブを取出し、ジョブを実行セルにコピーし、そのステージングセルからそのジョブを削除する。次にＪＥＰ３００は、読取りロックを解除し、一度に１つのジョブを実行し始める。同じトランザクション内で１つのジョブを実行した後、ＪＥＰ３００は実行セルからジョブを削除する。

ジョブ実行中に、ＪＥＰ３００は、そのジョブが、何らかの新しいジョブの産生を必要とするか否かを見極めるためジョブと共に運ばれる情報を使用する。ＪＥＰ３００によって産生された新しいジョブがある場合、それらは、書込みロックと共にＪＥＰが獲得した行のステージングセル内に記憶される。ステージングセルは、新しいジョブのコンテンションインデックスによって特定されたコンテンションスペース内に位置づけされている。

１つの行制御オブジェクト（例えば２９２）は各々の読取りロックが別々のコンテンションスペース内で異なる消費者により獲得される限りにおいて、同時に多数の消費者により獲得される多数の読取りロックを有する可能性がある。しかしながら、行制御オブジェクト２９２は、一度に１つの書込みロックしか許容せず、これは省略時 Objectivity/ＤＢ（登録商標）を通して達成される。１本の行上の書込みロックは、同時の読取り及び書込みがデータの非一貫性を作り出す可能性があるために、同一の行上に読取りロックを得ようとする試みをすべて排除する。同様にして、１本の行上の１つ以上の読取りロックの存在は、同じ行上の書込みロックの獲得を妨げる。

ＪＥＰ３００は、１つのトランザクションをコミットするとき、キャッシュメモリー又はディスクのような持続性メモリに対し、ジョブ実行の結果を書き戻す。ジョブ実行のトランザクションは、実行されたステップの数又は実行時間の長さといったような、予め定められた規準に基づいて定義される。予め定められた規準を満たす場合、例えば、トランザクションの開始から１０秒が経過したか又は１つ以上のジョブの５００のステップが実行された時点で、ＪＥＰ３００は１つのトランザクションをコミットする。トランザクションは、ジョブが短かい場合、多数のジョブの実行を内含することができる。例えば、１つのトランザクションは、１つのジョブの後半部分、完全な１０個のジョブ、及びもう１つのジョブの前半部分を内含しているかもしれない。

消費者プロセスのオペレーションには一般に以下のものが含まれる。
１．ＪＥＰ３００が実行セルから１つのジョブを選択しそれに＃start：メッセージを送ることから始める。ジョブは、１つのオブジェクトである第１の記憶をＪＥＰ３００に戻すことにより応答する。第１の記憶は、その後ジョブへと戻されることになる。第１の記憶は過渡的であり（すなわち、ＲＡＭ内にのみ保持され、連合データベース内のどこにも記憶されない）、ＪＥＰ３００は自動的にそれを追跡することを続ける。
２．周期的に、ＪＥＰ３００は、＃atEnd：メッセージを送り現行記憶をジョブに戻すことによりそれが終わったか否かをジョブに問い合わせる。ジョブが「真」のインジケータを戻した場合、以下で説明するように終了メッセージが送られる。
３．ジョブが「真」のインジケータを戻さない場合、ＪＥＰ３００はジョブに＃step:withScheduler：メッセージを送り、ジョブに現行の記憶及びＪＳコンテナ内に記憶された情報を渡す。ジョブは、第２の記憶（第１の記憶と同じオブジェクトである可能性もある）を戻す。ＪＳコンテナ内に記憶された情報といったような管理情報もジョブに対し渡される。この情報は、ジョブがより多くのジョブの産生を必要とする場合に使用される。
４．次にＪＥＰ３００は、例えば、最後のトランザクションがコミットされてから１０秒が経過したか否かに応じて、ショブのトランザクションをコミットすべきか否かを決定する。その後、ＪＥＰ３００はそれが終わったか否かをジョブに再び問い合わせる。
５．ショブがひとたび「真」インジケータを戻した時点で、ＪＥＰ３００はジョブに＃finish：メッセージを送り、ジョブに現行の記憶を渡す。次にＪＥＰ３００は、ジョブを削除する。
６．ＪＥＰ３００は、実行セル内の次のジョブに着手する。実行セル内でいかなるジョブも実行できる状態にない場合、ＪＥＰ３００は新しいジョブのためその列内の行を走査する。

ジョブの実行は、ＪＥＰの障害によって中断され得、ジョブは部分的にしか実行されなくなる。しかしながら、コンテンションスペースオブジェクト２９１は、トランザクションがコミットされる毎にその実行セルコンテナ内の現行の実行ジョブの状態を記憶することから、ジョブの状態は、少なくとも最近コミットされたトランザクションの時点まで回復され得る。

回復手順は、障害あるものと交換するため新しいＪＥＰを開始させること、そして次に部分的に実行されたジョブに再開するよう知らせることを内含する。回復手順は、外部状態が存在する場合、それをジョブがリセットすることを可能にする。回復手順は一般に以下の通りである：１．ジョブに、＃restart：メッセージを送る。ジョブは、そのジョブの実行を続行する上で使用するべく、新しいＪＥＰのための記憶を戻す。
２．前節で記述したようなジョブ実行手順のステップ２で続行する。

ジョブをＵＳＰ２３に付加するため、ジョブ生成プロセスは、書込みロックが１つの行上で首尾よく獲得されるまで、行のランダム順列からラウンドロビンスキームを用いて行を走査する。ジョブ生成プロセスは、ＪＣＰ３５０であっても、新しいジョブを産生していくＪＥＰ３００であってもよい。ジョブ生成プロセスは、そのジョブ及び同時にロードされているその他のジョブがその行内のステージングセル内に置かれる間、ジョブ生成トランザクションが終るまで、書込みロックを保持する。ジョブ生成トランザクションは、ジョブ消費者のトランザクションと同様に定義づけされ得る。トランザクションが完了した後、ジョブ生成プロセスは書込みロックを解除し、ジョブは、行上の読取りロックを用いてそれぞれのＪＥＰ３００による実行のため選択され得る。このようにして、ＵＳＰ２３内にジョブを付加するオペレーションには一般に以下のものが含まれる。
１．その行の行制御オブジェクト２９２上にある書込みロックを獲得することにより、１本の行上の書込みロックを獲得する。
２．ジョブのコンテンションインデックスに従って、ロックされた行の適切なセルにジョブを付加する。
３．書込みロックを解除する。

「SampleUSP」という名前でＵＳＰを新規作成するためには、以下の手順を用いることができる。

外１

手順は、「UpdateStreamProcessor SampleUSP root」、「UpdateStreamProcessor SampleUSP contention space1」、...「UpdateStreamProcessor SampleUSPcontention space10」という名前の１１のデータベースを新規作成する。ルートデータベースは、１つのＪＳコンテナと、１０＋４＝１４の行の各々について１つずつの行コンテナを有する。その他の１０個のデータベースの各々は、好ましくは、そのコンテンションスペースを処理するべく割当てられたプロセッサ又はその近くにあるディスク上に記憶されたコンテンションスペースを表わす。

以下の例は、SampleUSPと名付けられたＵＳＰの位置を特定しＵＳＰに対するハンドルを受けとるためのアプリケーションプログラムの命令を示す。例えばアプリケーションプログラムは、図１でトランザクションシステム１９２内に記憶されたものであってよい。

外２

以上の機能は、１つのトランザクション内で呼出しされなくてはならない。ひとたびハンドルが受理された時点で、アプリケーションプログラムはさらに、新しいジョブをスケジュールし既存のジョブを実行するためＵＳＰのプロセスを命令することができる。

以下の命令は、行をロックしその行の中に１つのジョブを書込むためＪＣＰ３５０をトリガーする。

外３

currentOutputRowは、未ロック行を発見する１つの機能であり、この機能は、ジョブ生成トランザクション内で呼出される。新しいトランザクション内のCurrentOutputRowに対する第１の要求のみがＪＣＰ３５０にもう１つの未ロック行を発見させる。反復的要求は、ＪＣＰ３５０に同じ行を戻させることになる。

時として、ジョブは、結果の正しさを確保するべく予め定められた順序で実行されなくてはならない。ジョブ実行の予め定められた順序を強化する方法は、同期化と呼ばれる。市販のデータベースシステムでは、例えば、人物の間に関係があるかもしれず、これらの人物と付随するオブジェクトは互いに属性を介して参照し合うことができる。１つの記録をもう１つの記録又は人物に関係づける属性、関係及びリンクを更新する場合、ジョブ実行の適正な順序が求められる。そうでなければ、データベースシステムの無欠性は破壊され、データの一貫性は失なわれる可能性がある。

１つのジョブは、共に同期化のために使用される定数分数及びタグを有する。同期化に参加する１つのジョブは、同じ同期化に参加するその他のジョブの全てが実行セル内に到着した時点で初めて実行され得る。同じ同期化に参加するジョブは、そのジョブのタグによって識別される同期グループを形成する。ジョブのタグがニル（無）である場合、それは、そのジョブがいかなる同期化にも参加しないことを意味する。ジョブのタグがニルでない場合、それは、同じタグをもつその他のジョブと共にまとめられる。

１つのジョブの定数分数は、同期化における定足数の割合を表わす。例えば、５つのジョブが同期化される必要がある場合、各々のジョブには定数分数値１/５に割当てられる。実行セル内の同じタグをもつジョブの合計分数が１に達した時点で、これらのジョブは過渡的メモリー内のスモールトーク辞書から実行セル内に記憶された実行準備完了リストまで、大量に移動させられる。辞書は、実行セル内で待機するジョブのリストを保持している。同期グループのジョブを容易に識別できるように、待機中のジョブはそのそれぞれのタグによってインデクシングされる。待機中のジョブは、そのそれぞれの同期グループ内のいくつかのジョブが実行セル内に到着していない場合、まだ準備完了とはならない。

ゼロの定数分数をもつジョブは無効である。同期化される必要のあるジョブグループの合計定数分数が１より大きい場合、エラーが起こる。

同期グループのジョブは、同じコンテンションスペース内で実行されなくてはならない。ある一定の順序で、異なるコンテンションスペース内のジョブが実行される必要がある場合には、一定の与えられたコンテンションスペース内の定数分数を１までパッドするためトークンジョブを生成することができる。例えば、ジョブ１が、全て異なるコンテンションスペース内にあるジョブ２及び３を新規作成すると想定する。さらに、ジョブ３はジョブ２が完了した後にのみ実行されなければならないと想定してみよう。ジョブ３が新規作成された時点で、それには１/２という定数分数と、生成された一意的タグが与えられる。ジョブ２が新規作成された時、それは全くタグをもたないが、ジョブ３のタグが何であるかはわかっている。ジョブ２が実行するとき、それが最後に行なうのは、ジョブ３と同じタグと１/２の定数分数をもつトークンジョブ３ａを新規作成することである。ジョブ３及び３ａが両方共到着した時点で初めて、それらは実行できる。ここでジョブ３ａは、１という定数分数を達成しジョブ３が実行できるようにするトリガーとして作用すること以外何も行なわない可能性がある、ということに留意されたい。

もう１つの例として、その他のジョブを生成する数多くのステップを伴う非常に長い実行中のジョブを考えてみる。例えば、主要ジョブが完了してしまうまでは、これらの産生されたジョブのいずれも実行してほしくないと我々が考えているとしよう。トランザクションは、主要ジョブのステップ間で何度もコミットされ得、こうして、産生されたジョブはその標的コンテンションスペースまで伝達され得るようになることから、我々は同期化を使用しなければならない。我々は各々の産生されたジョブに可能な限り最小の定数分数（２^-32）を与え、どれほどのジョブが各々のコンテンションスペースに行ったかを記録することができる。主要ジョブの最後のステップで、我々は、我々がそのコンテンションスペースに送ったジョブの定数分数の合計を１から引いたものである定数分数を用いて、我々がいずれかのジョブを送った各々のコンテンションスペースに対しダミートリガージョブを送ることができる。こうして、これらのトリガージョブが送られた時点（これは主要ジョブが完了した時点でしか起こらない）でのみ、以前に産生されたジョブは実行を開始することができる。

１つのジョブが支持するタグは、同期グループの一部としてそのジョブを識別する一意的整数である。ＪＥＰ３００は、タグ整数を同期グループにマッピングするためにＲＡＭ内のアソシエイティブ構造を使用する。ＪＥＰ３００は、定足数を決定するために同じタグをもつジョブを一緒にまとめる。ジョブは、それらが実行されるまで制限された時間だけデータベース内に存在するにすぎないことから、ＵＳＰ２３内の任意の既存の同期グループについて一意的な１つの整数を生成する目的で、通常は１つの巡回６４ビット計数器で充分である。計数器上のコンテンションを避けるため、各々のコンテンションスペースオブジェクト２９１は、対応するＪＥＰ３００によって産生されるジョブのためにその独自の６４ビット計数器を維持する。各々の行制御オブジェクト２９２は、ＪＣＰ３５０によって新規作成されたタグ付きジョブを構築するための計数器も保持している。タグの一意性を確保するためにジョブを保持するコンテナの列数又は行数を、取込むことが可能である。産生されたジョブのタグのための整数を生成するための１つの実施では、Ｎ本の列をもつＵＳＰの列の各々に対し０からＮ−１までの数字が割り当てられる。ジョブのタグ整数は、計数器の値をＮで乗じ次にジョブを保持するコンテナの割当てられた列番号を加えることによって生成できる。ＪＣＰ３５０により新規作成されるジョブについてタグを生成するためにも類似のアプローチを使用することができる。行制御オブジェクト２９１及びコンテンションスペースオブジェクト２９２から生成された同期グループを区別するには、正負符号のついた整数を使用してもよい。

タグを作成する必要がある場合、ＪＣＰ３５０又はＪＥＰ３００は、行制御オブジェクト２９２又はコンテンションスペースオブジェクト２９１に対しそれぞれメッセージ＃nextUniqueInteger を送る。タグが生成されている時間の間、この計数器上でのコンテンションを防ぐため行制御オブジェクト２９２又はコンテンションスペースオブジェクト２９１上の同じトランザクション内で書込みロックが獲得される（そして標準的にはすでに先行する要求により獲得されている）。

タグを生成するために行制御オブジェクト２９２に送られる命令は、以下の通りである。

外４

タグを生成するためにコンテンションスペースオブジェクト２９１に送られる命令は、以下の通りである。

外５

定数分数とタグを使用して、ジョブ実行の正しい順序が保証される。例えば、コンテンションスペース＃１内のジョブＪ１がジョブＪ２及びＪ３を新規作成すると想定する。これらのジョブは、異なるコンテンションスペース（例えば、それぞれコンテンションスペース＃２及び＃３）内で実行する。Ｊ２が終了した時点で、それはジョブＪ４を新規作成する。同様に、Ｊ３はＪ５を新規作成する。Ｊ４及びＪ５は、Ｊ１が実行したコンテンションスペースに割当てられる。Ｊ４及びＪ５は互いに同じタグ整数をもち、各々が１/２という定数分数を有する。こうして、Ｊ４がまず最初にコンテンションスペース＃１内に到着したならば、それはＪ５も到着するまで実行され得ない。同様に、Ｊ５が最初に到着したとしても、それは、Ｊ４が到着するのを待って実行しなければならない。

Ｊ４及びＪ５は同じタグを有していなければならないが、そのタグは包括的に一意的でなければならない。従って一意的整数を（例えば次の一意的整数について現行の出力行にたずねることによって）割当てるのはＪ１の責任である。Ｊ１はＪ２及びＪ３に、この整数が何であるかを告げる（ここで、Ｊ２及びＪ３は同期化される必要がないため独自のタグを全くもたないということに留意されたい）。Ｊ２がＪ４を新規作成した時点で、それはＪ４のタグをこの整数にセットする。同様に、Ｊ３はＪ５のタグをこの同じ整数にセットする。Ｊ２及びＪ３は、Ｊ２及びＪ３が含む残りのデータから明らかでない場合にＪ４及びＪ５をどのコンテンションスペースに送るべきかについての情報を包含していなけれはならないかもしれない。

一対の同期ジョブを新規作成するべくＪＣＰ３５０をアプリケーションプログラムがトリガーするためのコード例が、以下に示されている。このコード中、ジョブ１及びジョブ２には同じコンテンションインデックス、同じタグそして合計１となる異なる定数分数が割当てられている。両方のジョブ共、そのいずれかが実行され得る前に、割当てられたコンテンションスペースの実行セル内に到着しなければならない。

外６

同期ジョブグループが指定された実行セル内に到着した後、ＪＥＰ３００が、ジョブグループを実行する前に、ジョブ折畳み手順が起こるかもしれない。このジョブ折畳み手順は多数のジョブを単一のジョブへと減少させ、こうして冗長なジョブを除去し、反復されたジョブを単純化させる。同期ジョブグループがいつでも実行できる状態になった時点で、ＪＥＰ３００は順番にこれらのジョブの各々に対し＃collapseJobs：メッセージを送り、ジョブコレクションを引き数として渡す。ジョブの１つがニルの代りに１つのジョブで応答した場合、このジョブが、全グループの代わりに使用されることになる。このジョブは標準的に、オリジナルのジョブグループ内で発見される全ての情報を包含する。新しいジョブの実行結果は、同期グループ内の全てのジョブの組合せ結果と等価である。例えば、Ｎ回の「計数器を１だけ増分する」というオペレーションは「計数器をＮだけ増加する」へと折畳みされ得る。

同期ジョブグループ及びジョブ折畳みの使用例について以下で記述する。ＵＳＰ２３は、一定の与えられた記録とＢＤＵ２２内に記憶された記録との間に整合が存在するか否かを見極めるために、ＢＤＵ２２内の全ての記録を処理するロードジョブを実行することができる。例えば、一定の与えられた記録は、顧客ジョン(John)の新しい住所を含む新しい記録であり得る。ロードジョブは、一定数の整合ジョブを産生し、整合ジョブの各々は、一定の与えられた記録と記憶された記録との間で、誕生日、氏名、社会保険番号といったような特定の整合属性又は属性の組合せを比較する。

整合ジョブは、どの記録をそれが表わしているか、ならびに記録のためにどれほどの整合ジョブが作り出されたかを知っている。整合ジョブは、一定の与えられた記録と整合する対応する記憶された記録を見い出した時点で、各々がこれらの記録のうちの１つを保持する複数のジョブを新規作成し、整合を開始したコンテンションスペースまでそれらを戻す。各々の新しいジョブは、Ｍを整合ジョブの数としＲをこの整合ジョブが発見した記録の数として、１／（Ｍ*Ｒ）である定数分数を有する。ここで、任意の整合ジョブからの応答の定数分数の合計が１/Ｍに等しいという点に留意されたい。いかなる整合記録も発見されなかった場合、定数分数１/Ｍで、これを表示するため特殊なダミージョブが送られなくてはならない。

顧客ジョンの例においては、整合ジョブは記憶されたジョンの記録の全てに言及する応答ジョブを生成した。これらの応答ジョブの全てがオリジナルのコンテンションスペースに戻った時点でのみ、これらを処理することが可能である。これは正確には、定数分数の合計が１に等しくなるときである。この時点で、整合応答ジョブを、整合する記録の完全なリストをもつ単一ジョブへと折畳むことができる。このデータは、必要に応じて分析及び併合でき、次に、変更された住所を収容するために修飾される必要のある各々の記録に対して更新ジョブを送ることができる。

タスクは、タスクの実行の結果として産生された全てのジョブが完了した後、肯定応答を送ることができるようにするためジョブの同期化を使用する。産生されたジョブは全て、そのタスクのコンテンションスペース；一意的タグ及び、一定の与えられたジョブによりその他のジョブの中に含まれたその他の分数の全てに対して付加された時点で合計で産生ジョブの分数となるような分数を支持している。タスクによって産生されたジョブの場合、それらの分数は合計で１となる。これらの分数を生成する迅速な方法は、産生されつつあるジョブの数で１を除したものをとり、これに産生ジョブの分数を乗じ、タスクの分数が１となると仮定されている産生されたジョブの各々の中で、結果として得た分数を使用することである。このスキームは、最終的ジョブ（肯定応答以外の作業を行なうのに何らかのさらなるジョブを産生する必要のないジョブ）を横断した全ての分数の和が合計で１となるようにする。最終的ジョブは、記録されたコンテンションスペース、タグ及び定数分数としての分数を伴う肯定応答ジョブを産生する。全ての肯定応答ジョブがそのタスクのコンテンションスペースに到達した時点で、これらは折畳みされ実行され、アプリケーションプログラムに対し肯定応答を送らせる。

その他の実施が、請求項の範囲内に入るものである。

例えば、別々の実行セルを使用する代りに、同期実行を必要としないジョブをステージングセルから直接実行することが可能である。しかしながら、同期化されたジョブは、その全てが同期グループとして実行され共に削除され得るような形で、なおも実行のために実行セルまで移動されなくてはならなくなる。

ステージングセルから直接のジョブ実行を容易にするため、各々のステージングセルは実行されるべく待機しているステージングセル内のジョブの数を表示する計数器を有している。計数器は、計数器の値が２³²−１に達した時点で０まで循環する３２ビットの計数器であり得る。ＪＣＰ３５０がステージングセル内に新しいジョブを付加した時点で、ステージングセル内の計数器は増分される。ジョブの付加及び計数器の更新の両方が、同じトランザクション内で行なわれる。

各々の実行セルは、それぞれのステージングセルのための完了したジョブの数を表示する類似の３２ビットの計数器も有する。ＪＥＰ３００が１つのジョブ実行を完了した時点で、実行セル内の付随する計数器は、ＭＲＯＷ書込みで増分される。ＭＲＯＷセマンティクスにより、計数器は単一の書込み装置及び多数の読取り装置によって同時にアクセスされ得ることになる。ＪＣＰ３５０は、周期的に、ＭＲＯＷ読取りで実行セル内の計数器を検査する。計数器の値は、それぞれのステージングセル内でいくつのジョブを削除できるかを見極めるために、ＪＣＰ３５０によって使用される。

ＪＥＰ３００が新しいジョブの実行が必要となった時点で、ＪＥＰは、計数器がその最大値に達した時点で計数器はゼロまでラップできるということを考慮に入れて、計数器値が実行セルの計数器の値よりも大きいステージングセル内の全てのジョブを読みとる。（計数値−もう１つの値）モジュロ最大サイズ＜（最大サイズ／２）である場合、計数器の値はもう１つの値よりも大きいものとみなされる。例えば、２つの４ビット計数器の値を比較する場合に、計数器の値は９であり、もう１つの値は７であると想定する。９−７＝２、２モジュロ１６＝２であり、２は（１６/８）より小さいことから、９は７よりも大きい。この減算もラップする。すなわち例えば（０−１）が計数器の最大値に等しい。ＪＥＰ３００のための作業負荷は、ＪＥＰがステージングセルを修正する必要が決してないことから減少する。

ある種の実施態様においては、ＵＳＰは図１及び図３に示されている行列構造を持ちさえしない。その代り、ＵＳＰはジョブデータベース及びＴＣＰ/ＩＰソケットを介して通信するそのそれぞれのプロセスを含む。この実施態様においては、行の概念が存在しないことから、ロッキングオペレーションはもはや必要とされない。図３Ａを参照すると、ＵＳＰ２７には、ＪＥＰとＪＣＰが内含されており、その各々は、プロセスを実行する同じプロセッサのメモリー内にあるジョブリスト（２５）を有する。ＪＣＰのジョブデータベース２６は、ＪＥＰに送られるジョブのバックアップコピーを記憶する。ＪＥＰのジョブリスト２５は、実行されるべく待機しているジョブを追跡する。ＪＣＰが１つのジョブを新規作成した時点で、ジョブのコピーがバックアップとしてＪＣＰのジョブデータベース２６内にロードされる。ＪＣＰは、ジョブのコンテンションインデックスによってそのコンテンションスペースが特定されている適切なＪＥＰまでＴＣＰ/ＩＰソケットを介してジョブを伝送する。ＪＥＰはジョブを受理した後、一時的にそのジョブを、実行待機中のそのジョブリスト２５に付加する。

ＴＣＰ/ＩＰソケットというのは、アプリケーションプログラムがＴＣＰ/ＩＰメッセージをネットワーク上で送受信することができるようにするソフトウェアエンティティである。ＴＣＰ/ＩＰソケットを使用すると、ジョブをＴＣＰ／ＩＰメッセージとして送受信でき、こうしてシステムのプログラマからネットワークのディテールが隠される。
各々のＪＣＰは、各ＪＥＰへのソケット接続を有しており、それを通して、そのＪＥＰによって実行されなくてはならないジョブを伝送することができる。特定のＪＥＰを目的として特定のＪＣＰからのジョブは全て同じソケット接続を通して伝送され、連続的ジョブのＩＤ番号、モジュロ２³²が割当てられる。

ＵＳＰ２７は、Objectivity/ＤＢ（登録商標）によって実施される「自律区画化」の概念を利用する。自律区画化は、基本的に、連合データベースのデータベースサブセットである。各データベースは、正確に１つの自律区画に属する。ＵＳＰのこの変形態様においては、各々のプロセスはその独自の区画内で動作できる。データベース書込みは、その付随する実行プロセスによって制御されるデータベースに局所的なものとして制約され得、こうして、ネットワーク通信量は大幅に低減され、プロセッサが回復されるまであらゆるプロセッサの故障が安全に隔離されることになる。ネットワーク通信量の減少の結果、自律区画は同様に、遠隔した地理的サイトに広がる広域ネットワーク（ＷＡＮ）上での展開の望ましくない効果も低減される。この望ましくない効果としては、ローカルエリアネットワーク（ＬＡＮ）と比べてデータ伝送コストが高いこと及び通信リンクの予想故障率が高いことが含まれる。ネットワーク通信量が低減されることから、自律区画はＷＡＮ上の展開のためのコストを低下させるのみならず、伝送の信頼性に対する要求も少なくする。

ＪＣＰとＪＥＰとの間のＴＣＰ/ＩＰソケット接続は、「データグラム」ではなくむしろ「ストリーム」種のものである。「ストリーム」種のための根底にあるネットワークプロトコルは、必要に応じて誤り訂正及び再伝送を内含するメッセージの送達を確保している。個々のＩＰパケットは、ゼロ以上の回数、任意の順序で物理的ネットワークアダプタに到着し、任意に折畳みされる。「ストリーム」ソケット実施は、これらのパケットを正しく順序づけし直し、誤伝送されたパケットの再伝送を要求し、冗長なパケットを放棄することを担当する。パケットの伝送が適正な時間又は努力（標準的には数秒）の量内で達成されず肯定応答され得ない場合、プロトコルは単純に、クライアント（すなわちＪＣＰ及びＪＥＰ）に対しそのソケットが接続解除されたことを通知することになる。ソケットが接続解除された場合、クライアントは周期的に、接続解除されたソケットを再接続することを試みることになる。ＪＥＰは、再接続を試みる一方で、接続されたソケットから到着するジョブを処理し続けることになる。こうして、ジョブ処理は、故障したノード又はネットワークリンクからの回復中でさえ続行される。

標準的なネットワーク上のパケットサイズは、長さが数キロバイトのものである。固定サイズのパケットについては、パケットを伝送するオーバーヘッドが固定される。ジョブのサイズは通常、パケットのサイズよりも短かいことから、単一のパケットとして各ジョブを伝送するのは効率の悪いことであろう。従って、伝送の前に、ジョブは、そのサイズがパケットサイズに等しいバッファの中に書き込まれる。伝送プロセスは可能なかぎり多くのジョブを各バッファ内にパックし、無駄になるネットワーク通信量を低減するべく１つのパケット内で全バッファを伝送させる。

場合によっては、ほぼ空のパケットをなおも伝送する必要がある。そうでなければ、ＵＳＰが静止状態となった場合に、最終のジョブが決して伝送されない可能性がある。このようにして、我々は、パケット内で送られる前にどれほど長くデータがバッファ内にとどまり得るのかについての限界をセットする。例えば、最初のジョブがバッファ内に書込まれてから１０秒以上が経過した場合、バッファはソケットに対しフラッシュされ、パケットを強制的に物理的に送らせる。一方、それをバッファ内の最後のジョブとの関係においてタイミングした場合、９秒毎に到着するとぎれがちなジョブは、その一部が長時間伝送されるのを待っていたという事実にも関わらず、バッファが数分間伝送されないように保つ可能性がある。より少ない待ち時間を必要とする環境内でＵＳＰが使用される場合には、時間的限界を低減させることができる。

故障が発生した場合でさえジョブが確実に実行されるようにするため、コミットされたジョブは常に、ソケットを介してＪＥＰに伝送される前にＪＣＰのジョブデータベース２６に書き込まれる。ジョブがＪＥＰによって受信された時点で、我々は、ジョブがすでにＪＣＰのデータベースにコミットされたことがわかる。故障の場合、ＪＣＰはそのジョブデータベース２６を走査し、まだ実行されていない可能性のあるジョブを各ＪＥＰに再伝送することになる。ＪＥＰは、ジョブがすでに受信され実行されたことを表わすＩＤをもつジョブを単純に無視する。

ＪＣＰのジョブデータベースが勝手に大きくならないようにするため、各ＪＥＰは、１つのトランザクションをコミットする毎にＪＣＰ１つあたり１つの番号という割合で最近完了したジョブのＩＤ番号を記録する責任を負う。これらのジョブＩＤ番号は、ＲＡＭ計数器によって計数され、回復中に、どのジョブがすでに実行され無視できるかを告げるのに用いられる。ＪＥＰはまた、各々のＪＣＰに対して、そのＪＣＰについてのＲＡＭ計数器値を含む削除メッセージを周期的に伝送する。ＪＣＰは、削除メッセージを受信した時点で、ラップ演算を用いて自由にメッセージ内のＩＤ以下のＩＤですべてのジョブを削除することができる（すなわち、そのＩＤがメッセージ内のＩＤに等しいか、そのメッセージ内のＩＤより下２³¹以内にあるか又はメッセージ内のＩＤより２³¹より大きい全てのジョブを削除することができる）。

ジョブ削除メッセージは、実行されなかったジョブのＩＤを支持することができない。ジョブが同期化されていない場合、ジョブは完全に実行されコミットされてしまわなくてはならない。ジョブが同期化されたジョブである場合、ＪＥＰ内の情報の複製が必要とされる。同期化されたジョブのＩＤと共にジョブ削除メッセージを伝送するに先立ち、ＪＥＰはジョブデータベース２５内にジョブのコピーを記憶しそれをコミットする。同期ジョブのコピーを記憶することは、故障の際の回復にとって必要である。そうでなければ、ジョブの持続的記録は全くなくなる。ジョブ同期化においてすでに記述したＲＡＭ内のアソシエティブ構造は、削除メッセージ内で伝送されたＩＤをもつ同期ジョブを含め、そのタグを伴う同期グループ内のジョブリストに対する各同期化タグからのマッピングの記録を行なう。回復時点でアソシエティブ構造はジョブデータベース２５内のジョブから再構築される。

グループの合計定数分数が１に達した時点でそのグループには、単一ジョブへと折畳みする機会が与えられる。折畳みが発生した場合、そのグループのジョブはデータベース及びアソシエティブ構造から削除され、単一の置換ジョブが単一のトランザクション内のグループの代りに記憶される。単一のジョブは、定数分数が１である単一のメンバーをもつ同期グループとして扱われる。

同期グループが複数のオリジナルジョブから成るか又は折畳みにより新規作成された１つの単一ジョブから成るかに関わらず、グループがいつでも実行できる状態となった時点で、グループのタグは記録され、ジョブの実行が始まる。グループ内の１つのジョブが完了した時点でそのジョブはＪＥＰのジョブのデータベース２５から削除され、グループ内の次のジョブが開始される。グループの実行の途中でトランザクションをコミットすること（例えばトランザクションの持続時間を制限するため）が必要となった場合には、ＪＥＰは、グループのタグならびに実行中のジョブに対するポインタを記録することになる。コミットの間にクラッシュが発生した場合、グループの残りのジョブは、その他のあらゆるジョブの前に実行されることになる。グループの全てのジョブが完了した後、任意のソケット接続を介した次の入ジョブが処理される。

各々のＪＣＰ／ＪＥＰ対は、その伝達されたジョブのための連続するＩＤ番号を使用すること、かつ、削除がジョブの伝送と同じ順序で起こることから、ＪＥＰは、各メッセージが１ブロックのジョブの削除を要求している複数の削除メッセージの一部分のみを安全に伝送することができる。ＪＣＰは、ジョブ削除メッセージを受信した時点で、伝送されたＩＤ以下のＩＤをもつ全てのジョブを（上述のようなラップ演算を用いて）削除する。ジョブ削除メッセージの数を低減させるためには、ＪＥＰは、削除メッセージのＩＤが予め定められた数の倍数（例えば１０００）と交差する場合又は削除が予め定められたもの以上の長さの時間（例えば１０秒）だけ前に起こりその時間内にＪＣＰから（又はいずれかのＪＣＰから）いかなる新しいジョブも到着しなかった場合のいずれかの場合にのみ、ＪＣＰに対し削除メッセージを伝送する。

後者の条件がない場合、多くても数千個のジョブがＪＥＰ故障からの回復時点で各々のＪＣＰ／ＪＥＰ対について再度伝送されなくてはならなくなる。後者の条件がある場合、ＪＣＰは、新しいジョブが全く到着しないときでさえ、そのジョブデータベース２６内の完了したジョブを周期的に削除することができる。後者の条件における時間の長さは、回復オーバヘッド、削除オーバヘッド及び伝送コストの間の妥協である。時間が短かくなればなるほどＪＣＰは完了したジョブをより頻繁に削除でき、従ってＪＥＰ故障の場合にさらに少ないジョブが再伝送されることになる。しかしながら、後者の条件下で時間的限界を１０秒より短くすることは、ＪＣＰが実行しなければならなくなる削除トランザクションの数を増大させることになるため、恐らくやりがいのないことである。著しく小さい値では、ＪＣＰのジョブデータベース２６内でジョブの削除を扱うＣＰＵ時間がわずかしか無駄にならなくなる。より大きい値が使用される場合、多数の新しいジョブが最終的に到着した時点でＪＣＰがそのアイドル時間を浪費してしまっているかもしれず、そのときたとえ新しいジョブが準備完了していてもジョブの削除を実行するのに時間を費やさなくてはならなくなるという不利な状況が発生する可能性がある。

代替的な見通しとして、標準的な同期化されていないジョブＪのライフサイクルを考えてみる：すなわちいくつかの時点でＪＣＰ＃１がジョブＪを新規作成すると想定する。ジョブＪは、それがコンテンションスペース＃２内のデータを操作することから、コンテンションスペース＃２で実行するように割当てされる。コンテンションスペース＃２がＪＥＰ＃２の制御下にあり、ジョブＪには、ＪＣＰ＃１からＪＥＰ＃２に送られた先行ジョブのＩＤ番号より１つ大きい一意的ＩＤ番号１２３が割当てられると仮定する。

次にＪＣＰ＃１が１つのトランザクションをコミットした時点で、ジョブＪのコピーがＪＣＰ＃１のジョブのデータベース２６に書込まれることになる。ＪＣＰ＃１の現行のＩＤ番号も同様に同じトランザクション内で書き込まれることになる。トランザクションがコミットされた直後に、Ｊは一連のバイトへと変換され、ＪＥＰ＃２行きのその他のジョブと共にバッファ内に書込まれる。そのバッファが満杯になったとき、バッファ内の全てのジョブは、ＪＥＰ＃２へと１つのパケット内で送られる。

ＪＥＰ＃２は場合によってそのＪＣＰ＃１〜ＪＥＰ＃２ソケット接続からパケットを受信する。パケットは、１連のバイトから１連のジョブへと変換され、有効にＪ及びその他のジョブを再構成する。ジョブはＲＡＭ内のキューへと移動させられ、ここでこれらはその他のソケットから到着するその他のジョブとインターリーブされる。インターリービングは、ＪＣＰ＃１から来るジョブの相対的順序を保存する。

Ｊがキュー内にある間にＪＥＰ＃２が破損すると想定しよう。ＪＥＰ＃２が再ブートされ、ソケット接続は再確立される。ＪＣＰ＃１からの接続が再確立された時点で、ＪＣＰ＃１は、Ｊのコピーを含め、そのジョブデータベース２６内の全てのジョブを再伝送する。Ｊの前に着いたジョブの一部はＪＥＰ＃２により完了するまですでに実行されてしまっているかもしれない。これらのジョブは、ＪＣＰ＃１によりとにかく伝送されるが、ＪＥＰ＃２はそれらを無視する。ＪＥＰ＃２は、ジョブのＩＤが、ジョブ＃２がそのジョブデータベース２５内に記憶した、現在完了しているジョブＩＤ以下であるとき、そのジョブを無視することを知る。ＪがＪＥＰ＃２により再度受信された時点で、それは、ＪＣＰ＃１を起点とするその他のジョブとの関係においてジョブＩＤ順序でキュー内に置かれる。

場合によっては、ＪＥＰ＃２はＪをそのキューから除去し、それを実行する。ＪＥＰ＃２は、今ＪＣＰ＃１からのジョブ１２３（すなわちジョブＪ）を実行したことを表わすＲＡＭ計数器を増分する。ＲＡＭ計数器は１つのトランザクション中に何回も増分され得ることから、同じトランザクション中でＪの前及びその後に数多くのジョブを実行することができる。

トランザクションがコミットされた時点で、ＲＡＭ計数器の現行値が、ＢＤＵオブジェクト内の変更と合わせて、ジョブデータベース２５に書込まれる。この動作により、各ジョブがＢＤＵに正確に１回影響を与えることが保証される。すなわち、Ｊが１つのオブジェクト内で計数器を増分した場合、計数器は、Ｊのために１回だけ増分されることになる。

いくつかのある種のトランザクションの後、ＪＣＰ＃１からの現在完了したジョブ番号を表わすＪＥＰ＃２のＲＡＭ計数器は１００５に到達し、これは、削除メッセージを送るのに必要とされる１０００という値よりも大きい。新しい計数器値はこのときジョブ削除メッセージ内でＪＣＰ＃１に伝送し戻されることになる。

ＪＣＰ＃１は、ＩＤ＝１００５を伴う削除メッセージを受信した時点で、（以上で記述したラップ演算を用いて）１００５以下のＩＤをもつそのデータベース内の全てのジョブを削除する。ＪのＩＤは、１００５以下のものである１２３であるため、それは削除されることになる。この時点で約１０００以上のジョブが削除されつつあること、そしてそれらのうちの多くが当初単一のトランザクション内で書き出されていたことから、削除には標準的に非常にわずかなジョブデータベース２６のページをディスクに書き戻すことしか必要としない。このトランザクションがひとたびコミットすると、いずれのデータベース内にも又はいずれのプロセッサのメモリー内にもＪの痕跡はもはや何もなくなる。

ＪＣＰ＃１とＪＥＰ＃２との間に起こった唯一のネットワーク通信は、ＪＣＰ＃１からＪＥＰ＃２へのジョブの伝送及びＪＥＰ＃２からＪＣＰ＃１への削除メッセージの伝送であった。ＪＥＰ＃２が最初の伝送の後に破損したことだけを理由として、ジョブＪの伝送はこの例において２回起こった。削除メッセージは、１つのパケットで約１０００のジョブを一掃した。

ネットワーク上で伝送される情報を圧縮することにより、ネットワーク通信量を減少させることができる。例えば、単純な圧縮スキームとしては、ジョブのサイズを低減させるものが考えられる。ジョブは１つのオブジェクトであり、そして各々のオブジェクトはそのオブジェクトの構造及び挙動を定義するあるクラスのインスタンスであることから、我々はジョブをクラス「ジョブ」の異なるサブクラスのインスタンスとして定義づけすることができる。ジョブは、クラス「住所」又はクラス「人物」のインスタンスを更新するために新規作成することができる。従って、ジョブクラスは、そのタスクが１つのオブジェクトクラスに向かって導かれているジョブを内含する。ＪＣＰが最初に１つのジョブクラスのインスタンスをバイトへと符号化した時点で、そのクラスの名前は、ジョブオブジェクトの符号化と共に伝送される。このとき、このクラスは遭遇したクラスのリストに付加され、一意的番号が与えられる。このクラスのインスタンスが次に伝送される時には、このクラスの一意的番号が代りに伝送される。こうして、圧縮スキームは、ジョブの伝送オーバーヘッドを有効に低減させる。

各ＪＥＰの効率を改善するためには、我々がＯＩＤソーティングと呼ぶ技術を使用することができる。この技術では、ジョブが実行されるトランザクションの開始時点で、全ての利用可能なジョブはまず最初に、そのジョブによって修正されることになるオブジェクトがある場合その一意的オブジェクト識別子によりソートされる。１つのジョブを実行することによって多数のオブジェクトを修正できる場合には、任意に１つを選択することができる。１つのジョブが１つのオブジェクトを新規作成する場合には、新規オブジェクトを含むことになるコンテナの識別子がソーティングのために使用される。このとき、ジョブの実行はこのリストを通して順番に進行する。

ソートされたジョブリストが単一のトランザクション内で完全に実行されない可能性があるため、我々は、万一故障が発生した場合に、回復中に残りのジョブを再構築するためにオブジェクト内に充分な情報を記録しなければならない。この情報には、各々のジョブソースについて、リスト内のジョブの最初と最後のｉｄ番号が含まれる（ジョブには、そのジョブがそこから及びそこへと伝送されるＪＣＰ／ＪＥＰ対に関してのみ一意的ｉｄ番号が割当てられる）。こうして我々は、回復時点で正確に同じジョブリストを再構築することになるが、我々もまた１つのトランザクションをコミットする場合に常にこれらのジョブのうちのどれだけが実際に実行されたかを記録しなければならない。その情報は、故障からの完璧な回復を可能にする。故障したＪＥＰの回復中、我々は、故障時点で実行中であったジョブのソートされたリストに参与するジョブを各ＪＣＰが少なくとも再伝送するのを待たなくてはならない。

ソートされた全部のジョブリストが完了した時点で、次に、実行されたジョブを提供した各ＪＣＰに対して、ジョブ削除メッセージを送ることができる。我々がリスト内のどこにいるかを告げる持続計数器がリストの出発点ではなく終点との関係におけるものである限りにおいて、この時点以前に削除メッセージを送ることもなお合理的である。そうでなければ、リスト内の早期ジョブの一部が削除された時点で、これらが回復時にＪＥＰに対し再送されることはない。

ジョブによる影響を受けたオブジェクトの一意的オブジェクト識別子によりジョブをソートすることには、いくつかの理由がある：すなわち、オブジェクト識別子は、互いに数値的に近いオブジェクト識別子が互いに物理的にさらに近いオブジェクトを表わすことになるように１つのオブジェクトの物理的場所を符号化することから、トランザクション１回につきデータベースからのさらに少ないページしか検査／書込みされる必要がなくなる可能性があるからである。同じページへの多数の書込みが、単一の物理的書込みへと合わせて集約されることになる。トランザクション１回につきロックされる必要があるコンテナの数は少なくなるかもしれない。オブジェクト識別子の高いビットはコンテナを特定し、低いビットはそのコンテナ内のオブジェクトを特定する。コミット時に書込まれるページは、ディスク上で強い物理的近接性をもち、従ってシーク時間は短縮されることになる。

回復時点にジョブでの正確に同じリストが必ず生成されるようにするため、ソーティング規準は一貫してタイを中断しなくてはならない。こうして、更新されつつあるオブジェクトのオブジェクト識別子を考慮した後、発信ＪＣＰ＃及びジョブのｉｄ番号に基づいてさらにソートすることによってタイが中断されなくてはならない。この値の対は一意的であることが保証され、タイをはっきりと（任意に）中断するのに充分なものである。

１つのオブジェクトに対する各々の変更は潜在的に多くの作業を必要とする（例えば後述のようにオブジェクトを再インデクシングすること）可能性があることから、できればこの状況を避けたいと考えるかもしれない。従って１つのジョブの実行が求められた時点で、このジョブは、同じオブジェクトに影響を与えるジョブのリストを検査することができる（これらのジョブは、ソートされたリスト中で現行ジョブの後にくる）。このとき、これらのジョブによって表わされた変更は、一緒に単一の更新オペレーションの形に折畳みされ得、このオペレーションは、我々の例では、この変更セットについて再インデクシングが一度だけ起こることを可能にする。ジョブは、矛盾する変更を実行する順序を識別するため、該当する場合、タイムスタンプを指示することができる。

修正中のデータの場所に基づいてジョブを、順序づけする以外に、ジョブがいかに緊急に完了されなくてはならないかに基づいてジョブでの優先順を定めたい場合があるかもしれない。バッチジョブを完了させることに緊急性はないかもしれないが、ユーザーによって直接トリガーされるオブジェクト更新ジョブはおそらく、できる限り早く実行すべきである。このニーズを支援する基本的機構がいくつか存在する。

デッドラインベースのソフト実時間優先性スキームにおいては、各ジョブには１つの時刻が結びつけられている。ジョブがこの時刻までに完了していることが強く望まれる。残念なことに、これはＯＩＤソーティングと干渉する。この矛盾を解決するために、以下のアルゴリズムが使用される。任意の時点で、ＪＥＰは、満了時間によってソートされたジョブのヒープを有する。ジョブ実行プロセスは、このヒープの最上要素を参照する。これは、我々が一時的に過負荷状態にある場合には、過去にあると考えられる最も早いデッドラインをもつジョブである。５秒より多く未来にあるジョブをポップしたか又は全てのジョブをポップしたかのいずれかが先に起こる時点まで、ジョブがヒープからポップされる。このとき、我々はこれらのジョブのＯＩＤ順にソートし、１回のトランザクション内でこれらをできるかぎり多く実行させようと試みる。単一のトランザクション内でそれら全ての実行が終了しなかった場合（例えば、そのトランザクション内で１０秒より長く経過し、１０秒が構成上最長のトランザクション時間であるため）、我々は、トランザクションをコミットし、次のトランザクションでこれらのジョブの実行を続ける。

このスキームで完了したジョブの削除に対処するためには、同期化されたジョブについて既に記述した解決法を参照する。１つの同期化されたジョブは、コピーがそのＪＥＰのデータベースにコミットされた時点で、「対処された」とみなされる。この時点で（又はその後一時置いた時点で）、ＪＣＰがそのジョブのそのコピーを削除できることを表示するメッセージでＪＣＰに対し送り戻される。ＯＩＤソーティングされた実行（すなわちジョブｉｄ順にない実行）を支持するために、全ジョブのコピーを、ただ同期化されたものでなく、ＪＥＰのデータベースにコミットする必要がある。

図１を参照すると、データ処理センタ１９１内のＢＤＵ２２は、数百万個のオブジェクトを含むことができる。ＢＤＵ内で１つのオブジェクトの位置を特定するため、その場所又はその他の属性を含むそのオブジェクトについて情報が記憶され、並行（同時）処理環境内で効率良くアクセスするために配置されている。

例えば、保険会社のデータ処理センタ１９１の場合にはＢＤＵオブジェクトの各々は、あるタイプの保険証券の下で保険を担保されている人物についての記録を表わすかもしれない。このタイプの保険証券の特長に変更がある場合、保険代理店はこのタイプの保険証券の下で保険を担保されている人々全ての位置を特定し、彼らにその変更について通知することを望む可能性がある。この人々の位置を効率良く特定するため、予めソートされたエンティティを含むファイルを使用することができる。予めソートされたエントリの各々は、１人の人物のオブジェクト及びその人物を識別する上で不可欠なその他の情報に対するポインタを内含する。例えば、保険代理店は、最後の名前によって予めソートされた一定の与えられたタイプの保険証券の下で保険にかかっている全ての人物についてのエントリをもつフイァルを使用することができる。

オブジェクトが新規作成され、削除され又は更新された時点で、ファイル内の対応するエントリは更新されなければならない。オブジェクトを新規作成し、削除し又は更新する全てのジョブが確実に一貫して対応する予めソートされたエントリを修正することになるようにするためには、ジョブは、ファイル、予めソートされたエントリ及びオブジェクトに対し必要な変更を行なうため共通の機構及び共通の書式に合意しなくてはならない。ファイル及び予めソートされたエントリの書式は、望ましいオブジェクトの探索及び位置特定を容易にするように設計されており、従って、予めソートされたエントリ内の情報の書式又はレイアウトは標準的にファイル内のその他のエントリと同じである。

共通機構は、対応するエントリを予めソートするために、オブジェクトのどの属性が使用されるか、エントリ内にどの情報が表示されるか及び１つのオブジェクト内の変更がいかにエントリへと伝搬すべきかを予め定義づけする。我々が共通機構と呼んでいるのは、非同期インデックスマネージャ（ＡＩＭ）であり、ファイルとはインデックスであり、予めソートされたエントリとはインデックスエントリである。

数万（またはそれ以上）の同時データアクセスを可能にするデータベースシステムにおいては、アクセスの矛盾を回避しながらインデックスの無欠性を維持することが非常に重要である。ＡＩＭは、インデックスをいかに構造化し維持すべきかを定義する。インデックス内の変更を実行するタスクは、ＵＳＰによってスケジュールされたジョブによって実施される。例えば、１つのオブジェクトが付加又は削除された時点で、該当するインデックス内の対応するインデックスエントリを付加又は削除するべく新しいジョブが産生される。同様にして、１つのオブジェクトを更新することがインデックスエントリの精度に対し効果をもつ場合、影響を受けたインデックスエントリを含む該当するインデックスを更新するべく、ジョブが産生される。

インデックスは、概念上、特定の書籍の位置を特定するため図書館で使用されるカードカタログに似ている。カードカタログは、各々１冊の書籍についての情報を含むインデックスカードを保持している。情報には書籍の簡単な要約ならびに、図書館内で書籍の位置を特定するのにカードカタログユーザーにとって必要なその他のデータが含まれている可能性がある。

書籍は、著者、題名又は主題といったよう多数の規準のうちのいずれか１つによって探索され得、書籍を表わすインデックスカードは、効率を良くするため探索規準によって分類される。一定の与えられたカタログは標準的には同じタイプの事物のコレクションのための情報を保持している。例えば、一つの書籍カタログ、定期刊行物カタログ又は音響媒体（テープ又はＣＤ）カタログも存在し得る。カタログ内の全てのインデックスカードは、いかに情報が組織されているかに関して同じレイアウトを有する。例えば、書籍の題名は全てのインデックスカードの最上部にあり、著者名は題名の下にある。

ＢＤＵ内でオブジェクトの位置を特定するために使用されるインデックスは、概念的にカードカタログに類似している。インデックスは、各々１つのオブジェクト（書籍）の小さな要約を含むインデックスエントリー（インデックスカード）のコレクションを内含している。１つのインデックス内で識別されたオブジェクトは同じタイプのもの、すなわちオブジェクト指向の専門用語では同じクラスのものである。インデックス内のインデックスエントリは、同じデータ構造を有する。インデックスエントリは、インデックスの意図されたアクセスパターン及びサイズに応じて、予め規定されたキーによってソーティング又はハッシングされ得る。

各々のインデックスは、システムアドミニストレータによって定義されうるキー及び非キー属性を有する。キー属性は、インデックスエントリをソーティング又はハッシングするために使用され、非キー属性は、キー属性と合わせてインデックスエントリ内に表示される。非キー属性の表示は、インデックスのユーザーがＢＤＵからオブジェクトを検索する必要なくオブジェクトについてのある種の予め規定された情報を一覧できるようにする。図書館の例では、ＩＳＢＮによってソートされたインデックスカードは、書籍の題名及び著者を内含する情報を含み得る。

図５は、インデックスエントリの図である。データベース内の全ての人物は、そのインデックスが、キー属性ＳＳＮによりソートされたそれぞれのインデックスエントリにより表わされる人物オブジェクトの１クラスを含んでいることを意味するPerson−ＳＳＮと呼ばれるインデックス内に対応する１つのインデックスエントリ４０を有する。インデックスの各々のインデックスエントリはＳＳＮ、人物の氏名及び、それ自体人物の名前についてのより多くの情報を含む名前オブジェクト４２を指す人物オブジェクト４１に対するポインタを含有する。

インデックス及びインデックスエントリはディスク上及びメモリ内に記憶され得る。メモリ内にインデックスのコピーを記憶することによってインデックスアクセス時間を短縮し、従ってオブジェクトの位置を特定する処理速度を高めることができる。メモリ内のインデックスのコピーは、メモリー常駐（すなわちＲＡＭ常駐）探索構造（例えば２分探索樹又はハッシュテーブル）として実施される。ユーザーがＢＤＵオブジェクトを更新するための要求を提出すると、結果としての更新ジョブは、ＢＤＵオブジェクトを更新するのみならず、付随するインデックスをも更新する。探索構造は、ディスク上のインデックス及びＢＤＵにおける変更についてロックステップで更新されなくてはならない。各々のインデックス更新は、ＢＤＵオブジェクトを更新するジョブを実行したことの結果であることから、ジョブには、ディスク上のインデックス及びＢＤＵオブジェクトと探索構造の一貫性を維持する付加的な責任が与えられる。ＪＥＰが故障している場合、回復時点でＪＥＰは、ＢＤＵを走査することによってメモリ内の探索構造を再構築する。

ＢＤＵにおける変更はトランザクションがコミットされるまで反映されないことから、ＢＤＵオブジェクトに対する修正が、修正要求の送信直後に起こらない可能性がある。しかしながら、メモリ探索構造に対する修正は直ちに起こる。ユーザーが、ＢＤＵにコミットされなかったオブジェクトについての情報に対する問合せを提出した場合、そのオブジェクトの位置は特定され得ない。このようなコミットされていないオブジェクトについては、オブジェクト識別子（ＯＩＤ）が割当てされなかった可能性がある。このような場合には、ユーザーは単に、問合せの結果を廃棄することができる。データベース内の更新が探索構造内の更新より後ろに遅れる可能性があるという状況は時として、標準的データベースシステム内で発生し得る。オブジェクトが標準的データベースシステムにまだ書込まれていなかったならば、そのオブジェクトを発見することはできない。この状況に対処する代替的スキームは、１つのジョブを実行しているときに直ちに探索構造を変更せず、むしろ変更を蓄積してそれらを１つのトランザクションがコミットされた直後に適用することである。

図６は、システムアドミニストレータが１つのオブジェクトクラスのためのインデックスを定義できるようにするクラスエディタ５０と呼ばれるユーザーインタフェースである。一般に、１つのオブジェクトは、人物タイプ又は製品タイプといったオブジェクトタイプによってカテゴリに分類できる。１つのオブジェクトタイプは多数のクラスを含むことができる；すなわち例えば、車両保険会社は、その被保険者を、総合保険担保範囲をもつ人々及び責任保険担保範囲をもつ人々に分類することができる。各々のクラスは、少なくとも１つの対応するインデックスを有している。各インデックスは、クラスエディタから編集できるキー属性及び非キー属性を有している。

クラスエディタ５０は、システムアドミニストレータが自ら新規作成又は編集するインデックスについてのキー５１を選択し、インデックスエントリ内に記憶することを望む非キー属性５２を選択することを可能にする。図７においては、編集されつつあるインデックスは、Test::Personのクラス５３を含んでいる。インデックスのキーはＳＳＮであり、インデックスの各々のインデックスエントリはＳＳＮについての情報、人物の住所、人物の住所に対応する郵便番号（図示せず）を内含している。

１人の人物が１つ以上の住所を有する可能性があることから、この人物を複数の郵便番号に結びつけることができる。同じ郵便番号をもつ全ての人物の位置を特定する上での効率を考えると、この郵便番号がインデックス内のキーである場合、多数の住所をもつ人物については、住所１つに１つずつの多数のインデックスエントリが新規作成される。

どんなインデックスが定義されているかを見い出すためには、システムアドミニストレータは、インデックスの定義を含むスキーマを編集し表示するべくオブジェクトスキーマウインドウを開くことができる。図７は、オブジェクトクラス（６１、６２及び６３）及びそれらの付随するインデックス及び属性の定義を表示するオブジェクトスキーマウインドウ６０を示している。このスキーマは、データベース内のオブジェクトのためのクラスのレイアウトを含有している。各クラスのレイアウトは、属性及び関係に関してそのクラスのインスタンスの物理的構造を記述している。さらにこのスキーマは、データベース及びプロセッサ間でオブジェクトをコンテンションなくいかに分散させるか、データベース内にロードすべき入力ファイルをいかにして構文解析するか、そして、多数のソースからのデータをいかに統合するかを記述している。

１つのオブジェクトの付加、削除又は更新が関与するタスクについての要求がＵＳＰに到着する毎に常に、その要求について作用する１つ以上のジョブを新規作成するべくＪＣＰ３５０に対して要求が送られる。ＪＣＰは、そのオブジェクトクラスについてどのインデックスが定義されるかそしてそのインデックスのためのキーはどれかを見い出すためにスキーマ内の情報を使用する。その後、ＪＣＰ３５０は、インデックスエントリの付加、削除及び更新といったようなインデックスに対する必要な変更を見極め、インデックスを更新しタスクを完成させるために新規作成される必要のあるジョブのシーケンスを決定する。要求された各々の動作は、オブジェクト及びそのそれぞれのインデックスエントリが修正される順序について異なる必要条件を有する。この必要条件は、インデックスの無欠性を維持するため、厳守されなくてはならない。

図８は、ファイル７０をロードするためのインデックス修正プロセスの一例を示している。ファイル７０は、ＢＤＵ２２内のオブジェクトの付加６１０、削除６３０及び更新６５０を必要とする可能性がある。例えば、ファイル７０は、保険会社が取得したばかりの新しい部門の顧客記録を含んでいるかもしれない。取得した顧客記録は、既存の顧客についての複写された情報又はより最新の情報を含んでいてもよいし、あるいは又新しい顧客についての情報を含んでいてもよい。既存の顧客記録と取得した顧客記録を統合するためには、顧客記録を表わすＢＤＵオブジェクトを付加、削除及び更新するべくジョブが新規作成される。新規作成されるジョブ及びそれらが行なわれなくてはならない順序の一例として、１つのオブジェクトを削除するとき（６３０）、オブジェクトとそのインデックスエントリの間のリンクをまず最初に削除しなければならない（６３１）。このとき、オブジェクトを参照する全てのインデックスエントリを削除するためにジョブが生成される（６３２、６３３）。インデックスエントリが削除された後、オブジェクトを削除するためにもう１つのジョブが産生される（６３４、６３５）。インデックスエントリはオブジェクトが削除される前に削除されなくてはならない：そうでなければ、もう１つのプロセスではオブジェクトが削除されてしまっている一方でオブジェクトにアクセスするべくインデックスエントリの１つを使用することが可能である。

Objectivity/ＤＢ（登録商標）といったようないくつかの実施においては、オブジェクトに対するポインタが再度使用される。オブジェクトに対するポインタは、オブジェクト識別子（ＯＩＤ）と呼ばれ、オブジェクトのデータベース、コンテナ、ページ番号及び記憶装置内のページスロットを特定する４つの１６ビットの正負符号のついていない整数を内含する。削除されたオブジェクトのインデックスエントリは、削除されたオブジェクトのＯＩＤを内含するが、このＯＩＤは、削除されたオブジェクトと同じデータベース、コンテナ及び記録場所に付加されるもう１つのオブジェクトに再度割当てられた可能性がある。従って、１つのオブジェクトがそのインデックスエントリの前に削除された場合、２つの誤り条件のうちの一方、すなわち、プロセスが既存でないオブジェクトをアクセスしようと試みるか又はプロセスが誤ったオブジェクトを参照するといういずれかの条件が発生しうる。

オブジェクト及びそのインデックスエントリを削除する上でのコンテンションを避けるため、オブジェクトの削除を実施するジョブがＵＳＰによりスケジュールされる。これらのジョブは、いくつかのコンテンションスペース全体にわたり分散させられていてよい。各々のジョブでは、その完了を表示するもう１つの「応答」ジョブが産生させられる。応答ジョブは同期化され、オブジェクトが存在するコンテンションスペース内にロードされる。全ての応答ジョブが実行セル内に到着した時（定足数の完了によって見極められるように）、全ての応答ジョブは、そのオブジェクトを削除する単一のジョブへと折畳みされる。

１つのオブジェクトを付加するためのステップの順序決定は、削除の逆である。１つのオブジェクトを付加する場合（６１０）、そのオブジェクトは、いずれかのインデックスエントリがそれを参照できるようになる前に新規作成されなくてはならない。１つのオブジェクトが新規作成され（６１１、６１２）、持続メモリ内に記憶される場合、各々１つのインデックスエントリを新規作成し（６１４、６１５）、各々が１つの該当するコンテンションスペース内で実行される「インサート」ジョブが産生される（６１３）。ここでこれらのジョブがオブジェクト新規作成と同じトランザクション内で新規作成されるという点に留意されたい。そうでなければ、このオブジェクトは、故障が発生した場合に、対応するジョブがないまま記憶された状態で終了してしまう可能性がある。次にオブジェクトとそのインデックスエントリの間でリンクを確立するためにジョブが新規作成される（６１７）。

１つのオブジェクトを更新するとき、更新はそのオブジェクトのインデックスエントリのいずれかに対しいかなる効果ももたない可能性がある。例えば、１人の人物の色の好みはその人物のオブジェクト内に記憶されているもののインデックスエントリのいずれの中にも記憶されない可能性がある。このような状況下では、インデックスエントリのためにいかなる更新も必要とされない。その他の例においては、更新には、インデックスエントリが更新されるか又は削除されることが必要となるかもしれないし、あるいは又新しいインデックスエントリを新規作成することが必要となるかもしれない。例えば、一人の人物の住所が変更され、住所がその人物のインデックスエントリ内に記憶された情報の一部である場合、インデックスエントリは更新されなくてはならない。その人物がもう１つの郵送部域内でもう１つの家を購入し、郵便番号によりインデックスが打鍵された（すなわちソートされた）場合、その人物の新しい家の住所を含む新しいインデックスエントリが挿入される必要がある。

１つのオブジェクトを更新するプロセスにおいて、ＪＣＰ３５０は、そのインデックスエントリのいずれかを更新する前にオブジェクトを更新するべくジョブを新規作成する（６５０、６５１）。人物の住所を更新する例においては、インデックスエントリはそれが更新される前の旧住所を含んでいるものの、その人物のオブジェクトを指すインデックスエントリの中に含まれたＯＩＤはなおも現行状態にある。従って、更新されたオブジェクトはなおも、旧インデックスエントリを用いることによってその位置を特定することができる。１つのオブジェクトを更新した時点で、ＪＣＰ３５０は計算して、更新後に存在するはずのインデックスエントリのリストを作成する。次にこのリストは、どの再インデクシングジョブを実行する必要があるのか、すなわちどのインデックスエントリが更新され（６５２）、新規作成され（６５４）、削除され（６５３）又は未変更にとどまるべきかを見極めるため、オブジェクトに添付されたインデックスの現行リストと比較される。

インデックスエントリを削除すべきである（６５３）場合には、それをまずオブジェクトから接続解除し、その後ＪＣＰ３５０がインデックスエントリを削除するべくジョブを新規作成する。このジョブは、完了を表わす応答ジョブをオブジェクトまで送り戻す。この応答ジョブは、以下で記述するウエイトフリーアルゴリズムのために必要である。インデックスエントリを付加すべきである場合、ＪＣＰ３５０は、適切なコンテンションスペース内でインデックスエントリを新規作成するのに充分な情報を含むジョブを新規作成し、次に応答ジョブを、オブジェクトまで送り戻して新規作成されたインデックスエントリを表示する。インデックスエントリを更新するべきである場合、ＪＣＰ３５０は、既存のインデックスエントリを更新するのに充分な情報を含むジョブを新規作成し、その後応答ジョブを完了を表示するオブジェクトへと送り戻す。インデックスエントリが未変更のままとどまるべきである場合、行なうべきことは何もない。

１つのオブジェクトに対して多数の重複する変更が起こるとき（すなわちインデックスエントリが全てオブジェクトと一致させられる前に発生する変更）、再インデクシングジョブが正しく作動するようにするためには、ウエイトフリーアルゴリズムが用いられる。以下で記述するように、ウエイトフリーアルゴリズムは、オブジェクトが未処理ジョブを有する間１つのオブジェクト内の変更を許容し、さらに全ての再インデクシングジョブの間のコンテンションを回避する。オブジェクトは、インデックスエントリ更新オペレーションのために２ビットのフィールドすなわち、再インデクシングインジケータ及びpleaseReindexインジケータを予約する。再インデクシングインジケータは、応答ジョブをまだ送り戻していない未処理再インデクシングジョブが存在することを表示する。pleaseReindexインジケータは、その再インデクシングジョブが完了する前にオブジェクトが変更されたことを表示する。個別の再インデクシングジョブからの応答は同期化される。この同期化により、全ての応答がそのオブジェクトの対応する実行セル内に存在するとき、全ての再インデクシング応答が単一のジョブの形に折畳みすることが可能となる。単一ジョブは、オブジェクトに添付されたインデックスエントリのリストを更新する。更新の直後に、オブジェクトの pleaseReindexインジケータは検査される。インジケータがセットされる場合は、それは、オブジェクトが終了したばかりの再インデクシングの間に変化したことを表示する。新しい変更によるもう１つの再インデクシングオペレーションが直ちに開始することになる。

１つのオブジェクトを削除するための要求は再インデクシングオペレーション中に到着する可能性がある。オブジェクト及びそのインデックスエントリに対するあらゆる更新はオブジェクトが削除された後消滅することから、削除要求は更新要求よりも優先される。オブジェクトの中では付加的な確保された２ビットフィールドが使用される。１つはdeleting であり、もう１つは pleaseDeleteである。Deletingビットは、そのオブジェクトが削除されつつあるか否かを表示し、pleaseDeleteは、オブジェクトを削除するための要求が存在するか否かを表示する。いずれかのビットがセットされた時点で、pleaseReindexインジケータは無視され、その後に続くオブジェクト更新要求も同様に無視される。

ユーザーは、ＢＤＵオブジェクトについてのある種の情報を読みとることのみを望む場合、問合せを送ることができる。問合せは、その他の大部分のジョブとは異なり、オブジェクト、インデックスエントリ又はインデックス内の変更を作り出さない。ＴＣＰ／ＩＰソケットを用いたＵＳＰの実施態様においては、問合せは、ネットワークを介して伝送されるデータ量を減少させるべく問合せジョブとして取り扱うことができる。要求者がＢＤＵオブジェクトの位置を特定するための問合せを提出すると、ＪＣＰはその問合せを問合せジョブの形へと変換し、これは次に、要求されたオブジェクトが存在するコンテンションスペースのＪＥＰへと送られる。各々の問合せジョブがＩＤを有し、このＩＤは、結果を対応する問合せと整合させるべく発信元ＪＣＰのために使用される。問合せジョブには、ネットワーク上で送られるその他のジョブのように、シーケンス決定番号が与えられていない。問合せジョブがＪＥＰへの途中でネットワーク伝送中に失なわれた場合、問合せを再提出するか否か（タイムアウトの後であることが考えられる）は、要求者次第である。失なわれた問合せの取扱いは、ウェブブラウザ（例えばマイクロソフト社のInternet Explorer）を用いて広域ウェブからある会社のデータベースにアクセスする顧客にとって合理的なものである。

問合せジョブを準備完了ジョブのキューに対し付加する代りに、ＪＥＰがそれを受信した時点で、異なるキューつまり問合せジョブのキューにこの問合せジョブを付加することができる。通常のジョブの間、さらには通常のジョブのステップ間でさえ、この問合せジョブのキューを検査することができる。待機中の問合せジョブが存在する場合、問合せは直ちに実行され、結果は、そのジョブのＩＤが添付された状態で発信元ＪＣＰへと送り戻される。問合せジョブはＢＤＵ内のデータしか読取らないことから、問合せがその他のジョブより先行できるようにすることにより何らかの順序づけ上の問題が導入されることはない。

ＢＤＵ内の１つのオブジェクトは、インデックスを用いるだけでなく、オブジェクトをその他の関係するオブジェクトに連結させるリンクを用いてもその位置が特定され得る。数多くのＢＤＵオブジェクトは互いに関係をもつ。例えば、ここで再び図１を参照すると、保険会社のデータ処理センタ１９１は、その被保険者のオブジェクトと製品のオブジェクトをＢＤＵ２２内に記憶することができる。被保険者であるビル(Bill)が地震保険をかけていると想定する。これは、ビルを表わすオブジェクトと地震保険を表わす製品オブジェクトの間に「所有権」関係が存在することを意味している。システムユーザーがビルの所有する製品オブジェクトの位置を特定したいと考えた場合、１つの方法はビルのオブジェクトを検索し、どの保険証券をビルが有しているかを探し、保険製品のオブジェクトのインデックス内で地震保険のインデックスエントリの位置を特定することにある。あるいは、ビルのオブジェクトと地震保険という製品のオブジェクトの間に直接的リンクを確立することによって検索可能である。直接リンクを用いると、目的とするオブジェクト（例えば保険製品オブジェクト）に関する情報を、インデックス内を進むことなく直接検索することができる。

オブジェクト間の直接リンクは、関係と呼ばれる。１つの関係は例えば、所有権又は親子関係であり得る。オブジェクト間の関係は、非同期関係マネージャ（ＡＲＭ）と呼ばれる機構によって構築され得る。システムアドミニストレータは、オブジェクトの特定のクラス間の関係を定義する必要しかなく、ＡＲＭ機構に従いクラス（すなわちオブジェクト）の対応するインスタンス間の関係を構築するために自動的にジョブが新規作成される。

ＡＲＭは、大規模分散型データベースシステム内といったような数１００万の同時アクセスを可能にするシステムのためにはいかにして関係を構造化し維持すべきなのかを規定する。ＡＲＭは、分散型データベースを横断してオブジェクトが付加され、修正され削除されるにつれて、関係の無欠性を保証するように環境及び共通規則の組を提供する。

例えば、保険会社が、ビルの持つ地震保険の担保を停止する決定を下した場合、ＡＲＭは、地震保険の製品オブジェクトがデータベースから除去される前にビルと地震保険の間の関係が自動的に削除されることを保証する。関係の変更を実行するタスクは、高いスループット及び効率を可能にするべくＵＳＰによってスケジュールされたジョブにより実施される。例えば、１つのオブジェクトが付加又は削除されるとき、付随する関係を付加又は削除するべく新しいジョブが産生される。同様にして、１つのオブジェクトを更新するのにその関係の更新が必要とされる場合、適切な関係を更新するためにジョブが産生される。

ＪＥＰ３００により実行されるジョブは、ＢＤＵオブジェクトを付加し、削除し又は更新するジョブであり得る。オブジェクト内の変更には、ＢＤＵ内の関連するオブジェクトが付加、削除又は更新されることが必要となるかもしれない。付加、削除又は更新される必要のある関連するオブジェクトは、オブジェクト間の関係を追従することによって識別され位置特定され得る。関連するオブジェクトがひとたび発見されると、ＪＥＰ３００は、関連オブジェクトを更新するべく新しいジョブを産生する。

クラス間の新しい関係が、図７に示されているようなユーザーインタフェイスの中で定義され得る。このユーザーインタフェイスは、システムアドミニストレータが、例えば組織クラス６１、人物クラス６２及び製品クラス６３といったようなオブジェクトクラス間の関係を付加及び削除することを可能にするスキーマウインドウ６０を表示する。

新しい関係が定義された時点で、１つのクラスの中の各々のオブジェクトは、もう１つのクラスの中の対応するオブジェクトにリンクされなくてはならない。同様にして、ＪＣＰ３５０によって新しいオブジェクトが作り出された時点で、新しいオブジェクトとその他の既存のオブジェクトの間の新しい関係が確立されなくてはならない。１つの関係にある既存のオブジェクトの位置を特定するためには、ＪＣＰ３５０は、ＢＤＵ２２中の全てのオブジェクトのためのインデックスを使用する。スキーマ中に記憶された情報から、ＪＣＰ３５０は、どのインデックスを選択すべきか及びいかにして情報がインデックス内でソートされるかを知っている。ＪＣＰは、各々の既存のオブジェクトと新しいオブジェクトの間の関係を確立するためもう１つのジョブを新規作成する。

多数のプロセッサ及びデータベースを横断して分散させることのできるオブジェクト間の関係を確立するためには、オブジェクトと同期オペレーションの間のメッセージ通過を管理するために付加的なジョブ及びオブジェクトを新規作成しなければならない。より特定的に言うと、各クラスに１つのロールオブジェクトといった１組の相互接続されたロールオブジェクトとして関係を実施することができる。図６及び図１０（１）〜（４）は、既存のオブジェクト２及びオブジェクト３との新たに作成されたオブジェクト１の関係を確立するためのプロセスを例示している。オブジェクト１、オブジェクト２及びオブジェクト３は、それぞれクラス１、クラス２及びクラス３のインスタンスであり、オブジェクトは図９においてそれぞれＣ１、Ｃ２及びＣ３として示されている。

まず第１に、オブジェクトＣ１のためのジョブＪ１によりロールオブジェクトＲ１が新規作成される（５１０及び６２０）。その後ジョブＪ１ａ^t及びＪ１ｂ^tが新規作成され、各々ポインタがＲ１を指している状態で（５２０）、Ｃ２及びＣ３に対し送られる（６２２）。上添字「ｔ」は、Ｊ１ａ^t及びＪ１ｂ^tが、同期ジョブを産生するためにタグと定数分数を支持していることを表わしている。Ｊ１ａ^t及びＪ１ｂ^tはロールＲ２及びＲ３を新規作成し（６４０及び６６０）、それぞれＲ２及びＲ３を結びつけるポインタをＲ１に送り戻す（５３１、５３２）。

Ｊ１ａ^t及びＪ１ｂ^tはさらに同期ジョブＪ１ａ１^s及びＪ１ｂ１^sを産生し（５３０、６４２及び６６２）、それらをＲ１に送り戻す（６４３及び６６３）。上添字「ｓ」は、Ｊ１ａ１^s及びＪ１ｂ１^sが同期ジョブであり、そのためＪ１ａ１^s及びＪ１ｂ１^sのいずれもその両方の実行準備完了状態となるまで実行することができない、ということを示している。実行前に、Ｊ１ａ１^s及びＪ１ｂ１^sは、それぞれＪ１ａ１^s及びＪ１ｂ１^sが支持するＲ２及びＲ３についての情報を含む単一のジョブの形に折畳みされる。情報は、Ｒ２及びＲ３を指すポインタ（５３１及び５３２）、及び以下で記述するＣ２及びＣ３の予め定められたキャッシュ情報を内含する。単一のジョブはポインタを記録し、Ｒ１内に予め定められたキャッシュ情報をキャッシュ記憶する（６２４）。

単一ジョブが完了した後、このジョブは最終新規作成ジョブＪ２ａ及びＪ２ｂを産生し、Ｒ１、Ｒ２及びＲ３の情報（５４０）と共にそれらをＲ２及びＲ３にそれぞれ送る（６２６）。Ｒ２及びＲ３は、その他２つのもののポインタ（５４１、５４２、５４３及び５４４）を記録するためにその情報を用い、それぞれその他２つのものについての情報をキャッシュ記憶する（６４４及び６６４）。そのロールがその他のロール全ての情報を有する（６８０）まで、関係を１つのオブジェクトが利用することはできない。

１つの関係が確立された後、システムユーザーは、関係に参加するその他のオブジェクトについてのある種の情報と共に、１つのオブジェクトの関係全てを表示させたいと考えるかもしれない。情報を表示する性能を増大させるため、オブジェクトのロールは、そのオブジェクトが関係をもつその他のオブジェクトについての情報をキャッシュ記憶する。例えば、一人の人物は、通常多数のデータベースを横断して分散されているその他の人々、製品及び組織に対する数多くの関係を有するかもしれない。多数のデータベースを横断して分散したオブジェクトについての情報を検索するのは、効率が良くない。従って、ロールオブジェクトは、その関係内のその他のオブジェクトからの情報をキャッシュ記憶する。

図１１は、所有権関係に参加するロールオブジェクト内にキャッシュ記憶されるべきキャッシュ変数をユーザーが選択できるようにするユーザーインタフェース８０を例示している。ユーザーは、最上部に「Data」としてラベルづけされた列８１内の属性をマーキングすることによってキャッシュ変数を表示することができる。１つのオブジェクトの全ての関係の要約から、その関係内にあるその他のオブジェクトについてのキャッシュ記憶された情報を含め、リスト内に迅速に表示され得る。

全てのロールは、その付随するオブジェクトが修正された時点で増大するバージョン番号を有する。オブジェクトのバージョン番号が変更された時点で、その他のロール内にキャッシュ記憶されたオブジェクトの値を相応して更新できるようにそのオブジェクトの関係のその他のロールに対して１つのメッセージが送られる。バージョン番号は、６５５３６バージョン毎に０に回帰する。

全てのロールは同様に、それが現在キャッシュ記憶したその他のロールすべてのバージョン及び各々の他のロールについて欠けているバージョンの数も追跡する。ネットワーク上での伝送中に可変的長さの時間だけバージョン番号を含むメッセージを遅延させ、このようにして、順序外受信をひき起こすことができることから、バージョンが欠如していることもある。各々のその他のロールについての欠如しているバージョン番号の数は、いくつの未処理メッセージがそのロールからなお受信される予定であるかを表示する。ロールは、未処理メッセージがまもなく到着する場合、自らを削除したいと考えないかもしれない。

欠如しているバージョンの数を計算するために、ロールは受信した新しいバージョン番号をとり、現行バージョン番号を減算する。差から１を引いたものが、欠如しているバージョンの数を表わす現合計に加算される。現行バージョンより少ないバージョンが受信された時点で、現行バージョンと受信バージョンの間の差が計算され、欠如バージョンの現合計が１だけ減分される。例えば、現行バージョンが６でありバージョン１０が到着した場合、我々は１０−６−１＝３バージョンがなおも予想されているという事実を記録する（７、８、９）。バージョン１０が到着した後、旧バージョン８を受信することはすなわち、なお２つの旧バージョンが通過状態で存在することを意味する（７及び９）。

付随するオブジェクトが削除されるか又は更新されたことの結果として、１つの関係を削除することが可能である。もはや必要でないことを理由として関係を削除することも同様に可能である。オブジェクトの間で１つの関係が削除される場合、関係削除のための１つのアルゴリズムが、その関係内の異なるオブジェクトから同時に削除要求が存在する場合でさえもその削除の適正さを保証する。このアルゴリズムは、たとえＵＳＰがメッセージの到着順を保証しなくても物理的に削除されてしまったロールについてメッセージが到着することは決してないことを保証する。

削除プロセスは、１つのオブジェクトがそのロールの１つにそのロールの関係を削除するよう告げた時点で開始する。このロールはイニシエータと呼ばれる。スキーマ定義時点で、関係のロールクラスの１つは、コーディネータロールとして任意に選択される。コーディネータは、イニシエータとなることが許されている。

イニシエータが、削除のために既にマーキングされている場合、それは、削除がすでに進行中であり関係が場合によって削除されることになることを表わしている。こうして、イニシエータは何もしない。あるいは、イニシエータが削除のためマーキングされていない場合、それは削除のため自らマーキングし、メッセージ１をコーディネータロールに送る。イニシエータの最終バージョン番号は、メッセージ１内で中ほどへと入る。バージョン番号は、ロールキャッシュ更新要求を順序づけするために用いられる（すなわち１つのオブジェクトが変わるとき、そのオブジェクトのロールとの関係に参加する全てのロールは新しい情報でそのキャッシュを更新するよう要請される）。イニシエータロールは、削除のためにマーキングされているため、イニシエータロールのオブジェクトに対するその後の変更を無視し、その他のロールに変更メッセージを送らない。

コーディネータはメッセージ１を受理した時点で、計数器を増分させて、どれほどの隣接ロールが削除済みとしてマーキングされたかを表示する。これがこのようなメッセージの最初のものであった場合、メッセージ２が各ロールに対し送られる。

メッセージ２がロールにより受信された時点で、削除フラグが検査される。ロールが既に削除についてマーキングされている場合、それはすなわちメッセージ１が既にこのロールからコーディネータまで送られたことを意味する。従って、ロールは単に、メッセージ２が到着したことを記録し、いかなる応答も送らない。そうでなければ、ロールはそれ自体削除されたものとして自らにマーキングし、メッセージ１をコーディネータに送ってこのことを表示する。

メッセージ１及び２に対するこれらの規則は、コーディネータが各ロールから正確に１つのメッセージ１を受信し、ロールが削除済みとマーキングされた後に初めてこのメッセージを受信することになるよう保証している。このことは、たとえ、各々が関係の削除をトリガーしようとしている多数のイニシエータが存在する場合にさえ言えることである。

（コーディネータが各ロールからメッセージ１を受理したことから）全てのロールが削除済みとしてマーキングされたことをコーディネータ内の計数器が表示した時点で、コーディネータは、各ロールに対し、それを物理的に削除するのが安全であることを表示するメッセージ３を送る。

これらのメッセージ３は、コーディネータからロールに送られる最後のメッセージである。各々のロールはこれに先立ち既に削除済みとマーキングされているため、これらはまた互いにキャッシュ更新メッセージを送ることをやめている。しかしながら、ずいぶん前に送られしかもまだ到着していない（ＵＳＰがメッセージの順序付けを保証しないことを理由として）メッセージも存在し得る。全てのメッセージが到着する前に、ロールを物理的に削除するのを避けるため、各ロールは、その他のロール各々に１つずつのバージョン番号のアレイを有する。バージョン番号は、対応するロールについての受信メッセージのうちの最後のバージョン番号を記録する。もう１つのアレイは、その他のロール各々について未処理メッセージの計数を維持し、この計数は、その他のロール各々からまだ到着していないメッセージがいくつあるかを表わしている。未処理メッセージは、標準的にキャッシュ更新メッセージである。

アルゴリズムは、１つのメッセージ３だけがロールに到着することを保証し、全てのロールについて最終バージョン番号のアレイを支持している。このメッセージが到着した時点で、物理的削除準備完了フラグがセットされる。ロール内部の計数器が、未処理入メッセージが全くないことを表示した場合、そのロールは直ちに削除される。そうでなければ、旧キャッシュ更新メッセージが最終的にロールに到着した時点で常に計数器は更新され、全てのメッセージが到着しロールが物理的削除準備完了としてマーキングされた場合、ロールはデータベースから物理的に削除される。

メッセージ２は、ロールがイニシエータである場合、メッセージ１の後にロールに到着する。各ロール内のフラグが、メッセージ２が既に到着したか否かを表示し、メッセージ２（ならびに上述のように何らかの未処理キャッシュ更新メッセージ）が到着するまで物理的削除は延期される。

以下に記すのは、３つのタイプのメッセージの中に含まれる情報の短い要約である：メッセージ１（「ロールは削除のためマーキングされている」）には、次のものが含まれる：− 削除のためにマーキングされたロール。
− そのロールの最終バージョン番号。メッセージ２（「コーディネータに代って削除のためマーキングして下さい」）には以下のものが含まれる：− コーディネータのロールの最終バージョン番号。メッセージ３（「旧メッセージが全て説明された時点でロールを物理的に削除すること」）には、以下のものが含まれる：− 各ロールの最終バージョン番号。

ロールが削除されたものとしてマーキングされた時点で、そのロールをそのオブジェクトから接続解除されなくてはならない。こうして、オブジェクトの観点からは、削除は既に起こっているように見える。

一例として、Ｒ２がコーディネータである３つの接続されたロールＲ１、Ｒ２及びＲ３を考慮する。図１２及び図１３（ａ）〜（ｆ）を参照して、削除がＲ１で開始されていると想定する（８１０、８２０）。同様に、例全体について通過状態にあるＲ１からＲ３の未処理キャッシュ更新メッセージが存在することも仮定する。例は、各々のロールが取るステップを反映している。

Ｒ１： 私はマーキングされておらず（８１１）、従って、私は私自身を削除済みとしてマーキングし（８１３）、メッセージ１をコーディネータであるＲ２に送る（８１４）。私は、自分の最終バージョン番号ＦＶ１を内含することになる。（Ｒ１からＲ２への通過中のいかなるキャッシュ更新メッセージも存在しないと想定する）。
Ｒ２： Ｒ１からメッセージ１を受取り（８３０）、私は私のロールバージョン番号テーブル内に、ＦＶ１がＲ１についての現行バージョンであることを記録する（８３５）。私には、Ｒ１からＲ２まで通過中のキャッシュ更新メッセージが全く存在しないことがわかる。ここで私は各ロール（Ｒ１、Ｒ２及びＲ３）に対しメッセージ２を送り出す（８３７）。このメッセージは私の最終バージョン番号ＦＶ２を内含している。
Ｒ１： 私はメッセージ２を受信する（８３１）が、すでに削除済みと自らマーキングしたため、私は単純にコーディネータ（Ｒ２）の最終バージョン番号を記録する。
Ｒ２： 私はメッセージ２を受信する（８３１）。私はまだ削除済みとして自らマーキングしていない（８３２）ことから、私は自ら削除済み（８３３）とマーキングし、私の最終バージョン番号ＦＶ２を含めたメッセージ１をコーディネータ（すなわち私自身）に送る（８３４）。
Ｒ３： 私はメッセージ２を受信する（８３１）。私はまだ削除済みと自らマーキングしていないことから（８３２）、私は削除済みと自らマーキングし（８３３）、私の最終バージョン番号ＦＶ３を含めコーディネータ（Ｒ２）にメッセージ１を送る（８３４）。（Ｒ２が、Ｒ２からのメッセージ２を受信する前のＲ３からメッセージ１を受信すると想定する）。
Ｒ２： 私はまず最初にＲ３からメッセージ１を受信する。私は、私の現行バージョンアレイの中にＲ３の最終バージョン番号を記録する（８３５）。２つのメッセージ１（Ｒ１及びＲ３から）しか受信していないことから、他に何も行なわない。
Ｒ２： 私は次にＲ２からメッセージ１を受信する（８３１）。これは私の３番目のメッセージ１であったことから、今や、全てのロールの全ての最終バージョン番号ならびにそれら全てが削除のためにマーキングされているということがわかっている。従って私は、メッセージ３を各ロールに送り（８３８）、各メッセージ内の最終バージョン番号ＦＶ１、ＦＶ２及びＦＶ３を渡す。（Ｒ１、Ｒ２及びＲ３がＲ２からメッセージ３を受信した後、Ｒ１及びＲ２について未処理のメッセージは全く存在しないが、Ｒ３について１つの未処理メッセージが存在すると想定する）。
Ｒ１： 私はＲ２から、私が物理的に自ら削除できることを表示するメッセージ３を受信する。私は、自分の現行バージョンに対し最終バージョン番号を調和させる（８３９）。すなわち、私は、私の未処理メッセージ計数のアレイ内の未処理メッセージについてチェックする。何もないことがわかる。従って、私は自分自身を削除する（８４０）。
Ｒ２： 私はＲ２から、私が物理的に自ら削除できることを表示するメッセージ３を受信する。私は、自分の現行バージョンに対し最終バージョン番号を調和させる（８３９）。すなわち、私は、私の未処理メッセージ計数のアレイ内の未処理メッセージについてチェックする。何もないことがわかる。従って、私は自分自身を削除する（８４０）。
Ｒ３： 私はＲ２から、私が物理的に自ら削除できることを表示するメッセージ３を受信する。私は、自分の現行バージョンに対し最終バージョン番号を調和させる（８３９）。すなわち、私は、私の未処理メッセージ計数のアレイ内の未処理メッセージについてチェックする。Ｒ１からの１つの未処理キャッシュ更新メッセージが存在することがわかる。私は、物理的削除準備完了として私自身をマーキングし、次のメッセージを待機する（８４１）。
Ｒ３： 私は、Ｒ１から最終未処理キャッシュ更新メッセージを受信し（８４２）、それが到着したことを書き留め、それが私の待っている最後のメッセージであったこと及び私の物理的削除準備完了状態がセットされていること（８３９）を通知する。その後私は、データベースから自分自身を物理的に削除する（８４０）。

ここで再び図９を参照すると、１つの関係を削除するためのメッセージは、時としてロールが関係を新規作成中であるときに到着することがある。メッセージが、既存でないロールに送られるのを妨げるため、ロールは自らを削除する前に新規作成ジョブを完了することになる。ロールが、最終的新規作成ジョブ（Ｊ２ａ又はＪ２ｂ）を受信してしまう前に削除済みメッセージを受理した場合、それは自らを削除済みとしてマーキングし、最終的新規作成ジョブが受信されるまで待機する。最終新規作成ジョブが受信されると直ちに、ロールは削除メッセージの処理に着手することになる。
付属書類Ａは、VisualWorks SmallTalk5i.1がObjectivity/DB5.2.2.データベースシステムと共に設置されているシステム上で使用するための本発明の実施のソースコードを内含する。

その他の実施態様も冒頭の請求項の範囲内に入る。例えば、本発明は、関係データベースといったような、オブジェクトデータベースではないデータベース上で実施することができる。オブジェクトデータベースにおいては、データオブジェクトはデータ項目として参照され得、データオブジェクト属性は、データ要素として参照され得る。関係データベースにおいては、データ記録はデータ項目とみなすことができ、データフィールドは、データ要素とみなすことができる。

更新ストリームプロセッサを用いたデータ処理センタを例示する図である。 連合データベースの図である。 更新ストリームプロセッサの図である。 更新ストリームプロセッサのための代替的設計を例示する図である。 インデックスエントリを例示する。 クラスエディタのためのユーザーインタフェースを例示する。 スキーマの表示を例示する。 ファイルをロードするときにインデックスを修正するプロセスを示す例である。 １つの関係を確立するためのプロセスを例示する。 １つの関係を確立するためのプロセスの流れ図である。 ロールのためのキャッシュ変数を選択するためのユーザーインタフェースを例示する。 １つの関係を削除するためのプロセスの流れ図である。 関係を削除するため３つのロールの中から送られたメッセージのシーケンスを例示する。

１０ 連合データベース
１２ システムデータベース
１３ カタログ
１５ スキーマ
２２ ビジネスデータユニット（ＢＤＵ）
２３ 更新ストリームプロセッサ（ＵＳＰ）
２５ ジョブリスト
２６ ジョブデータベース
１００、１１０ データベース
１２０、１３０及び１４０ コンテナ
１４５ オブジェクト
１４８ リンク
１８１ ローカルエリアネットワーク（ＬＡＮ）
１８９ 顧客
１９１ データ処理センタ
１９２ トランザクションシステム
１９５ 公衆網
１９６ サーバー
１９８ タスク又はジョブ命令
１９９ コールセンターオペレータ
２９１ コンテンションスペースオブジェクト
２９２ 行制御オブジェクト
３００ ジョブ実行プロセス（ＪＥＰ）
３０４ 行
３５０ ジョブ新規作成プロセス（ＪＣＰ）

Claims (16)

1. 持続的にデータを保持するデータベースを維持するステップと、
   プロセッサによる並行実行用にジョブを受け取るステップと、を含む方法であって、
   前記データベースにおける前記データの少なくとも２つの異なる項目は、矛盾しない２つの領域又は２つの物理的クラスタ内に保持され、前記データに対する矛盾するアクセスは前記領域又は前記クラスタのいずれか１つ内において回避され、その際他の前記２つの領域又は前記２つの物理的クラスタにおける前記データへの同時アクセスは回避せず、
   前記データベース内の矛盾しない領域又は物理的クラスタに持続的に保持されているデータに対して前記プロセッサの１つによるアクセスを必要とするジョブは、対応する論理要素に受け取られ、異なる矛盾しない領域又は異なる物理的クラスタに対して前記プロセッサによるアクセスを必要とするジョブは異なる論理要素に受け取られ、少なくともいくつかの前記ジョブはグループとしての実行を必要とする１つの論理要素に受け取られ、前記グループ内の前記ジョブの各々は前記グループ内の前記ジョブの参入を定義する関連付けられた情報を示すデータを操作し、
   前記プロセッサの各々は、前記グループ内の全てのジョブが前記論理要素に受け取られかつ前記グループ内の全てのジョブについて実行可能であるという前記関連付けられた情報を決定するまでは、前記グループ内のジョブを実行しないことを特徴とする方法。
2. 請求項１に記載の方法であって、グループとして実行されるべく受け取られるジョブは、他のジョブの分岐によって生成されることを特徴とする方法。
3. 請求項１に記載の方法であって、グループのジョブに関連付けられた前記情報は前記ジョブの生成時に生成されることを特徴とする方法。
4. 請求項１に記載の方法であって、前記グループ内のジョブの各々によって操作されるデータは、前記グループ内に参入するものとしてのジョブを特定するタグを含むことを特徴とする方法。
5. 請求項１に記載の方法であって、前記グループ内のジョブの各々によって操作されるデータは、前記グループ内の前記ジョブの参入割合を示す定数分数を含むことを特徴とする方法。
6. 請求項１に記載の方法であって、前記ジョブは順序づけて実行用に受け取られ、
   前記プロセッサに、前記ジョブが実行用に受け取られる順序以外の少なくともいくつかの前記ジョブを実行させるステップをさらに含むことを特徴とする方法。
7. 請求項６に記載の方法であって、前記プロセッサの１つによって実行される前記少なくともいくつかのジョブは、単一の集約されたジョブに置換されることを特徴とする方法。
8. 請求項６に記載の方法であって、前記プロセッサの各々は、前記ジョブによってアクセスされなくてはならないディスク上の前記持続的に保持されているデータの物理的場所に基づいて、前記少なくともいくつかのジョブの処理順序を決定することを特徴とする方法。
9. 請求項１に記載の方法であって、前記プロセッサによって実行される前記少なくともいくつかのジョブは冗長なものであり、前記プロセッサは前記冗長なジョブを実行しないことを特徴とする方法。
10. 請求項１に記載の方法であって、前記プロセッサが、前記受け取られたジョブを、互いに並列かつ独立して実行するステップを含むことを特徴とする方法。
11. データ記憶システムであって、
    持続的にデータを保持するデータベースを維持する手段と、
    タスクソースからタスクを受け取る手段と、
    前記タスクの各々について、前記タスクを完了するために実行されるべきジョブを定義する手段と、
    関連付けられた前記タスクの優先順に基づいた順序で、コンテンションを回避しつつ並行実行のために前記タスクのための前記ジョブの全てを待ち行列化する手段と、を含み、
    前記タスクは優先性情報に関連付けられており、前記優先性情報は前記タスクの各々が実行のための少なくとも２つの異なる優先性レベルのうちの１つを有するものとして識別する情報であることを特徴とするデータ記憶システム。
12. 請求項１１に記載のシステムであって、前記タスクのうちの少なくともいくつかは前記データベースの領域を使用するための競合する要求を有し、前記領域の各々は所定の時間において全ての書込みをロックされているか又はロックされていないデータを含み、前記領域の各々は１つのプロセッサに関連付けられていることを特徴とするシステム。
13. 請求項１１に記載のシステムであって、前記ジョブは、タスクの生成とそのタスクのために定義されたジョブの実行の間の予め定められた平均的な短い遅延だけを保証するような順序で実行されることを特徴とするシステム。
14. 請求項１１に記載のシステムであって、前記タスクは、リアルタイムでの実行のためユーザーにより生成される優先性の高いタスク及びソフトウエアプロセスにより生成される優先性の低いタスクを含むことを特徴とするシステム。
15. 請求項１１に記載のシステムであって、前記ジョブは、プロセッサに分散され実行を待機している１つのステージングされたジョブセットから、各々のプロセッサによって、予め定められたサイズの実行セットへと選択されることを特徴とするシステム。
16. データ記憶システムであって、
    持続的にデータを保持するデータベースを維持する手段と、
    前記データベース内のデータに対するアクセスを必要とするジョブを、並行実行のために受け取る手段と、
    前記ジョブを待ち行列化して、前記ジョブが実行のために受け取られた順序以外で前記ジョブのうちの少なくともいくつかを前記データに対するアクセスのコンテンションを回避しつつ実行させる手段と、を含み、
    前記データベースにおける前記データの少なくとも２つの異なる項目は、矛盾しない２つの領域又は２つの物理的クラスタ内に保持され、前記データに対する矛盾するアクセスは前記領域又は前記クラスタのいずれか１つ内において回避され、その際他の前記２つの領域又は前記２つの物理的クラスタにおける前記データへの同時アクセスは回避せず、
    前記データベース内の矛盾しない領域又は物理的クラスタに持続的に保持されているデータに対して前記プロセッサの１つによるアクセスを必要とするジョブは、対応する論理要素に受け取られ、異なる矛盾しない領域又は異なる物理的クラスタに対して前記プロセッサによるアクセスを必要とするジョブは異なる論理要素に受け取られ、
    前記ジョブは、待ち行列化されて前記論理要素に受け取られ、前記論理要素の１つに受け取られた前記ジョブのいくつかは、対応する前記矛盾しない領域又は前記物理的クラスタ内において、他の前記矛盾しない領域又は前記物理的クラスタ内において実行されたジョブとのコンテンション及び前記データに対するアクセスのコンテンションを回避しつつ、前記実行されたジョブが実行のために受信された順序以外の順序で実行されることを特徴とするデータ記憶システム。
    
    

Images