JP2020161152A - 分散データグリッドにおける分散データ構造をサポートするためのシステムおよび方法 - Google Patents

Abstract

【課題】分散データグリッドにおける分散データ構造をサポートするシステムおよび方法を提供する。【解決手段】分散データグリッド２００は、複数のバケットを含む。各バケットは、分散データ構造の多数のエレメントを収容するための容量を有する。分散データグリッドは、状態所有者プロセスを含む。状態所有者プロセスは、分散データ構造に関する状態情報を保持し、分散データ構造に関する状態情報をクライアントプロセスに与える。分散キューは、複数のプロセスに格納されたバケットのキューを含む。各バケットは、分散キューの多数のエレメントを含む。分散キューは、当該分散キューに関する状態情報のローカルバージョンを保持する名前付きキューを含む。状態情報のローカルバージョンは、分散データグリッドにおけるバケットのキューに対する先頭ポインタと末尾ポインタとを含む。【選択図】図２

Description

著作権に関する注意
本特許文献の開示の一部には、著作権保護の対象となるものが含まれている。著作権者は、この特許文献または特許開示の何者かによる複製が、特許商標庁の特許ファイルまたは記録にある限り、それに対して異議を唱えないが、そうでなければ、いかなる場合もすべての著作権を留保する。

発明の分野
本発明は、概してコンピュータシステムに関し、特に分散データグリッドのサポートに関する。

背景

現代の計算システム、特に大規模な組織および企業で採用されている計算システムは、サイズおよび複雑度が増し続けている。特に、インターネットアプリケーション等の分野では、何百万人ものユーザがアプリケーションに同時にアクセスできるはずであると予測され、そうすると、事実上、ユーザが生成し消費するコンテンツの量とそのコンテンツを伴うトランザクションが急激に増加することになる。また、このような作用の結果、データベースおよびメタデータの記憶装置に対するトランザクションコールの数がそれに応じて増加するが、上記データベースおよびメタデータの記憶装置は、そのような要求に応えるための容量が限られている場合がある。これが、本発明の実施形態が取組もうとしている一般的な分野である。

概要
本明細書には、分散データグリッドにおける分散データ構造をサポートするシステムおよび方法が記載されている。分散データグリッドは複数のバケットを含み、各バケットは、分散データ構造の多数のエレメントを収容するための容量を有するように構成されている。さらに、分散データグリッドは、状態所有者プロセスを含み、状態所有者プロセスは、分散データ構造に関する状態情報を保持するように構成され、分散データ構造に関する状態情報をクライアントプロセスに与える。

本明細書には、分散データグリッドにおける分散キューをサポートするシステムおよび方法が記載されている。分散データグリッドは複数のバケットを含み、各バケットは、分散データキューの多数のエレメントを収容するための容量を有するように構成されている。さらに、分散キューは、分散キューに関する状態情報のローカルバージョンを保持する名前付きキューを含み得る。上記状態情報のローカルバージョンは、分散データグリッドにおけるバケットのキューに対する先頭ポインタと末尾ポインタとを含む。

本発明のさまざまな実施形態に従うデータグリッドクラスタを説明する図である。 本発明のある実施形態に従う、分散データグリッドにおける分散データ構造のサポートを説明する図を示す。 本発明のある実施形態に従う、分散データ構造におけるバケットのサポートを説明する図を示す。 本発明のある実施形態に従う、クライアントプロセスを用いる分散データ構造に対するオペレーションの実行を説明する図を示す。 本発明のある実施形態に従う、分散データグリッドにおける分散データ構造をサポートするための典型的なフローチャートを示す。 本発明のある実施形態に従う、分散データグリッドにおける分散キューのサポートを説明する図を示す。 本発明のある実施形態に従う、分散キューにおけるバケットを説明する図を示す。 本発明のある実施形態に従う、分散キューに対するエレメントの提供を説明する図を示す。 本発明のある実施形態に従う、分散キューに対するエレメントの提供のための相互作用図を示す。 本発明のある実施形態に従う、分散キューにおけるバケットに対するエレメントの提供のための相互作用図を示す。 本発明のある実施形態に従う、分散キューからのエレメントのポーリングを説明する図を示す。 本発明のある実施形態に従う、分散キューからのエレメントをポーリングまたはピーキングするための相互作用図を示す。 本発明のある実施形態に従う、分散キューにおけるバケットからのエレメントをポーリングまたはピーキングするための相互作用図を示す。 本発明のある実施形態に従う、分散データグリッドにおける分散キューをサポートするための典型的なフローチャートを示す。

詳細な説明
本明細書には、分散データグリッドにおける分散データ構造をサポートすることができるシステムおよび方法が記載されている。分散データグリッドは複数のバケットを含み、各バケットは、分散データ構造の多数のエレメントを収容するための容量を有するように構成されている。さらに、分散データグリッドは、状態所有者プロセスを含み、状態所有者プロセスは、分散データ構造に関する状態情報を保持するように構成され、分散データ構造に関する状態情報をクライアントプロセスに与える。

分散データグリッド
ある実施形態に従うと、本明細書において「データグリッドクラスタ」または「データグリッド」と呼ばれているものは、複数のコンピュータサーバを含むシステムであり、これらのコンピュータサーバは、分散またはクラスタ化環境においてともに働くことによって情報を管理しかつ関連する計算等のオペレーションを管理する。データグリッドクラスタを用いることにより、サーバ間で共有されるアプリケーションオブジェクトおよびデータを管理することができる。好ましくは、データグリッドクラスタは、短いレスポンス時間、高いスループット、予測可能なスケーラビリティ、連続可用性、および情報の信頼性を有していなければならない。これらの性能を有しているので、データグリッドクラスタは、計算集約的でステートフルな中間階層アプリケーションに非常に適している。データグリッドクラスタのいくつかの例、たとえばオラクルコヒーレンス（Oracle Coherence）データグリッドクラスタは、情報をインメモリで格納することによって、より高度な性能を得ることができ、かつ、複数のサーバ間で同期が取られた情報のコピーを取る際に冗長性を利用することによって、システムの弾力性とサーバの故障時のデータの可用性を確保することができる。たとえば、コヒーレンスは、信頼性がありスケーラビリティが高いピア・ツー・ピアクラスタリングプロトコル上に、複製および分散（分割）データ管理およ
びキャッシングサービスを提供する。

インメモリデータグリッドは、ともに働く多数のサーバにデータを分散させることによって、データ記憶および管理機能を提供することができる。データグリッドは、アプリケーションサーバと同じ階層においてまたはアプリケーションサーバにおいて実行されるミドルウェアであってもよい。これは、データの管理と処理を提供することができ、かつ、グリッド内においてデータが位置する場所に処理を進めることもできる。加えて、インメモリデータグリッドは、サーバが機能不全に陥ったまたはネットワークから切断されたときに自動的にかつトランスペアレントにフェイルオーバしそのクラスタ化されたデータ管理サービスを再度分散させることによって、単一障害点をなくすことができる。新たなサーバが追加されたときまたは故障したサーバを再起動させるときは、クラスタを自動的に加えサービスを今度はそれに対してフェイルオーバさせて、クラスタ負荷をトランスペアレントに再度分散させることができる。データグリッドはまた、ネットワークレベルのフォールトトレランス（fault tolerance）特徴とトランスペアレントなソフト再起動機能
も含み得る。

