JP6189304B2

JP6189304B2 - 分散データグリッド内のサーバ側イベントモデルをサポートするためのシステムおよび方法

Info

Publication number: JP6189304B2
Application number: JP2014530894A
Authority: JP
Inventors: オリバー，ブライアン; アーリス，ノア; グレイザー，ジーン; リー，ロバート・エイチ
Original assignee: オラクル・インターナショナル・コーポレイション
Priority date: 2011-09-15
Filing date: 2012-09-14
Publication date: 2017-08-30
Anticipated expiration: 2032-09-14
Also published as: US20160234057A1; CN103827864A; CN103827864B; JP2014526750A; US9621409B2; US20130074101A1; EP2756430A4; US9348668B2; US20130074083A1; US9602339B2; EP2756430A2; WO2013040463A3; WO2013040463A2; EP2756430B1

Description

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

本発明は分散演算環境におけるデータキャッシングおよびアクセス技術に関し、特に、分散データグリッド内のサーバ側イベントモデルのサポートに関する。

背景
分散データ管理システムの文脈において、データ変更についての情報を提供するためにイベントモデルが用いられることがある。典型的な例では、クライアントはリスナーを登録して、あるデータ上の特定のイベントをリスニングし得る。データが変更されるとイベントが発生し、クライアントはリスナーによってイベントを通知される。

この手法の１つの制限は、イベントが既に発生したという意味で非同期であることであり、つまり、クライアントはイベントが既に発生した後に通知されるのでクライアントはデータ変更に影響を及ぼす有効な手段を有しないことである。このため、イベントに変更を加えるためには、クライアントは新たなトランザクション全体を行なって当該変更を加えざるを得ないことがあり得る。別の制限は、クライアントはしばしば非常に大きいデータセットであるものの内部のすべてのイベントをリスニングするように登録されるため、ソリューションのサイズおよびスケーラビリティであることが多い。

また、異なるセマンティクスおよび特有の構成形態を有するさまざまな拡張可能なフックが別個の特徴としてユーザに提示されることが多い。これらのフックが互いにどのように関連しているかについてのドキュメンテーションはほとんどない場合があり、どのフックが使用に最適であるかが常に明確であるとは限らない。さらに、プログラミングモデルはフックごとに異なり、その多くが独特の制限を有する。

したがって、上記の制限に対処するか制限を解消し、かつ多数の他の利点を提供する新たなソリューションが望まれる。

概要
本明細書には、分散データグリッド内のサーバ側イベントモデルに、クラスタ全体にわたって分散されたデータパーティションを格納する複数のクラスタノードを提供し得るシステムおよび方法が記載され、各クラスタノードは１組のパーティションを担当する。上記システムは、１つ以上のイベント・インターセプタを、クラスタ内に配置されたイベント・ディスパッチャにマッピングし得る。１つ以上のイベント・インターセプタは、イベント・ディスパッチャからディスパッチされる少なくとも１つのイベントをハンドリングすることができ、少なくとも１つのイベントは分散データグリッド内のオペレーションに関連付けられている。上記システムは、上記１つ以上のイベント・インターセプタによる少なくとも１つのイベントのハンドリングが完了するまで、分散データグリッド内のオペレーションの完了を遅らせ得る。

本発明の実施形態に係る、サーバ側イベントモデルをサポートする分散データグリッドを示す図である。本発明の実施形態に係る、分散データグリッド内のサーバ側イベントモデルを提供するためのフローチャートを示す図である。本発明の実施形態に係る、分散データグリッド内のサーバ側イベントモデルのイベント階層を示す図である。本発明の実施形態に係る、分散データグリッド内のサーバ側イベントモデルについてイベントをディスパッチするフローを示す図である。本発明の実施形態に係る、分散データグリッド内のイベント・インターセプタの登録を示す図である。本発明の実施形態に係る、分散データグリッド内のイベント・インターセプタの登録を示す図である。本発明の実施形態に係る、分散データグリッド内のサーバ側イベントモデルの継続のサポートを示す図である。

詳細な説明
さまざまな実施形態に従い、サーバ側イベントモデルには、分散データグリッド内で、クラスタ全体にわたって分散されたデータパーティションを格納する複数のクラスタノードが提供され得、各クラスタノードは１組のパーティションを担当する。１つの例示的な分散データグリッドは、オラクル（登録商標）社のCoherenceデータグリッドである。このシステムは、１つ以上のイベント・インターセプタを、クラスタ内に配置されたイベント・ディスパッチャにマッピングし得る。１つ以上のイベント・インターセプタは、イベント・ディスパッチャからディスパッチされる少なくとも１つのイベントをハンドリングすることができ、少なくとも１つのイベントは分散データグリッド内のオペレーションに関連付けられている。このシステムは、上記１つ以上のイベント・インターセプタによる少なくとも１つのイベントのハンドリングが完了するまで、分散データグリッド内のオペレーションの完了を遅らせ得る。

ある実施形態に従い、分散データグリッド内のサーバ側機能を実行するクリティカルパスにイベントが発生し得る。データグリッドは、ある一定のデータが変更されたときにのみ受動的な演算を実行し得る。データグリッドは、クライアントをクリティカルパスに注入することを回避するために、クライアント側からのインタラクションを必要とせずにそのようなイベントのハンドリングをサポートする。データグリッド内では、クライアントがクリティカルパスに関与するとクライアント応答を待つための不要な遅延が生じ得るため、クライアントがクリティカルパスに関与できないようにすることが好ましい。