ある実施形態に従うと、データグリッドクラスタの機能は、さまざまなクラスタサービスを使用することに基づいている。これらのクラスタサービスは、ルートクラスタサービス、分割されたキャッシュサービス、およびプロキシサービスを含み得る。データグリッドクラスタ内の各クラスタノードは、クラスタサービスを提供するという点においても消費するという点においても、多数のクラスタサービスに参加することができる。各クラスタサービスは、データグリッドクラスタ内のサービスを一意に特定するサービス名と、このクラスタサービスができることを定義するサービスタイプとを有する。データグリッドクラスタ内の各クラスタノード上で実行されるルートクラスタサービス以外にも、各サービスタイプに属する複数の名前付きインスタンスがあるであろう。これらのサービスは、ユーザによって構成されてもよく、サービスのデフォルトセットとしてデータグリッドクラスタによって提供されてもよい。

図１は、本発明のさまざまな実施形態に従うデータグリッドクラスタを説明する図である。図１に示されるように、データグリッドクラスタ１００、たとえばオラクルコヒーレンスのデータグリッドは、クラスタノード１０１〜１０６等の複数のクラスタメンバ（またはサーバノード）を含み、上記クラスタノードは、クラスタノード上で実行されるさまざまなクラスタサービス１１１〜１１６を有する。加えて、キャッシュコンフィギュレーションファイル１１０を用いてデータグリッドクラスタ１００を構成することができる。ある実施形態において、データグリッドクラスタ１００は、ともに働くクラスタノードのメモリにデータを分散させることによってデータ記憶および管理機能を提供するインメモリデータグリッドクラスタである。

分散データ構造
本発明のある実施形態に従うと、分散データグリッドは分散データ構造をサポートすることができる。たとえば、分散データ構造は、分散キュー、分散セット、分散リスト、および／または分散スタックであってもよい。

図２は、本発明のある実施形態に従う、分散データグリッドにおける分散データ構造のサポートを説明する図を示す。図２に示されるように、分散データ構造２０１は、複数のバケット（たとえばバケット２１１〜２１６）を含み得る。各バケットは多数のエレメントを含むように構成されている。使用時、バケットは、ゼロ、１つ、または２つ以上のエレメントを、異なる時点において含み得る。これらのエレメントは、分散データ構造のアプリケーションに応じて、たとえばデータの単位、コール、要求、応答、メッセージ、トランザクション、および／またはイベントを含むデータエレメントであってもよい。

さらに、クラスタ２００内の状態所有者プロセス２０２は、分散データ構造２０１の状態２０３を保持する役割を有し得る。分散データ構造２０１は、個々のエレメントに対して直接働くのではなく、異なるバケット２１１〜２１６に対して別々に異なるオペレーションを実行することができる。

図２に示されるように、分散データグリッド２００内のプロセス２２１〜２２３等のプロセスのクラスタは、複数のバケット２１１〜２１６を維持する（または所有する）ことができる。たとえば、バケット２１１〜２１６を、プロセス２２１〜２２３のクラスタに均等に分散させることができ、各プロセスは、１つ以上のバケットを維持する（または所有する）役割を果たす。よって、分散データ構造２０１の全体のサイズは、単一のプロセスの最大記憶容量を超える可能性がある。なぜなら、各プロセス２２１〜２２３が分散データ構造２０１のコンテンツの一部のみを格納する役割を果たすからである。

本発明のある実施形態に従うと、分散データ構造２０１では、分散データ構造２０１内の異なるバケット２１１〜２１６に対し、異なるオペレーションを、複数のユーザプロセスが同時に実行することができる。図２に示されるように、オペレーション２０４をバケット２１１に対して実行することができ、その一方で別のオペレーション２０６をバケット２１６に対して実行する。このように、このシステムは、分散データ構造２０１における競合（contention）を減じることができる。なぜなら、分散データ構造２０１に対するアクセス要求を複数のバケットに分散させることができるからである。

さらに、分散データ構造２０１は、どの時点においても１つのプロセスのみが１つのバケット内のエレメントにアクセスできることを保証することが可能である。たとえば、システムは、競合している個々のバケットに対してロック機構を適用することができる。これに代えて、システムは、異なるプロセスが順番に処理を待つようにする要求キューを利用することができる。

図２に示されるように、オペレーション２０４がバケット２１１に対して実行されている間、バケット２１１はロックされている。同じバケット２１１に対する、オペレーション２０５等の他のオペレーションは、ロックしているオペレーション２０４が終了するまで待つ必要があるであろう。同様に、オペレーション２０６がバケット２１６に対して実行されている間、バケット２１６はロックされており、同じバケット２１６に対するオペレーション２０７等の他のオペレーションは、ロックしているオペレーション２０６が終了するまで待つ必要があるであろう。

図３は、本発明のある実施形態に従う、分散データ構造におけるバケットのサポートを説明する図を示す。図３に示されるように、分散データグリッド３００内のバケット３０１は、多数のエレメントを含むように構成され、分散データ構造の内部データ構造３１０内において１つ以上のエレメント、たとえばエレメント３１１〜３１５を含み得る。加えて、バケット３０１は、バケット３０１に格納されているエレメント３１１〜３１５にアクセスするために使用できるさまざまなバケット状態３０３を維持することができる。

本発明のある実施形態に従うと、バケット３０１は、バケット３０１が含み得る最大数のエレメントに相当する容量を有するように構成されている。よって、バケット３０１は分散データ構造の多数のエレメントを含むように構成されている。バケット３０１は、使用時、ゼロから（容量までの）１つ以上のエレメントを保持することができる。さらに、（特定のデータアクセスパターンについての性能を改善することを目的として）バケット３０１の容量を、異なる分散データ構造をサポートするために調整することができる。

加えて、バケット３０１は、分散データグリッド３００内の他のノードに複製することができる。図３に示されるように、１つ以上のエレメント（たとえば内部データ構造３２０のエレメント３２１〜３２５）と対応するバケット状態３０４とを含むバックアップバケット３０２を、バケット３０１が失われたときに代わりに使用することができる。

図４は、本発明のある実施形態に従う、クライアントプロセスを用いる分散データ構造に対するオペレーションの実行を説明する図を示す。図４に示されるように、分散データグリッド４００内の分散データ構造４０１は、複数のバケット、たとえばバケット４１１〜４１６を含み得る。加えて、状態所有者プロセス４０２は、分散データ構造４０１に関する状態情報４０３を保持する役割を有し得る。

さらに、クライアントプロセス４０４は、分散データ構造４０１に関する状態情報４０５のローカルコピーを保持する名前付きデータ構造４１０を使用する（または含む）ことができる。たとえば、システムは、クライアントプロセス４０４が最初に分散データ構造４０１に接続するときに、状態情報４０５を初期化することができる。

本発明のある実施形態に従うと、複数のクライアントプロセスが分散データ構造４０１に対して同時にアクセスすることができる。クライアントプロセス４０４上の状態情報４０５のローカルコピーは、別のクライアントプロセスが分散データ構造４０１の状態４０３を変更したときに無効（stale）になるであろう。

分散データ構造４０１を用いると、名前付きデータ構造４１０内の（すなわちクライアントプロセス４０４によって使用される）ロジックは、状態４０５が無効である可能性があることを考慮することができる。よって、毎回オペレーション前に状態情報４０５をリフレッシュする必要はない。

図４に示されるように、状態４０５が無効になると、（クライアントプロセス４０４上の）名前付きデータ構造４１０は、状態４０５をリフレッシュするために状態所有者プロセス４０２に対してメッセージを送信することができる。状態所有者プロセス４０２は、このメッセージを受けた後に、新たな状態４０３をクライアントプロセス４０４に返送することができ、そうすると、クライアントプロセス４０４は、バケット４１６に対するオペレーション４２０をプロセス４２１を通して実行することができる。

本発明のある実施形態に従うと、バケットが一旦作成されると、このバケットは、たとえ空になったとき（すなわちエレメントがすべてポーリングされたまたはこのバケットから削除されたとき）でも分散データ構造４０１から削除されることはないであろう。このことは、複数のクライアントプロセスのオペレーションをサポートするためには有益となり得る。

図５は、本発明のある実施形態に従う、分散データグリッドにおける分散データ構造をサポートするための典型的なフローチャートを示す。図５に示されるように、ステップ５０１において、システムは複数のバケットを分散データグリッド内に与えることができ、各バケットは、分散データ構造の多数のエレメントを収容するための容量を有するように構成されている。バケットは、使用中の異なるポイントにおいて分散データ構造のゼロまたは（容量までの）１つ以上のエレメントを含み得る。さらに、ステップ５０２で、状態所有者プロセスは、分散データ構造に関する状態情報を保持することができる。次に、ステップ５０３で、状態所有者プロセスは、分散データ構造に関する状態情報をクライアントプロセスに提供することができる。

分散キュー
本発明のある実施形態に従うと、分散データグリッドは分散キューをサポートすることができる。たとえば、分散キューは複数のキュー（またはバケット）からなるキューであり、各バケットはペアレントキューにおけるサブキューである。

図６は、本発明のある実施形態に従う、分散データグリッドにおける分散キューのサポートを説明する図を示す。図６に示されるように、分散キュー６０１は、分散データグリッド６００において、バケット、たとえばバケット６１１〜６１６からなるキューを含み得る。複数のバケット（たとえばバケット６１１〜６１６）は各々、多数のエレメントを含むように構成されている。使用時、バケットは、異なる時点において、ゼロ、１つ、または２つ以上のエレメントを含み得る。分散データ構造のアプリケーションに応じて、エレメントは、たとえばデータの単位、コール、要求、応答、メッセージ、トランザクション、および／またはイベントを含むデータエレメントであってもよい。

加えて、状態所有者プロセス６０２は、分散キュー６０１の状態６０３を保持する役割を有し得る。たとえば、状態６０３は、分散キュー６０１における現在の先頭バケット６１１に対する先頭ポインタと、分散キュー６０１における末尾バケット６１６に対する末尾ポインタとを含み得る。

本発明のある実施形態に従うと、クライアントプロセス６０４は、分散キュー６０１の現在の状態６０３をキュー状態所有者６０２から取得することができるとともに、分散キュー６０１に対してさまざまなオペレーション（提供およびポーリングオペレーション等）を実行することができる。

図６に示されるように、ユーザプロセス６０６〜６０７がアクセスし得るクライアントプロセス６０４は、名前付きキュー６１０を使用する（または含む）ことができる。名前付きキュー６１０は、自身のビュー内の先頭ポインタと末尾ポインタとを含むキュー状態６０５のローカルコピーを維持することができる。たとえば、キュー状態６０５における先頭ポインタは先頭バケット６１１を指すことができ、キュー状態６０５における末尾ポインタは末尾バケット６１６を指すことができる。

キュー状態６０５の構造は、クライアントプロセス６０４が最初に分散キュー６０１に接続するときに初期化できる。さらに、クライアントプロセス６０４は、毎回オペレーションの前にそのキュー状態６０５をリフレッシュする必要はない。なぜなら、（オペレーションの提供およびポーリングを実行するための）名前付きキュー６１０内のロジックは、維持されているキュー状態６０５が無効である可能性があることを考慮できるからである。

本発明のある実施形態に従うと、クライアントプロセス６０４は、１つ以上のエレメントを分散キュー６０１の末尾バケット６１６（すなわち終端）に提供する（または追加する）ことによって、提供というオペレーションを分散キュー６０１に対して実行することができる。また、クライアントプロセス６０４は、分散キュー６０１の先頭バケット６１１（すなわち前端）から１つ以上のエレメントをポーリングする（または削除する）ことによって、ポーリングオペレーションを分散キュー６０１に対して実行することができる。加えて、クライアントプロセス６０４は、ピーキングオペレーションを分散キュー６０１に対して実行することにより、（分散キュー６０１からエレメントを削除することなく）１つ以上のエレメントの値を取得することができる。

加えて、異なるクライアントプロセスが異なるオペレーションを同時に実行することを試みてもよい。異なるクライアントプロセスによって複数の試みを処理するために、分散キュー６０１の先頭バケット６１１と末尾バケット６１６の周りに暗黙のトランザクショ
ンを形成してもよい。システムは、競合している先頭バケット６１１および／または末尾バケット６１６に対してロック機構を適用することができる。これに代えて、システムは、異なるプロセスが順番に処理を待つようにする要求キューを利用することができる。

図７は、本発明のある実施形態に従う、分散キューにおけるバケットを説明する図を示す。図７に示されるように、分散キュー７００におけるバケット７０１は、エレメント、たとえばキュー７１０におけるエレメント７１１〜７１５からなるキューを含む。

加えて、バケット７０１は、バケット７０１に格納されている異なるエレメント７１１〜７１５にアクセスするために使用できるさまざまなバケット状態７０２を維持することができる。バケット状態７０２は、バケット７０１における先頭エレメント７１１に対するポインタと、バケット７０１における末尾エレメント７１６に対するポインタとを含み得る。

さらに、バケット７０１内のエレメント７１１〜７１５は、（バケット７０１を格納する）同じプロセスを用いて格納することができる。バケット７０１が最初に作成されたとき、先頭および末尾のエレメントに対するポインタは、このバケット７０１が空であることを示す特殊な値を含み得る。また、バケット７０１は、バケット７０１がキューにおける最後のバケットであるか否かを示すフラグを含み得る。

図８は、本発明のある実施形態に従う、分散キューに対するエレメントの提供を説明する図を示す。図８に示されるように、分散データグリッド８００内の分散キュー８０１は、バケット、たとえばバケット８１１〜８１６からなるキューを含み得る。バケットは各々、多数のエレメントを保持するための容量を有するように構成されていてもよく、使用中はゼロ以上のエレメントを保持し得る。加えて、状態所有者プロセス８０２は、分散キュー８０１の状態情報をキュー状態８０３に保持する役割を有し得る。

本発明のある実施形態に従うと、クライアントプロセス８０４は、名前付きキュー８１０におけるキュー状態８０５によって示されるように、末尾バケットに対して１つ以上のエレメントを提供（または追加）することを試みることができる。たとえば、クライアントプロセス８０４は、バケット８１５が末尾バケットであると想定し得る。なぜなら、キュー状態８０５における末尾ポインタがバケット８１５を指しているからである。したがって、クライアントプロセス８０４は、バケット８１５を維持しているプロセス８２１に対して提供メッセージ（一組のエレメントを含む）を送信することができる。

その後、クライアントプロセス８０４は、そのメッセージに対する応答を受信することができる。この応答の内容は、上記提供オペレーションが成功であったか否かをクライアントプロセス８０４に対して知らせることができる。たとえば、上記応答が空である場合は、提供したエレメントすべてが末尾バケットに追加されたことになる。一方、この応答が何らかのエレメントを含む場合は、これらのエレメントがバケットに提供（または追加）されなかったことになる。

システムが１つ以上のエレメントをバケットに提供（または追加）しない理由として他の理由が存在し得る。たとえば、認識された末尾バケットがもはや現在末尾ではない（すなわちキュー状態８０５が無効である）場合がある。この場合、エレメントはすべて応答で返送される。これに代えて、現在の末尾バケットが、提供されたエレメントをすべて保持するのに十分な残容量を有していない場合がある。この場合、残ったエレメントが応答メッセージで返送される。