ある実施形態に従い、クリティカルパス内のイベントのハンドリングは、クライアント・インタラクションのオーバーヘッドなしにデータグリッドが大きなデータ列を処理するときに有益であり得る。こうして、データグリッドはより多くのタイプのイベントを使用し得、イベントをハンドリングするための異なるイベント・リスナーまたはインターセプタを定義し得る。さらに、データグリッド内のデータに対するオペレーションの実行は、クリティカルパス内にディスパッチされるイベントのハンドリングが完了するまで遅らされる。こうして、必要とされるサーバ側イベントは、分散データグリッドの性能を改良し得る。
サーバ側イベントモデル

ある実施形態に従い、Coherenceの単一イベントモデル（Unified Event Model：UEM）などのサーバ側イベントモデルは、分散データグリッド内のサーバ側プログラミングモデルを単純化するために用いられ得る汎用イベント・フレームワークである。

サーバ側イベントモデルは、一貫性があるセマンティックモデル、一様な構成を提供し得、分散データグリッドのサーバ側プログラミング能力を拡張するための柔軟性を拡大し得る。イベントは、対応するイベントハンドラの内部からどのオペレーションが実行され得るかを形式化する、明確に定義されたセマンティクスを有し得る。これらのイベントは、分散データグリッド・クラスタ内で拡張性に対して「ワンストップ・ショップ（one-stop shopping）」を提供し得る。ユーザはどのイベントが利用可能であるかを迅速に調べ、それらのセマンティクスを理解し得る。

サーバ側イベントモデルを用いて、分散データグリッドは、広範な拡張可能なフックの代わりにサーバ側プログラミングモデルを提供し得る。たとえば、Coherenceでは、エンドユーザはこのサーバ側プログラミングモデルを用いて、バッキング・マップ・リスナー（Backing Map Listener）、パーティション・リスナー（Partition Listener）、キャッシュ・ローダー／キャッシュ・ストア（Cache Loader/Cache Store）、トリガ（Trigger）、トランスフォーマ（Transformer）、エントリ・プロセッサ（Entry Processor）、アグリゲータ（Aggregator）およびカスタム・バッキング・マップ（Custom Backing Map）のためのカスタムロジックを挿入し得る。こうして、分散データグリッドは、拡張可能なフックの使用に関する異なる問題を回避し得、外部ユーザアプリケーションとのデータ交換を単純化し得る。

図１は、本発明の実施形態に係る、サーバ側イベントモデルをサポートする分散データグリッドを示す図である。図１に示されるように、サーバ側イベントモデル１１０は、相互接続された複数のクラスタノード１０１〜１０６を含むデータグリッド・クラスタ１００内に設けられ得る。サーバ側イベントモデルは、１つ以上のイベント・インターセプタ１２１〜１２３にマッピングされ得る少なくとも１つのイベント・ディスパッチャ１１１を含む。イベント・インターセプタは、サーバ側イベントモデル・フレームワークによって発生したイベント１２０を受信してハンドリングする役割を果たす。データグリッド・クラスタ内に配置されるイベント・ディスパッチャは、イベント・インターセプタを、イベント・インターセプタが登録されているイベントに対してトリガする役割を果たし得る。

ある実施形態に従い、イベント・インターセプタは、サーバ側イベントモデル・フレームワークによって発生したイベントを受信してハンドリングする役割を果たし得る。イベント・インターセプタはさらに、２つ以上のイベント・インターセプタが同じイベントに登録されている場合、ともにチェーンされ得る。こうして、複数のインターセプタが単一のイベントのコンテキスト内で実行され得る。

Coherenceの例では、イベント・インターセプタ・インターフェイスは、イベントをハンドリングするためのロジックを実装するためにエンドユーザに提供され得る。リスティング１において以下に示されるようなサンプルインターフェイスは、イベントをハンドリングするための１つの方法および登録処理の一部として用いられる別の方法の、２つの方法を有し得る。

ある実施形態に従い、イベント・ディスパッチャは、イベントが発生する必要のあるコンテキストに緊密に結合され得る専用オブジェクトである。分散データグリッド内のキーの場所に配置された専用イベント・ディスパッチャ・インスタンスが存在し得る。

Coherenceでは、イベント・ディスパッチャは、StorageEventをハンドリングするためのPartitionedServiceに関連付けられ得る。リスティング２において以下に示されるように、最適化されたイベント・インターセプタの登録を容易にするために、イベント・ディスパッチャは、イベント・ディスパッチャがディスパッチする役割を果たす明確に定義された１組のイベントを有し得る。

さらに、イベント・ディスパッチャは、たとえばＪＭＸを介して自身の性能についての統計を公開し、サーバ側イベントモデルがシステム内でどのように挙動しているかについての見通しを開発者およびオペレーションチームの両方に与え得る。そのような情報には、すべての登録されたイベント・インターセプタの名前、登録された各イベント・インターセプタの対象のイベント・タイプ、発生／処理されたイベントの数、投げられた例外の数、イベントのハンドリングに費やされる平均時間、イベントのハンドリングに費やされる最長時間、上記イベントの間に最も長く時間がかかったイベント・インターセプタの名前が含まれる。