いずれの場合も、ある提供に対する応答が、提供されていないエレメントを含むとき、
クライアントプロセス８０４は、次の末尾バケットＩＤが何であるかを知る必要があるであろう。プロセス８０４は、キュー状態８０３を所有している状態所有者プロセス８０２に対してメッセージを送信してキュー状態８０３が次の末尾バケットを指す必要があることを状態所有者プロセス８０２に知らせることができる。

複数のクライアントプロセスがある場合、クライアントプロセス８０４は、別のクライアントプロセスが既に末尾ＩＤを移動させたか否かを知らない場合がある。システムは、アトミック比較設定（atomic compare and set）オペレーションとして末尾ＩＤを移動させるオペレーションを実行することができる。

図８に示されるように、クライアントプロセス８０４が状態所有者プロセス８０２に対して末尾ＩＤのインクリメントを依頼するとき、クライアントプロセス８０４はまた、キュー状態８０５における末尾ＩＤを状態所有者プロセス８０２に対して送信することができる。

キュー状態８０５における末尾ＩＤがキュー状態８０３における現在の末尾ＩＤと一致するとき、システムは、末尾を次のバケットＩＤに移動させることによってキュー状態８０３を変更することができる。そうすると、システムは、更新されたキュー状態８０３における末尾ＩＤを応答としてクライアントプロセス８０４に送信することができる。

キュー状態８０５における末尾ＩＤがキュー状態８０３における現在の末尾ＩＤと一致しないとき、キュー状態８０３は、このメッセージによってインクリメントされたかまたは既にインクリメントされていたかのいずれかである可能性がある。この場合、システムは、現在のキュー状態８０３における末尾ＩＤを応答としてクライアントプロセス８０４に送信することができる。

たとえば、クライアント側の末尾ＩＤが１０であり所有者側の末尾ＩＤが１０である場合、所有者側の末尾ＩＤを１１に移動させることができ、この値をクライアントにリターンすればよい。クライアント側の末尾ＩＤが１０であり所有者側の末尾ＩＤが既に１１である場合、キュー状態の所有者が値１１をクライアントにリターンすればよい。

図８に示されるように、キュー状態８０３は新たな末尾バケット８１６を指している。クライアントプロセス８０４は、正しい末尾ＩＤを受信した後に、提供すべき残りのエレメントを含む提供メッセージを、新たな末尾バケット８１６を所有しているプロセスに送信することができる。

さらに、新たな末尾バケット８１６が、提供されたエレメントすべてを保持することができない場合がある。たとえば、別のクライアントプロセスが既に新たな末尾バケット８１６を満たしているかもしれない、または、新たな末尾バケット８１６がエレメントすべてを保持するのに十分な容量を有していない。その場合、システムは、分散キュー８０１に対するすべてのエレメントの提供（追加）が成功するまで、末尾バケットＩＤをインクリメントし残りのエレメントを提供する上記プロセスを繰返せばよい。

図９は、本発明のある実施形態に従う、分散キューに対するエレメントの提供のための相互作用図を示す。図９に示されるように、クライアントプロセス９０１は、分散データグリッドにおける分散キューに１つ以上のエレメントを提供（または追加）するために名前付きキュー９０２を使用することができる。分散データグリッドは、キュー状態９０６を所有するキュー状態所有者９０５であるクラスタメンバ９０５を含む。

ステップ９１１において、名前付きキュー９０２は、分散キューの末尾に新たな値を提
供するためのメッセージを（たとえばクライアントプロセス９０１から）受信することができる。クライアントプロセス９０１に対応付けられた名前付きキュー９０２は、分散キューのキュー状態９０６のローカルバージョンであるキュー状態９０３を維持することができる。

名前付きキュー９０２は、ローカルキュー状態９０３における情報が正しいと想定し得る。ステップ９１２〜９１３において、名前付きキュー９０２は、末尾ＩＤおよびキューのバージョンナンバー等の、キューに関する状態情報を要求しローカルキュー状態９０３から受信することができる。

次に、クライアントプロセス９０１に対応付けられた名前付きキュー９０２は、末尾バケットを所有するクラスタメンバに、したがってそのローカルビューに、提供メッセージを送信することができる。ステップ９１４において、名前付きキュー９０２は、受信した値を、キュー状態９０６から受信した末尾ＩＤに基づく末尾バケットを所有するクラスタメンバ９０４に提供することができる。

末尾バケットに対する上記値の提供（または追加）が成功した場合、ステップ９１５において、クラスタメンバ９０４は空のセットをリターンすることができ、ステップ９１６において、名前付きキュー９０２は、OFFER_ACCEPTEDメッセージをクライアントプロセス９０１に返送することができる。

そうでない場合、末尾バケットに対する上記値の提供（または追加）は、たとえばバケットが満杯であることが原因でまたはキュー状態のバージョンの不一致が原因で、成功していない。ステップ９１５において、クラスタメンバ９０４は、一組の、提供されなかったエレメントを、名前付きキュー９０２にリターンすることができる。その場合、名前付きキュー９０２は、たとえば次の末尾バケットにメッセージを送信することにより、提供オペレーションを再び試みてもよい。名前付きキュー９０２は、分散キューが満杯になるまでまたは受信した値の提供（または追加）に成功するまで、受信したものを分散キューの末尾に対して繰返し（たとえばループ９１０において）追加しようと試みてもよい。

ループ９１０内で、名前付きキュー９０２は、バケットが満杯であることまたはバージョンの不一致を原因とする前の提供の失敗が生じた場合、末尾ＩＤおよびキューバージョンのそのビューをリフレッシュまたは更新する必要がある場合がある。

ステップ９１７において、名前付きキュー９０２は、末尾ＩＤをリフレッシュするために要求をローカルキュー状態９０３に送信することができる。ステップ９１８において、ローカルキュー状態９０３は、キュー状態９０６の所有者であるクラスタメンバ９０５から次の末尾ＩＤを取得しようと試みてもよい。たとえば、メッセージは、ローカルキュー状態９０３におけるこのような情報に基づく末尾ＩＤおよびキューバージョン情報を含んでいてもよい。

ステップ９１９〜９２０において、クラスタメンバ９０５は、所有者バージョンのキュー状態９０６における状態情報を要求して取得することができる。よって、クラスタメンバ９０５は、たとえばローカルキュー状態９０３から受信した情報とキュー状態９０６を比較することにより、キュー状態をリフレッシュすべきか否か判断することができる。

たとえば、ローカルキュー状態９０３は、ローカルキュー状態９０３が所有者キュー状態９０６における情報と一致しないときは無効である。このような場合、所有者キュー状態９０６における状態情報を、ローカルキュー状態９０３にリターンしてもよい（すなわちローカルキュー状態９０３がリフレッシュされる）。

ローカルキュー状態９０３における情報がキュー状態９０６における情報と一致するとき、ステップ９２１において、クラスタメンバ９０５は、たとえば末尾を次のバケットＩＤに移動させることにより、キュー状態９０６を更新することができる。次に、ステップ９２２において、キュー状態９０６は、キューの更新された状態情報をクラスタメンバ９０５に与えることができる。たとえば、末尾ＩＤが最初のバケットＩＤまたはその他いずれかの使用済バケットに折返すことによって次のバケットＩＤに移動した場合は、キューバージョンナンバーをインクリメントすればよい。

加えて、キューが満杯であるか否か判断するために検査を実行することができる。たとえば、末尾ＩＤのインクリメントによって末尾ＩＤが現在の先頭ＩＤと同値になる場合、キューは満杯である。

図９に示されるように、ステップ９２３〜９２４において、クラスタメンバ９０５は、（リフレッシュまたは更新された）キューの状態情報をキュー状態９０３に与えることができ、キュー状態９０３は、キューの状態情報を名前付きキュー９０２に与えることができる。たとえば、このような状態情報は、QUEUE_FULLメッセージ、または、更新されたキューバージョンナンバーを伴う更新された末尾ＩＤを含み得る。

ステップ９２５において、分散キューが満杯である場合、名前付きキュー９０２は、QUEUE_FULLメッセージをクライアントプロセス９０１に送信することができる。そうでなければ、ステップ９２６〜９２７において、名前付きキュー９０２は、キューの状態情報を要求してキュー状態９０３から取得することができる。さらに、ステップ９２８〜９２９において、名前付きキュー９０２は、クラスタメンバ９０４に（または更新された末尾ＩＤを有するバケットを所有するその他いずれかのクラスタメンバに）値を提供（または追加）することができる。

図９に示されるように、名前付きキュー９０２は、受信した値の追加に成功するまで、たとえばループ９０１において、受信したエレメントを分散キューの末尾に提供（または追加）することを繰返し試みてもよい。ステップ９３０において、名前付きキュー９０２は、受信した値の追加に成功した後に、QUEUE_SUCCESSメッセージをクライアントプロセ
ス９０１に送信することができる。

図１０は、本発明のある実施形態に従う、分散キューにおけるバケットに対するエレメントの提供のための相互作用図を示す。図１０に示されるように、発呼側（たとえば名前付きキュー１００１）を用いて、分散データグリッドにおけるクラスタメンバ１００２が所有する特定のバケット１００３に１つ以上のエレメントを提供（または追加）することができる。

ステップ１０１１において、名前付きキュー１００１は、バケットＩＤおよびキューバージョン情報等の状態情報に基づいてクラスタメンバ１００２に値を提供することができる。ステップ１０１２〜１０１３において、特定のバケットＩＤを有するバケット１００３が存在しない場合は新たなバケットが作成されてもよい。

ステップ１０１４〜１０１５において、クラスタメンバ１００２はバケット１００３が満杯であるか否か検査することができる。バケットが満杯である場合、ステップ１０１６において、クラスタメンバ１００２はBUCKET_FULLメッセージを名前付きキュー１００１
に送信することができる。そうでない場合は、ステップ１０１７〜１０１８において、クラスタメンバ１００２はバケット１００３から状態情報を取得することができる。

ステップ１０１９において、名前付きキュー１００１のビューにおけるキューバージョン情報が、バケット１００３に対応付けられたキューバージョン情報と一致しない場合、名前付きキュー１００１はOFFER_FAILEDメッセージを名前付きキュー１００１に送信することができる。

ステップ１０２０〜１０２１において、名前付きキュー１００１は、値をバケット１００３に追加することができる。次に、ステップ１０２２において、名前付きキュー１００１は、OFFER_SUCCESSメッセージを名前付きキュー１００１に送信することができる。

図１１は、本発明のある実施形態に従う、分散キューからのエレメントのポーリングを説明する図を示す。図１１に示されるように、分散データグリッド１１００における分散キュー１１０１は、バケット、たとえばバケット１１１１〜１１１６からなるキューを含み得る。各バケットは１つ以上のエレメントを含み得る。加えて、状態所有者プロセス１１０２は、分散キュー１１０１のキュー状態１１０３の状態情報を保持する役割を有し得る。

本発明のある実施形態に従うと、クライアントプロセス１１０４は、分散キュー１１０１の先頭バケットに対してポーリングまたはピーキング動作を実行することができる。たとえば、ポーリング動作は、分散キュー１１０１からエレメント（先頭エレメント等）をリターンして削除することができる。一方、ピーキング動作は、先頭エレメントを削除せずに、分散キュー１１０１の先頭エレメントの値をリターンすることができる。

図１１に示されるように、クライアントプロセス１１０４は、バケット１１１１が分散キュー１１０１における先頭バケットであると想定する。分散キュー１１０１からのポーリングのために、クライアントプロセス１１０４は、先頭バケット１１１１を所有するプロセス１１２１にメッセージを送信する。次に、クライアントプロセス１１０４は、分散キュー１１０１の先頭からのエレメントまたはバケット１１１１が空であるという表示を含む応答を受信することができる。

バケット１１１１が空である（分散キュー１１０１自身は空でない場合）ことを応答が示す場合、名前付きキュー１１１０が維持するキュー状態１１０５は無効である。よって、キュー状態１１０５は、先頭バケットＩＤが次の先頭ＩＤに更新されるよう、リフレッシュされる必要があるであろう。

図１１に示されるように、キュー状態１１０４は、キュー状態１１０３を所有する状態所有者プロセス１１０２に、先頭ＩＤのインクリメントをキュー状態１１０３に命令するためのメッセージを送信することができる。ポーリングまたはピーキングオペレーションのために次の先頭ＩＤに移動させるオペレーション（すなわちキュー状態１１０５のリフレッシュ）は、アトミック比較設定オペレーションであってもよく、この場合、キュー状態１１０３は、現在の先頭ＩＤがクライアントの先頭ＩＤと一致する場合に限って変更される。クライアントプロセス１１０４は次に、このメッセージによってインクリメントされたかまたは以前にインクリメントされていたキュー状態１１０３からの先頭ＩＤを含む応答を受信することができる。

最後に、クライアントプロセス１１０４は、新たな先頭バケットを所有するプロセスに、ポーリング／ピーキングメッセージを再送することができる。

図１２は、本発明のある実施形態に従う、分散キューからのエレメントをポーリングまたはピーキングするための相互作用図を示す。図１２に示されるように、クライアントプロセス１２０１は、名前付きキュー１２０２を使用して、分散データグリッドにおける分
散キュー１２００の１つ以上のエレメントに対してポーリングまたはピーキング動作等の動作を実行することができる。分散キュー１２００は、キュー状態１２０６を所有するキュー状態所有者１２０５であるクラスタメンバ１２０５を含む。

ステップ１２１１において、名前付きキュー１２０２は、分散キュー１２００の先頭エレメントに対してポーリングまたはピーキング動作を実行するための（たとえばクライアントプロセス１２０１からの）メッセージを受信することができる。クライアントプロセス１２０１に対応付けられた名前付きキュー１２０２は、分散キュー１２００のキュー状態１２０３のローカルバージョンを維持することができる。

ステップ１２１２〜１２１３において、名前付きキュー１２０２は、分散キュー１２００が空であるか否かに関する情報を取得するためにキュー状態１２０３を検査することができる。分散キュー１２００が空であるとき、ステップ１２１４において、名前付きキュー１２０２は、QUEUE_EMPTYメッセージをクライアントプロセス１２０１に送信すること
ができる。

さらに、キューが空でない場合、クライアントプロセス１２０１は、現在の先頭ＩＤおよびキューバージョンナンバーを有していると想定する。ステップ１２１５〜１２１６において、名前付きキュー１２０２は、先頭ＩＤおよびキューバージョンナンバー等の状態情報を要求してローカルキュー状態１２０３から受信することができる。名前付きキュー１２０２は、分散キュー１２００の先頭エレメントに対してポーリングまたはピーキング動作を実行するためにこのような情報を使用することができる。

次に、ステップ１２１７において、名前付きキュー１２０２は、受信した先頭ＩＤに基づく先頭バケットを所有するクラスタメンバ１２０４に対してポーリングまたはピーキング動作を実行することができる。