図２は、本発明の実施形態に係る、分散データグリッド内のサーバ側イベントモデルを提供するためのフローチャートを示す図である。図２に示されるように、ステップ２０１において、１つ以上のイベント・インターセプタがイベント・ディスパッチャにマッピングされ得る。イベント・ディスパッチャは、分散データグリッド内のオペレーションに関連付けられる少なくとも１つのイベントをディスパッチするように動作する。次に、ステップ２０２において、上記１つ以上のイベント・インターセプタは、イベント・ディスパッチャから上記１つ以上のイベント・インターセプタにディスパッチされる少なくとも１つのイベントをハンドリングし得る。最後に、ステップ２０３において、分散データグリッドは、上記１つ以上のイベント・インターセプタによる少なくとも１つのイベントのハンドリングが完了するまで、オペレーションの完了を遅らせる。
イベント階層

ある実施形態に従い、イベントは、分散データグリッド内で実行される何らかのオペレーションの観察可能な発生を表わす。分散データグリッド内には異なるタイプのイベントが存在し得る。たとえば、クライアント・イベントはクライアント・コンテキスト（すなわち非ストレージ・メンバー）内で発生し得、ストレージ・イベントはストレージ可能メンバーのコンテキスト内で発生し得る。

ある実施形態に従い、イベントは、イベントが発生する機能領域に対応する１組のインターフェイスと定義され得る。

図３は、本発明の実施形態に係る、分散データグリッド内のサーバ側イベントモデルのイベント階層を示す図である。図３に示されるように、Eventインターフェイス３０１はシステム内のすべてのイベントのベースである。システム内の各イベントオブジェクトは、自身に関連付けられた１つ以上のイベント・タイプを有し得る。Eventインスタンスのコンシューマは、イベント・タイプに基づいてどの動作を実行すべきかを決定し得る。以下のリスティング３は、CoherenceにおけるサンプルのEventインターフェイスを示す。

さらに図３に示すように、イベント階層３００は、ストレージ・イベントのためのStorageEventインターフェイス３０２を含む。StorageEventインターフェイスは、イベント・インターフェイスから直接的に拡張する。さらに、イベント階層は、異なるタイプのストレージ・イベントのための、StorageCacheEventインターフェイス３０３、StorageEntryEventインターフェイス３０４、StorageInvocationEventインターフェイス３０５、およびStorateTransferEventインターフェイス３０６を含む。

さらに、図３には示されない他のイベントも存在し得る。たとえば、クラスタ内のメンバーシップ（参加したメンバー、離脱したメンバー）に関するイベントであるMemberEvent、クラスタ全体に関するイベントであるClusterEvent、Coherenceトランザクション（開始、コミット、ロードバック）に関するイベントであるTransactionEvent、Coherence Proxy（ロード・バランシング・イベント、プッシュバック・イベント）に関するイベントであるProxyEvent、セキュリティおよび監査に関するイベントであるSecurityEvent、動作を必要とするいくつかの閾値エラーが発生したことを示すイベントであるAbnormalEvent、ならびにストレージ不可能メンバー上で実行されるイベントであるClientSideEventが存在し得る。

ある実施形態に従い、イベント・インスタンスは不変であり得、その寿命は下層システムによって制御され得る。したがって、イベント・クラスの参照は、複数の呼出しにわたって保持され得ない。
イベントのディスパッチ

ある実施形態に従い、イベントのディスパッチには、イベント・インターセプタによる処理のためのイベントの発生と、同じイベントに登録されたイベント・インターセプタが２つ以上ある場合のイベント・インターセプタのチェーンの呼出しとが含まれる。

ある実施形態に従い、イベント・インターセプタはともにチェーンされ得、イベントをディスパッチする役割を果たすスレッドによって逐次呼出され得る。イベントオブジェクトのベース実装は、インターセプタをチェーンするためのすべてのロジックを提供し得、これは次に、指定インターフェイスによって必要とされるイベント・インスタンスの各実装に再使用され得る。イベント・インターセプタは、イベント・インターセプタがイベント・ディスパッチャに追加された順序に基づいて実行され得る。たとえば、Coherenceでは、イベント・インターセプタは、EventDispatcher.addInterceptor()方法で第１のパラメータを介して先頭または末尾に追加され得る。

図４は、本発明の実施形態に係る、分散データグリッド内のサーバ側イベントモデルについてイベントをディスパッチするフローを示す図である。図４に示されるように、イベントをディスパッチするフローは４０１で開始され、４０２において、処理するためのイベントが発生する。イベントをディスパッチするフローは、４０３において、イベントに登録されたイベント・インターセプタのチェーンを呼出すステップを含む。チェーン内のイベント・インターセプタがシステムによってトリガされると、４０４において、イベントをハンドリングするためにonEvent()方法が実行され得る。最後に、イベントをディスパッチするフローは、４０６において、チェーン内のすべてのイベント・インターセプタが呼出されて完了すると終了する。

チェーン内の各イベント・インターセプタは、コンテキストが許可する場合、イベントに関連付けられたデータを任意に修正し得る（たとえばStorageEntryEvent前のINSERTINGおよびUPDATINGイベント）。予めコミットされたストレージ・イベント（たとえばUPDATING、INSERTING、REMOVING）については、イベント・インターセプタは、４０５において例外を投げることによってオペレーションを禁止し得る。

チェーン内の各イベント・インターセプタは、チェーン内で自身の後に実行されるイベント・インターセプタによって生じるすべての副作用の結果を任意に観察し得る。インターセプタ・チェーンが予めコミットされたストレージ・イベントに関連付けられている場合、この結果観察能力は、処理を禁止する第２の機会を提供する。

下流のイベント・インターセプタの副作用の観察は、Event.nextInterceptor()方法によって達成され得る。この方法がリターン（return）すると、すべての下流のイベント・インターセプタが実行されたことを意味し、イベントに関連付けられた状態に対するいずれの変更も観察可能である。

ある実施形態に従い、イベントオブジェクトは、下流の効果の観察をサポートするために、イベント・インスタンスの処理の状態を保持し得る。イベント・インターセプタ自身がEvent.nextInterceptor()を呼出すと、イベント・インターセプタは発火すべきチェーン内の次のイベント・インターセプタをトリガし得、例外を投げることを含む、副作用に対して行動を取るオプションが与えられる。イベント・インターセプタがリターン（return）すると、イベント自身がチェーンのonEvent()方法において次のイベント・インターセプタをトリガし得る。
インターセプタ管理

ある実施形態に従い、イベント・インターセプタは、システム内のどのイベント・ディスパッチャが利用可能であるかを直接的に知らずに、サーバ側イベントモデル・フレームワークに登録され得る。たとえば、システムは、まだインスタンス化されていないイベント・ディスパッチャにイベント・インターセプタが登録されるシナリオをサポートし得る。ユーザが、ensureCache(“cache-foo”)が呼出される前に特定のサービスについてのすべてのストレージ・イベントに関心がある場合、登録されたイベント・インターセプタは、“cache-foo”についてのイベント・ディスパッチャが実現される際にこのディスパッチャに依然として追加される必要があり得る。さらに、システムは、イベント・インターセプタをイベント・ディスパッチャに選択的に登録し得る。また、ディスパッチャの選択基準はイベント・ディスパッチャおよびディスパッチャ実装ごとに異なり得るため、システムは柔軟なカスタマイズ化可能なマッピングをサポートし得る。

ある実施形態に従い、イベント・インターセプタ・レジストリは、システムに登録されたイベント・インターセプタを、システムに登録されたイベント・ディスパッチャにマッピングし得る。イベント・インターセプタ・レジストリは、イベント・ディスパッチャの後のランタイム初期化およびランタイム・イベント・インターセプタ登録をサポートするために、利用可能なイベント・ディスパッチャおよび現在登録されているイベント・インターセプタの両方を追跡し得る。以下のリスティング４は、イベント・インターセプタ・レジストリのサンプルインターフェイスである。

サーバ側イベントモデル・フレームワークは、イベント・インターセプタを異なるイベント・ディスパッチャに柔軟に整合させ得る。フレームワークは、イベント・ディスパッチャが所与のイベント・インターセプタを呼出すべきか否かを判断するために、イベント・インターセプタとイベント・ディスパッチャとの間のハンドシェイクを可能にする。このハンドシェイクは登録期間中に行なわれ得る。

ある実施形態に従い、登録ワークフローは、ディスパッチャの登録およびインターセプタの登録と同様である。主な相違点は、レジストリが登録された１組のインターセプタまたは登録された１組のイベント・ディスパッチャ全体にわたって反復しているか否かである。

図５は、ある実施形態に係る、分散データグリッド内のイベント・インターセプタの登録を示す図である。図５に示されるように、５０２において新たなインターセプタがイベント・インターセプタ・レジストリに登録されると、５０４においてレジストリは登録された各ディスパッチャについてinterceptor.introduceDispatcher(Dispatcher d)を呼出す。そして、イベント・インターセプタは、供給されたディスパッチャからのイベントを自身がリスニングしたいか否かを評価し得る。リスニングしたい場合、５０６において、インターセプタはEventDispatcher.addInterceptor()を呼出すことによって自身をディスパッチャに関連付け得る。

図６は、ある実施形態に係る、分散データグリッド内のイベント・インターセプタの登録を示す図である。図６に示されるように、６０２において新たなディスパッチャが登録されると、６０４においてレジストリは登録された各インターセプタについてinterceptor.introduceDispatcher(Dispatcher d)を呼出す。そして、イベント・インターセプタは、供給されたディスパッチャからのイベントを自身がリスニングしたいか否かを評価し得る。リスニングしたい場合、６０６において、インターセプタはEventDispatcher.addInterceptor()を呼出すことによって自身をディスパッチャに関連付け得る。

サーバ側イベントのプログラム構成をサポートするために、イベント・インターセプタ・レジストリ・インスタンスは、ＪＶＭ内で実行されるCoherenceインスタンス全体に利用可能であるようにされ得る。システム内のどこからもレジストリにアクセスできるため、サーバ側イベントモデルは、ディスパッチャおよびインターセプタがインスタンス化される際にそれらを動的に追加および削除することをサポートするのに十分拡張可能であり得る。Coherenceでは、異なる機能性はregisterResource/unregisterResource APIを介してクラスタに追加され得る。レジストリは、いずれかの他のオブジェクトまたはコンポーネントがレジストリへのアクセスを望む前に、インスタンス化されてクラスタオブジェクトに登録され得る。たとえば、インターセプタ・レジストリは、com.oracle.EventInterceptorRegistryの名前で格納され得る。
Coherenceにおけるサポートクラス