先頭バケットに対するこの動作の実行が成功した場合、ステップ１２１８において、クラスタメンバ１２０４は、１つ以上のエレメントを名前付きキュー１２０２にリターンすることができ、ステップ１２１９において、名前付きキュー１２０２は、上記エレメントをクライアントプロセス１２０１にリターンすることができる。

そうではなく、先頭バケットに対する上記動作の実行が成功しなかった場合、ステップ１２１８において、クラスタメンバ１２０４は、空のセットを名前付きキュー１２０２にリターンすることができる。このような場合、クライアントプロセス１２０１は、先頭ＩＤおよびキューバージョン情報のそのビューを更新する必要がある場合がある。

図１２に示されるように、名前付きキュー１２０２は、分散キュー１２００が空になるまでまたはポーリングもしくはピーキング動作の実行が成功するまで、（たとえばループ１２１０において）分散キュー１２００に対するポーリングまたはピーキング動作の実行を繰返し試みてもよい。

ループ１２１０内のステップ１２２０において、名前付きキュー１２０２は、先頭ＩＤおよびキューバージョンナンバーをリフレッシュすることをローカルキュー状態１２０３に要求することができ、ステップ１２２１において、ローカルキュー状態１２０３は、キュー状態１２０６の所有者であるクラスタメンバ１２０５から次の先頭ＩＤを取得しようと試みてもよい。

ステップ１２２２〜１２２３において、クラスタメンバ１２０５は、キュー状態１２０６における状態情報の所有者バージョンを要求して取得することができる。たとえば、メ
ッセージは、ローカルキュー状態１２０３における情報に基づく先頭ＩＤおよびキューバージョン情報を含み得る。よって、クラスタメンバ１２０５は、たとえばローカルキュー状態１２０３から受信した情報とキュー状態１２０６を比較することによって、キュー状態が無効か否か判断することができる。

たとえば、ローカルキュー状態１２０３における情報がキュー状態１２０６における情報と一致しない場合、キュー状態１２０３は無効である。このような場合、キュー状態１２０６における状態情報をキュー状態１２０３にリターンしてもよい（すなわちキュー状態１２０３がリフレッシュされる）。

ローカルキュー状態１２０３における情報がキュー状態１２０６における情報と一致するとき、ステップ１２２４において、クラスタメンバ１２０５は、たとえば先頭を次のバケットＩＤに移動させることにより、キュー状態１２０６を更新することができる。次に、ステップ１２２５において、キュー状態１２０６は、キュー状態１２０６の更新された状態情報をクラスタメンバ１２０５に与えることができる。加えて、キューが空であるか否か判断するために検査を実行することができる。たとえば、分散キュー１２００は、先頭ＩＤが末尾ＩＤと同一であるときは空のキューであり、この場合、先頭ＩＤを末尾ＩＤに対してインクリメントしなくてもよい。

ステップ１２２６〜１２２７において、クラスタメンバ１２０５は、（リフレッシュまたは更新された）キューの状態情報をキュー状態１２０３に与えることができ、キュー状態１２０３は、このキュー状態情報を名前付きキュー１２０２に与えることができる。たとえば、このような状態情報は、QUEUE_EMPTYメッセージまたは更新されたキューバージ
ョンナンバーとともに更新された先頭ＩＤを含み得る。

ステップ１２２８〜１２２９において、名前付きキュー１２０２は、（複数のオペレーションを分散キュー１２００に対して実行し得るので）分散キュー１２００が空であるか否か判断するためにキュー状態１２０３を検査することができる。ステップ１２３０において、分散キュー１２００が空であるとき、名前付きキュー１２０２は、QUEUE_EMPTYメ
ッセージをクライアントプロセス１２０１に送信することができる。

そうでない場合は、ステップ１２３１〜１２３２において、名前付きキュー１２０２は、キュー状態１２０３の更新された状態情報を要求しキュー状態１２０３から取得することができる。ステップ１２３３〜１２３４において、名前付きキュー１２０２は、クラスタメンバ１２０４（または更新された先頭ＩＤを有するバケットを所有する他のいずれかのクラスタメンバ）に対してポーリングまたはピーキング動作を実行することができる。

図１２に示されるように、名前付きキュー１２０２は、ポーリングまたはピーキング動作の実行が成功するまで、（たとえばループ１２１０において）分散キュー１２００の先頭に対するポーリングまたはピーキング動作の実行を繰返し試みてもよい。ステップ１２３５において、名前付きキュー１２０２は、エレメントをクライアントプロセス１２０１にリターンすることができる。

図１３は、本発明のある実施形態に従う、分散キューにおけるバケットからのエレメントをポーリングまたはピーキングするための相互作用図を示す。図１３に示されるように、発呼側（たとえば名前付きキュー１３０１）を用いて、分散データグリッドにおけるクラスタメンバ１３０２が所有するバケット１３０３に対し、ポーリングまたはピーキング動作等の動作を実行することができる。

ステップ１３１１において、名前付きキュー１３０１は、バケットＩＤおよびキューバ
ージョンナンバー等の状態情報に基づいてクラスタメンバ１３０２に対しポーリングまたはピーキング動作を実行することができる。

ステップ１３１２〜１３１３において、クラスタメンバ１３０２は、バケット１３０３が空であるか否か検査することができる。ステップ１３１４において、バケット１３０３が空である場合、クラスタメンバ１３０２は、BUCKET_EMPTYメッセージを名前付きキュー１３０１に送信することができる。

ステップ１３１５〜１３１６において、クラスタメンバ１３０２は、バケットの状態情報をバケット１３０３から取得することができる。

ステップ１３１７において、名前付きキュー１３０１のビューにおけるキューバージョン情報がバケット１３０３に対応付けられたキューバージョン情報と一致しない場合、クラスタメンバ１３０２は、POLL_FAILEDメッセージを名前付きキュー１３０１に送信する
ことができる。

そうでない場合、ステップ１３１８〜１３２４において、クラスタメンバ１３０２は、バケット１３０３に対してポーリングまたはピーキング動作を実行することができる。たとえば、この動作がポーリング動作である場合、バケット１３０３は、バケットエレメント１３０４を削除または消去する前にバケットエレメント１３０４の値をリターンすることができる。加えて、バケットは、バケットエレメント１３０４の削除または消去後にバケットが空になった場合は、キューバージョンを更新することができる。次に、クラスタメンバ１３０２は、エレメントを名前付きキュー１３０１に与えることができる。一方、上記動作がピーキング動作である場合、バケット１３０３は、バケットエレメント１３０４を削除または消去することなくバケットエレメント１３０４の値をリターンすることができる。

図１４は、本発明のある実施形態に従う、分散データグリッドにおける分散キューをサポートするための典型的なフローチャートを示す。図１４に示されるように、ステップ１４０１において、システムは、複数のバケットを分散データグリッド内に与えることができる。次に、ステップ１４０２において、システムは、分散キューの１つ以上のエレメントを複数のバケットに格納することができる。さらに、ステップ１４０３において、システムは、名前付きキューを用いて分散キューに関する状態情報のローカルバージョンを保持することができ、状態情報のローカルバージョンは、分散データグリッド内のバケットのキューに対する先頭ポインタと末尾ポインタとを含む。

分散データグリッドにおける分散キューをサポートするためのシステムは、１つ以上のマイクロプロセッサと、この１つ以上のマイクロプロセッサ上で実行される分散データグリッド内の複数のバケットとを含み、キューにおいて維持される上記複数のバケットは、分散キューの１つ以上のエレメントを格納するように構成されており、上記システムはまた、上記分散キューに関する状態情報のローカルバージョンを保持する名前付きキューを含み、上記状態情報のローカルバージョンは、上記分散データグリッドにおけるバケットのキューに対する先頭ポインタと末尾ポインタとを含む。