ある実施形態に従い、分散データグリッドは、サーバ側イベントモデルのシンプルなユースケースについて、すぐに使えるサポートクラスを提供し得る。たとえば、Coherenceデータグリッドは、抽象イベント・インターセプタ・クラス、シンプルなデリゲート・イベント・インターセプタ・クラス、シンプルなイベント・ディスパッチャ・クラス、およびマルチスレッド・イベント・ディスパッチャ・クラスを提供する。

抽象イベント・インターセプタ・クラスは、システム内のインターセプタを構築するのに必要な作業を単純化するイベント・インターセプタのためのベース実装を提供し得る。抽象イベント・インターセプタ・クラスは、イベント・タイプと、サービス名と、処理されるイベントの総数、イベントの平均処理時間、およびイベントの最長処理時間を含む基本的なＪＭＸメトリクスとに基づいて、基本的な登録アルゴリズムを提供し得る。

シンプルなデリゲート・イベント・インターセプタ・クラスは、サポートされるイベント・タイプのみに集中することによって、システム内のイベント・インターセプタの登録の際に必要なオーバーヘッドを減少させ得る。シンプルなデリゲート・イベント・インターセプタ・クラスは、抽象イベント・インターセプタ・クラスを拡張し得、イベント・インターセプタと、イベント・インターセプタがリスニングする関心がある任意のサービス名と、イベント・インターセプタがリスニングする関心がある任意のキャッシュ名と、上記インターセプタがリスニングする関心がある１組のイベント・タイプとを用いて構築され得る。

ある実施形態に従い、次にイベント・ディスパッチャは、供給されたインターセプタを所望のイベント・タイプに整合させ得、インプリメンタはシステム内のイベント・ディスパッチャとのハンドシェイクのいずれにも対処する必要がない。

シンプルなイベント・ディスパッチャ・クラスは、１組のインターセプタおよびそれらの順序をタイプによって管理する役割を果たし得る汎用イベント・ディスパッチャである。新たなインターセプタを追加するとインターセプタ・リストの新たなコピーが生成され得るため、現在処理中のどのイベントにも処理の最中に影響が及ばない。さらに、コンポーネントがイベント・タイプをディスパッチしたい場合、シンプルなイベント・ディスパッチャは、適切な１組のインターセプタを取り、インターセプタ・チェーニングフローに基づいてイベントにそれらの処理を開始するよう頼む役割を果たし得る。また、シンプルなイベント・ディスパッチャは、実行順序における名前による登録済インターセプタのリスト、ディスパッチされたイベントの数、イベントのディスパッチに費やされる平均時間、イベントをディスパッチする最長時間、および最長ディスパッチ時間を有するインターセプタなどのＪＭＸ統計について報告する役割を果たし得る。さらに、シンプルなイベント・ディスパッチャ・クラスは、DispatchEventの汎用実装とともにEventDispatcherインターフェイスを実装するcom.tangosol.net.internal.unifiedevents.dispatchersの下で実装され得る。

また、マルチスレッド・イベント・ディスパッチャ・クラスはシンプルなイベント・ディスパッチャ・クラスを拡張し得、余分のスレッドを追加してイベントを非同期に処理し得る。イベントは、内部ワーカー・スレッドによる処理のためにキューに配置され得る。メイン・スレッドがキューに作業を配置する間、ワーカー・スレッドは登録されたインターセプタを実際に呼出す役割を果たす。マルチスレッド・イベント・ディスパッチャは、メイン・スレッドについてのイベントのディスパッチ、およびワーカー・スレッドについてのイベントのディスパッチの両方を可能にするＡＰＩを提供し得る。
サーバ側イベントモデルの構成

ある実施形態に従い、サーバ側イベントモデルはプログラム的に構成され得る。たとえば、Coherenceでは、イベント・インターセプタ・レジストリは、Cluster.getResource(“com.oracle.EventInterceptorRegistry”)を呼出すことによってクラスタから抽出され得る。さらに、イベント・インターセプタは、EventInterceptorRegistry.registerInterceptor(“InterceptorName”、新たなEventInterceptor())を呼出すことによってイベント・インターセプタ・レジストリに登録され得る。

別の実施形態に従い、サーバ側イベントモデルは、キャッシュ構成ファイル内で宣言的に構成され得る。以下のリスティング６は、インターセプタ構成を有するサンプルキャッシュ構成である。

上記に示されるように、Coherenceの名前空間ハンドラは、キャッシュ構成ファイル内の新たなｘｍｌ要素をサポートするように拡張され得る。１つのｘｍｌ要素は、システム内に登録される１組のすべてのインターセプタを定義する任意の<event-interceptors>要素であり得る。別のｘｍｌ要素は、イベント・インターセプタのインスタンスを定義する任意の<interceptor>要素であり得る。

<interceptor>要素は、インターセプタの名前を定義する<name>属性と、EventInterceptorを実装するクラスの名前を定義する<class-scheme>属性と、<service-name>、<cache-name>、および<events>に関連付けられているいずれかのディスパッチャをインターセプタがフィルタリングするかの宣言的な方法を定義する<dispatcher-filter>属性とを含み得る。<service-name>属性は、登録するために整合する必要のあるサービスの名前を定義する。<cache-name>属性は、登録するために整合する必要のあるキャッシュの名前を定義する。<events>属性は、インターセプタが登録することを望むイベントのリストを定義する。<event-type>属性は、登録すべきイベント・インスタンスを定義する。<event-type>属性は、<class-scheme>属性および<events>属性に対して登録すべきイベント・インスタンスを定義する。<class-scheme>属性は、com.tangosol.coherence.unifiedevents.StorageEntryEventなどの使用すべきサーバ側イベント・クラスを定義し、<events>属性は、登録すべきイベント名のリストを定義する。
オフロードイベントおよびサポート継続

ある実施形態に従い、エンドユーザコードがクラスタ・メンバーを停止させたりストールすることを防止するために、サーバ側イベントモデルは、可能ならいつでも、分散データグリッド内のパーティションサービスに関連付けられたサービス・スレッドのブロッキングを回避する。サービス・スレッドは、すべての受信要求をハンドリングし、かつそれらの実行を調整する役割を果たすからである。こうして、サーバ側イベントモデルは分散データグリッドの性能を改良し得る。

Coherenceの例では、$Service上のイベント・ディスパッチャ処理は、ほとんどのサーバ側イベントメッセージをハンドリングする役割を果たすスレッドとして用いられ得る。イベント・ディスパッチャ処理は、サーバ側で実行されると明示的に宣言される場合以外はクライアント側でハンドリングされるマップ・リスナーの形態のエンドユーザコードを典型的に実行する、ガードされたキューベースのプロセッサである。比較的小さい１組の機能がサーバ側で消費されるため、このスレッドはサーバ側イベントモデルの理想的な候補である。また、イベント・ディスパッチャは必要な保護でガードされる。さらに、イベント・ディスパッチャ処理は、キーによって順番にイベントを処理する単一のスレッド・キュー・プロセッサであり得る。順序付けが保証されるように、イベントのハンドリングは単一のスレッド上で行なわれ得る。

図７は、分散データグリッド内の継続のサポートを示す図である。図７に示されるように、サービス・スレッド７０１上の継続を要求する方法は、イベント前段階７０２およびイベント後段階７０４の２段階に分けることができる。イベント前段階は、必要なイベントが処理のためにワーカー・スレッド７１０にディスパッチされると終了する。イベント・ディスパッチャがイベントハンドリング７０６を完了すると、ワーカー・スレッドがサービス・スレッドに応答メッセージをポストバックすることによって、要求処理がイベント後段階で継続される。換言すれば、イベントがハンドリングされたという応答がポストバックされるとイベント後段階が継続する。

ある実施形態に従い、継続サポートは、イベント・ディスパッチャ・スレッドにイベントをポストすることによって達成され得る。たとえば、パーティション転送イベントが継続をサポートし得る。特定のエントリに対する修正とは異なり、パーティション転送は、ユーザが継続に対処する際に同一のスレッド（サービス・スレッド）から１組のパーティションを確実にロックおよびロック解除できるようにするために、サービス・スレッド上で実行可能である。さらに、パーティション転送イベントによってインターセプタがパーティション全体にわたって反復する可能性が高いことを考えると、パーティション転送ロジックは、それが長期間にわたってブロックされることを防止するために、サービス・スレッド上で実行されなくてもよい。

ある実施形態に従い、コミット後のイベントは、これらが提供されるエントリが不変であるため、分散データグリッド内部の要求処理のフローを中断する能力を有しない。１つの要件は、コミット後のイベントがキーによって順番に実行されることであり、これは、イベントハンドリングをワーカー・スレッドからイベント・ディスパッチャ・スレッドにオフロードして進むことによって単純に達成され得る。この場合も、Coherenceでは、イベントハンドリングのオフロードは、イベントオブジェクトをイベント・ディスパッチャ・スレッドにポストすることによって達成され得る。

ある実施形態に従い、イベント・ディスパッチャ上にディスパッチされるすべてのイベントがイベント・ディスパッチャ・キューに配置され得る。Coherenceでは、イベント・ディスパッチャは、典型的にSerice$DispatchEventオブジェクトであるRunnableを実行する。DispatchUEMEventオブジェクトは、公的にディスパッチされる必要のあるUEMEventオブジェクト、およびイベントをディスパッチするUEMEventDispatcherオブジェクトへの参照を含む、PartitionedCache上の専用のService$DispatchEvent子コンポーネントであり得る。

リスティング７において以下に示されるように、DispatchUEMEventオブジェクトは、必要とされる特定のリターンまたは継続をハンドリングする役割を果たす子オブジェクトを有し得る。必要な情報は、多様性に基づいてイベントがディスパッチされたあとにカプセル化され得る。