上記システムがさらに含む手段において、上記名前付きキューはクライアントプロセスに対応付けられ、クライアントプロセスは、上記分散キューにおける１つ以上のエレメントにアクセスするために１つ以上のユーザプロセスによって使用される。

上記システムがさらに含む手段において、上記クライアントプロセスは、上記分散キューに関する状態情報のローカルバージョンに基づいて上記バケットのキューにおける末尾
バケットに対して１つ以上のエレメントを提供するように構成されている。

上記システムがさらに含む手段において、上記クライアントプロセスは、末尾バケットを所有するプロセスから受信したメッセージが１つ以上のまだ提供されていないエレメントを含むときは、上記キュー状態が無効であると判断するように構成されている。

上記システムがさらに含む手段において、上記クライアントプロセスは、状態所有者プロセスから、リフレッシュされたキュー状態を取得するように構成されており、リフレッシュされたキュー状態は新たな先頭バケットを示す。

上記システムがさらに含む手段において、上記クライアントプロセスは、上記分散キューに関する状態情報のローカルバージョンに基づいて、バケットのキューにおける先頭バケットからのエレメントをポーリングまたはピーキングするように構成されている。

上記システムがさらに含む手段において、上記クライアントプロセスは、上記分散キューが空でないときに上記先頭バケットを所有するプロセスから受信したメッセージが空である場合は、上記キュー状態が無効であると判断するように構成されている。

上記システムがさらに含む手段において、上記クライアントプロセスは、状態所有者プロセスから、リフレッシュされたキュー状態を取得するように構成されており、リフレッシュされたキュー状態は新たな先頭バケットを示す。

上記システムがさらに含む手段において、各バケットは、現在の先頭エレメントに対するポインタと現在の末尾エレメントに対するポインタとを含むバケット状態を維持し、バケットはオペレーションが実行されている間はロックされ、上記バケットに対するその他のオペレーションは、上記実行されているオペレーションが完了するまで待機するように構成されている。

分散データグリッドにおける分散キューをサポートするための方法は、複数のバケットを分散データグリッド内に与えるステップを含み、各バケットは分散キューの１つ以上のエレメントを格納するように構成されており、上記方法はさらに、分散キューの１つ以上のエレメントを複数のバケットに格納するステップと、名前付きキューを用いて分散キューに関する状態情報のローカルバージョンを保持するステップとを含み、上記状態情報のローカルバージョンは、分散データグリッドにおけるバケットのキューに対する先頭ポインタと末尾ポインタとを含む。

上記方法はさらに、上記名前付きキューをクライアントプロセスに対応付けるための手段を含み、上記クライアントプロセスは、上記分散キューにおける１つ以上のエレメントにアクセスするために１つ以上のユーザプロセスによって使用される。

上記方法はさらに、上記クライアントプロセスを用いて、上記分散キューに関する状態情報のローカルバージョンに基づいて上記バケットのキューにおける末尾バケットに対して１つ以上のエレメントを提供するための手段を含む。

上記方法はさらに、上記クライアントプロセスを用いて、末尾バケットを所有するプロセスから受信したメッセージが１つ以上のまだ提供されていないエレメントを含むときは、上記キュー状態が無効であると判断するための手段を含む。

上記方法はさらに、上記クライアントプロセスを用いて、状態所有者プロセスから、リフレッシュされたキュー状態を取得するための手段を含み、上記リフレッシュされたキュ
ー状態は新たな先頭バケットを示す。

上記方法はさらに、上記クライアントプロセスを用いて、上記分散キューに関する状態情報のローカルバージョンに基づいて、バケットのキューにおける先頭バケットからのエレメントをポーリングまたはピーキングするための手段を含む。

上記方法はさらに、上記クライアントプロセスを用いて、上記分散キューが空でないときに上記先頭バケットを所有するプロセスから受信したメッセージが空である場合は、上記キュー状態が無効であると判断するための手段を含む。

上記方法はさらに、上記クライアントプロセスを用いて、状態所有者プロセスから、リフレッシュされたキュー状態を取得するための手段を含み、上記リフレッシュされたキュー状態は新たな先頭バケットを示す。

上記方法はさらに、各バケットのバケット状態を維持するための手段を含み、バケット状態は、現在の先頭エレメントに対するポインタと現在の末尾エレメントに対するポインタとを含み、バケットはオペレーションが実行されている間はロックされ、上記バケットに対するその他のオペレーションは、上記実行されているオペレーションが完了するまで待機するように構成されている。

分散データグリッドにおける分散キューをサポートするための命令が格納された非一時的なマシン読取可能な記憶媒体において、上記命令はコンピュータシステムによって実行されたときに上記コンピュータシステムに以下のステップを実行させる。これらのステップは、複数のバケットを分散データグリッド内に与えるステップを含み、各バケットは、分散データキューの多数のエレメントを格納するように構成されており、上記ステップはさらに、分散キューの１つ以上のエレメントを複数のバケットに格納するステップと、名前付きキューを用いて分散キューに関する状態情報のローカルバージョンを保持するステップとを含み、上記状態情報のローカルバージョンは、分散データグリッドにおけるバケットのキューに対する先頭ポインタと末尾ポインタとを含む。

分散データグリッドにおける分散データ構造をサポートするための装置は、複数のバケットを分散データグリッド内に与えるための手段を含み、各上記バケットは、分散データ構造の多数のエレメントを収容するための容量を有するように構成されており、さらに、状態所有者プロセスを通して、分散データ構造に関する状態情報を保持するための手段と、状態所有者プロセスを通して、分散データ構造に関する状態情報をクライアントプロセスに与えるための手段とを含む。

上記装置はさらに、上記複数のバケットを分散データグリッドにおける複数のプロセスに均等に分散させるための手段を含む。

上記装置はさらに、分散データ構造に対応付けられた異なるバケットに対して複数のオペレーションを同時に実行するための手段を含む。

上記装置はさらに、上記状態所有者プロセスによって、分散データ構造が変化したときに上記分散データ構造に関する状態情報を更新するための手段を含む。

上記装置はさらに、オペレーションが実行されている間バケットをロックするための手段を含み、上記バケットに対するその他のオペレーションは、上記実行されているオペレーションが完了するまで待機するように構成されている。

上記装置はさらに、分散データ構造を、分散キュー、分散セット、分散リスト、または分散スタックとするための手段を含む。

上記装置はさらに、各バケットにバケット状態を維持させるための手段を含み、上記バケット状態は、上記バケットにおける１つ以上のエレメントにアクセスするために使用される。

上記装置はさらに、少なくとも１つのバケットをバックアップバケットに対応付けるための手段を含み、上記バックアップバケットは、上記少なくとも１つのバケットに含まれる１つ以上のエレメントを含む。

上記装置はさらに、上記クライアントプロセスに、分散データ構造に関する状態情報のローカルバージョンを格納させ、上記状態情報のローカルバージョンが無効になったときに限り、上記状態所有者プロセスが保持する状態情報に基づいて上記クライアントプロセスに格納されている上記状態情報のローカルバージョンをリフレッシュさせ、上記分散データ構造におけるバケット内の１つ以上のエレメントに対してオペレーションを実行させるための手段を含む。

本発明は、本開示の教示に従いプログラムされた、１つ以上のプロセッサ、メモリ、および／またはコンピュータ読取可能な記憶媒体を含む、従来の汎用もしくは専用デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを１つ以上用いて、適宜実装し得る。適切なソフトウェアコーディングは、熟練したプログラマが本開示の教示に基づいて容易に準備できるものである。これはソフトウェア技術における当業者には明らかであろう。