特定のDispatchUEMEventインスタンスの実行が終了すると、ワーカー・スレッドからの応答がサービス・スレッドにポストバックされ得る。データパーティション転送をサポートする例では、基本的なPartitionedCache$Acknowledgementコンポーネントを拡張する２つの応答メッセージ、すなわちPostDepartedメッセージおよびPostArrivedメッセージがあり得る。DispatchTransferDepartingコンポーネントのrunAfter方法は、PostDepartedメッセージをサービス・スレッドにポストバックする役割を果たし得る。DispatchTransferDepartingコンポーネントは、DispatchUEMEventを拡張し、StorageTransferEvent.DEPARTINGイベントをCoherence EventDispatcherスレッド上のUEMEventDispatcherに発生させる役割を果たす。さらに、DispatchTransferArrivedコンポーネントのrunAfter方法は、PostArrivedメッセージをサービス・スレッドにポストバックする役割を果たし得る。DispatchTransferArrivedコンポーネントはさらにDispatchUEMEventを拡張し、StorageTransferEvent.ARRIVEDイベントをCoherence EventDispatcherスレッド上のUEMEventDispatcherに発生させる役割を果たす。

本開示に記載されるさまざまな文脈の全体にわたって、本発明の実施形態は、上述のシステムおよび方法を実行するように構成されたコンピュータ装置、演算システムおよび機械読取可能媒体をさらに含む。特別に設計された集積回路または他の電子機器からなる実施形態に加えて、本発明は本開示の教示に従ってプログラムされた汎用または専用デジタルコンピュータまたはマイクロプロセッサを用いて便利に実現され得、これはコンピュータ技術の当業者にとって明らかになるであろう。

本開示の教示に基づいて適切なソフトウェアコーディングが熟練のプログラマによって作成され得、これはソフトウェア技術の当業者にとって明らかになるであろう。本発明は特定用途向け集積回路を作成することによって、または従来のコンポーネント回路の適切なネットワークを相互接続することによっても実現され得、これは当業者にとって明らかになるであろう。

さまざまな実施形態は、本明細書中に提示された特徴のいずれかを実行するように（１つまたは複数の）汎用または専用の演算プロセッサ／装置をプログラムするために使用できる命令が格納された（１つまたは複数の）記憶媒体であるコンピュータプログラム製品を含む。記憶媒体は、フロッピーディスク（登録商標）、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、光磁気ディスク、ホログラフィック記憶装置、ＲＯＭ、ＲＡＭ、ＰＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気または光カード、ナノシステム（分子メモリＩＣを含む）を含む任意の種類の物理的媒体、紙または紙ベースの媒体、ならびに命令および／または情報を記憶するのに適した任意の種類の媒体またはデバイスを含み得るが、これらに限定されない。コンピュータプログラム製品は全体的または部分的に、１つ以上の公的および／または私的ネットワーク上で送信可能であり、当該送信は、本明細書中に提示された特徴のいずれかを実行するための１つ以上のプロセッサによって使用できる命令を含む。当該送信は複数の別個の送信を含み得る。しかし、ある一定の実施形態に従って、命令を含むコンピュータ記憶媒体は、一時的ではなく（すなわち、送信処理中でなく）、むしろ物理的デバイス上に持続される。

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

Claims

分散データグリッド内のサーバ側イベントモデルを提供するためのシステムであって、
イベント・ディスパッチャを備え、前記イベント・ディスパッチャは、前記分散データグリッド内のオペレーションに関連付けられる少なくとも１つのイベントをディスパッチするように動作し、前記システムはさらに、
１つ以上のイベント・インターセプタを備え、前記１つ以上のイベント・インターセプタは前記イベント・ディスパッチャにマッピングされ、前記１つ以上のイベント・インターセプタは、前記イベント・ディスパッチャから前記１つ以上のイベント・インターセプタにディスパッチされる前記少なくとも１つのイベントをハンドリングするように動作し、
前記分散データグリッドは、前記１つ以上のイベント・インターセプタによる前記少なくとも１つのイベントのハンドリングが完了するまで、前記分散データグリッド内の前記オペレーションの完了を遅らせ、
前記１つ以上のイベント・インターセプタは、同じイベントに登録されている場合に互いにリンクされる、システム。
前記イベント・インターセプタは、当該イベント・インターセプタが含まれるインターセプタ・チェインがストレージイベントに関連付けられている場合に、要求された処理のコミットを禁止する、請求項１に記載のシステム。
分散データグリッド内のサーバ側イベントモデルを提供するためのシステムであって、
イベント・ディスパッチャを備え、前記イベント・ディスパッチャは、前記分散データグリッド内のオペレーションに関連付けられる少なくとも１つのイベントをディスパッチするように動作し、前記システムはさらに、
１つ以上のイベント・インターセプタを備え、前記１つ以上のイベント・インターセプタは前記イベント・ディスパッチャにマッピングされ、前記１つ以上のイベント・インターセプタは、前記イベント・ディスパッチャから前記１つ以上のイベント・インターセプタにディスパッチされる前記少なくとも１つのイベントをハンドリングするように動作し、
前記分散データグリッドは、前記１つ以上のイベント・インターセプタによる前記少なくとも１つのイベントのハンドリングが完了するまで、前記分散データグリッド内の前記オペレーションの完了を遅らせ、
前記イベント・インターセプタは、当該イベント・インターセプタが含まれるインターセプタチェーンがストレージイベントに関連付けられている場合に、要求された処理のコミットを禁止する、システム。
前記分散データグリッドは、イベント・ディスパッチャ処理にイベントをポストすることによって、前記イベント・ディスパッチャと、前記イベント・ディスパッチャによってディスパッチされるイベントをハンドリングするサービス・スレッドとの間で、イベント処理の継続性をサポートする、請求項１から３のいずれかに記載のシステム。
分散データグリッド内のサーバ側イベントモデルを提供するためのシステムであって、
イベント・ディスパッチャを備え、前記イベント・ディスパッチャは、前記分散データグリッド内のオペレーションに関連付けられる少なくとも１つのイベントをディスパッチするように動作し、前記システムはさらに、
１つ以上のイベント・インターセプタを備え、前記１つ以上のイベント・インターセプタは前記イベント・ディスパッチャにマッピングされ、前記１つ以上のイベント・インターセプタは、前記イベント・ディスパッチャから前記１つ以上のイベント・インターセプタにディスパッチされる前記少なくとも１つのイベントをハンドリングするように動作し、
前記分散データグリッドは、前記１つ以上のイベント・インターセプタによる前記少なくとも１つのイベントのハンドリングが完了するまで、前記分散データグリッド内の前記オペレーションの完了を遅らせ、
前記分散データグリッドは、イベント・ディスパッチャ処理にイベントをポストすることによって、前記イベント・ディスパッチャと、前記イベント・ディスパッチャによってディスパッチされるイベントをハンドリングするサービス・スレッドとの間で、イベント処理の継続性をサポートする、システム。
前記分散データグリッドに関連付けられるレジストリをさらに備え、前記１つ以上のイベント・インターセプタは前記レジストリに登録される、請求項１〜５のいずれかに記載のシステム。
前記少なくとも１つのイベントはイベント階層において定義される、請求項１〜６のいずれかに記載のシステム。
エンドユーザがイベントをハンドリングするためにカスタマイズされたロジックを実装することを可能にするインターフェイスをさらに備える、請求項１〜７のいずれかに記載のシステム。
前記イベント・ディスパッチャは、前記１つ以上のイベント・インターセプタを、それらが登録されているイベントに対してトリガする、請求項１〜８のいずれかに記載のシステム。
前記１つ以上のイベント・インターセプタは、それらが前記イベント・ディスパッチャにマッピングされる順序で実行される、請求項１〜９のいずれかに記載のシステム。
前記分散データグリッド内のパーティションサービスに関連付けられたサービス・スレッドは、すべての受信要求をハンドリングし、かつそれらの実行を調整する役割を果たす、請求項１〜１０のいずれかに記載のシステム。
分散データグリッド内のサーバ側イベントモデルを提供するための方法であって、
１つ以上のイベント・インターセプタをイベント・ディスパッチャにマッピングするステップを備え、前記イベント・ディスパッチャは、前記分散データグリッド内のオペレーションに関連付けられる少なくとも１つのイベントをディスパッチするように動作し、前記方法はさらに、
前記１つ以上のイベント・インターセプタを介して、前記イベント・ディスパッチャから前記１つ以上のイベント・インターセプタにディスパッチされる前記少なくとも１つのイベントをハンドリングするステップと、
前記１つ以上のイベント・インターセプタによる前記少なくとも１つのイベントのハンドリングが完了するまで、前記分散データグリッド内の前記オペレーションの完了を遅らせるステップとを備え、
前記１つ以上のイベント・インターセプタは、同じイベントに登録されている場合に互いにリンクされる、方法。
分散データグリッド内のサーバ側イベントモデルを提供するための方法であって、
１つ以上のイベント・インターセプタをイベント・ディスパッチャにマッピングするステップを備え、前記イベント・ディスパッチャは、前記分散データグリッド内のオペレーションに関連付けられる少なくとも１つのイベントをディスパッチするように動作し、前記方法はさらに、
前記１つ以上のイベント・インターセプタを介して、前記イベント・ディスパッチャから前記１つ以上のイベント・インターセプタにディスパッチされる前記少なくとも１つのイベントをハンドリングするステップと、
前記１つ以上のイベント・インターセプタによる前記少なくとも１つのイベントのハンドリングが完了するまで、前記分散データグリッド内の前記オペレーションの完了を遅らせるステップと、
当該イベント・インターセプタが含まれるインターセプタチェーンが予めコミットされたストレージイベントに関連付けられている場合に、要求された処理のコミットを中止するステップとを備える、方法。
分散データグリッド内のサーバ側イベントモデルを提供するための方法であって、
１つ以上のイベント・インターセプタをイベント・ディスパッチャにマッピングするステップを備え、前記イベント・ディスパッチャは、前記分散データグリッド内のオペレーションに関連付けられる少なくとも１つのイベントをディスパッチするように動作し、前記方法はさらに、
前記１つ以上のイベント・インターセプタを介して、前記イベント・ディスパッチャから前記１つ以上のイベント・インターセプタにディスパッチされる前記少なくとも１つのイベントをハンドリングするステップと、
前記１つ以上のイベント・インターセプタによる前記少なくとも１つのイベントのハンドリングが完了するまで、前記分散データグリッド内の前記オペレーションの完了を遅らせるステップとを備え、
前記分散データグリッドは、イベント・ディスパッチャ処理にイベントをポストすることによって、前記イベント・ディスパッチャと、前記イベント・ディスパッチャによってディスパッチされるイベントをハンドリングするサービス・スレッドとの間で、イベント処理の継続性をサポートする、方法。
請求項１２〜１４のいずれかに記載の方法をコンピュータに実行させるための、コンピュータプログラム。