実施形態によっては、本発明は、本発明のプロセスのうちいずれかを実行するためにコンピュータをプログラムするのに使用できる命令が格納された記憶媒体または（１つまたは複数の）コンピュータ読取可能な媒体であるコンピュータプログラムプロダクトを含む。この記憶媒体の例は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む、任意の種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム（分子メモリＩＣを含む）、または、命令および／またはデータを格納するのに適した任意の種類の媒体もしくはデバイスを含み得るものの、これらに限定されない。記憶媒体または（１つまたは複数の）コンピュータ読取可能な媒体は非一時的なものであってもよい。

本発明に関するこれまでの記載は例示および説明を目的として提供されている。すべてを網羅するまたは本発明を開示された形態そのものに限定することは意図されていない。当業者には数多くの変更および変形が明らかであろう。上記変更および変形は、記載されている特徴の関連する任意の組合わせを含む。実施形態は、本発明の原理およびその実際の応用を最もうまく説明することによって意図している特定の用途に適した本発明のさまざまな実施形態およびさまざまな変形を他の当業者が理解できるようにするために、選択され説明されている。本発明の範囲は以下の請求項およびその均等物によって定義されることが意図されている。

Claims (23)

1. 分散データグリッドにおける分散データ構造をサポートするためのシステムであって、
   １つ以上のマイクロプロセッサと、
   前記分散データグリッドにおける複数のバケットとを含み、各前記バケットは、分散データ構造の多数のエレメントを収容するための容量を有するように構成されており、
   前記１つ以上のマイクロプロセッサ上で実行される状態所有者プロセスを含み、前記状態所有者プロセスは、
   前記分散データ構造に関する状態情報を保持するように構成され、かつ、
   前記分散データ構造に関する状態情報をクライアントプロセスに与えるように構成されている、システム。
2. 前記複数のバケットは、前記分散データグリッドにおける複数のプロセスに均等に分散されている、請求項１に記載のシステム。
3. 複数のオペレーションは、前記分散データ構造に対応付けられた異なるバケットに対して同時に実行される、請求項１または２に記載のシステム。
4. 前記状態所有者プロセスは、前記分散データ構造が変化したときに前記分散データ構造に関する状態情報を更新するように構成されている、請求項１〜３のいずれかに記載のシステム。
5. オペレーションが実行されている間バケットはロックされ、前記バケットに対するその他のオペレーションは、前記実行されているオペレーションが完了するまで待機するように構成されている、請求項１〜４のいずれかに記載のシステム。
6. 前記分散データ構造は、分散キュー、分散セット、分散リスト、または分散スタックである、請求項１〜５のいずれかに記載のシステム。
7. 各バケットはバケット状態を維持しており、前記バケット状態は、前記バケットにおける１つ以上のエレメントにアクセスするために使用される、請求項１〜６のいずれかに記載のシステム。
8. 少なくとも１つのバケットは、前記少なくとも１つのバケットに含まれる１つ以上のエレメントを含むバックアップバケットに対応付けられている、請求項１〜７のいずれかに記載のシステム。
9. 前記クライアントプロセスは、
   前記分散データ構造に関する状態情報のローカルバージョンを格納するように構成され、かつ、
   前記分散データ構造におけるバケット内の１つ以上のエレメントに対してオペレーションを実行するように構成されている、請求項１〜８のいずれかに記載のシステム。
10. 前記クライアントプロセスは、前記状態情報のローカルバージョンが無効になったときに限り、前記状態所有者プロセスが保持する前記状態情報に基づいて前記クライアントプロセスに格納されている前記状態情報のローカルバージョンをリフレッシュするように構成されている、請求項９に記載のシステム。
11. 分散データグリッドにおける分散データ構造をサポートするための方法であって、
    複数のバケットを前記分散データグリッド内に与えるステップを含み、各前記バケット
    は、分散データ構造の多数のエレメントを収容するための容量を有するように構成されており、
    状態所有者プロセスを通して、前記分散データ構造に関する状態情報を保持するステップと、
    前記状態所有者プロセスを通して、前記分散データ構造に関する状態情報をクライアントプロセスに与えるステップとを含む、方法。
12. 前記複数のバケットを前記分散データグリッドにおける複数のプロセスに均等に分散させるステップをさらに含む、請求項１１に記載の方法。
13. 前記分散データ構造に対応付けられた異なるバケットに対して複数のオペレーションを同時に実行するステップをさらに含む、請求項１１または１２に記載の方法。
14. 前記状態所有者プロセスによって、前記分散データ構造が変化したときに前記分散データ構造に関する状態情報を更新するステップをさらに含む、請求項１１〜１３のいずれかに記載の方法。
15. オペレーションが実行されている間バケットをロックするステップをさらに含み、前記バケットに対するその他のオペレーションは、前記実行されているオペレーションが完了するまで待機するように構成されている、請求項１１〜１４のいずれかに記載の方法。
16. 前記分散データ構造は、分散キュー、分散セット、分散リスト、または分散スタックである、請求項１１〜１５のいずれかに記載の方法。
17. 各バケットがバケット状態を維持するステップをさらに含み、前記バケット状態は、前記バケットにおける１つ以上のエレメントにアクセスするために使用される、請求項１１〜１６のいずれかに記載の方法。
18. 少なくとも１つのバケットを、前記少なくとも１つのバケットに含まれる１つ以上のエレメントを含むバックアップバケットに対応付けるステップをさらに含む、請求項１１〜１７のいずれかに記載の方法。
19. 前記クライアントプロセスは、
    前記分散データ構造に関する状態情報のローカルバージョンを格納するステップと、
    前記状態情報のローカルバージョンが無効になったときに限り、前記状態所有者プロセスが保持する前記状態情報に基づいて前記クライアントプロセスに格納されている前記状態情報のローカルバージョンをリフレッシュするステップと、
    前記分散データ構造におけるバケット内の１つ以上のエレメントに対してオペレーションを実行するステップとをさらに含む、請求項１１〜１８のいずれかに記載の方法。
20. 前記分散データ構造は分散キューであり、キューにおいて維持されている前記複数のバケットは、前記分散キューの１つ以上のエレメントを格納するように構成されており、前記状態所有者プロセスは、前記分散キューに関する状態情報のローカルバージョンを保持する名前付きキューであり、前記状態情報のローカルバージョンは、前記分散データグリッドにおけるバケットのキューに対する先頭ポインタと末尾ポインタとを含む、請求項１１〜１９のいずれかに記載の方法。
21. コンピュータシステムによって実行されたときに請求項１１〜２０のいずれかに記載の方法を前記コンピュータシステムに実行させるマシン読取可能なフォーマットのプログラム命令を含むコンピュータプログラム。
22. 非一時的なマシン読取可能なデータ記憶媒体に格納されている請求項２１に記載のコンピュータプログラムを含むコンピュータプログラムプロダクト。
23. 分散データグリッドにおける分散データ構造をサポートするための命令が格納された非一時的なマシン読取可能な記憶媒体であって、前記命令はコンピュータシステムによって実行されたときに前記コンピュータシステムに以下のステップを実行させ、前記ステップは、
    複数のバケットを分散データグリッド内に与えるステップを含み、各前記バケットは、分散データ構造の多数のエレメントを収容するための容量を有するように構成されており、
    状態所有者プロセスを通して、前記分散データ構造に関する状態情報を保持するステップと、
    前記分散データ構造に関する状態情報をクライアントプロセスに与えるステップとを含む、非一時的なマシン読取可能な記憶媒体。

Images