ヘッダーをスキップ
Oracle Coherence開発者ガイド
リリース3.5
B56039-01
  目次
目次
戻る
戻る 		 次へ
次へ		  

3 連続問合せの実行

Coherenceキャッシュからポイント・イン・タイムの問合せ結果を取得でき、その問合せ結果を変更するイベントを受信可能な場合、Coherenceでは、問合せ結果と連続的な関連するイベント・ストリームとを組み合せて、問合せ結果をリアルタイムに維持できます。目的の問合せの待機時間が0である場合と同じ効果を持ち、問合せがミリ秒ごとに数回繰り返されるため、この機能は連続問合せと呼ばれています。ポイント・イン・タイムの問合せ結果およびイベントの詳細は、第6章「キャッシュの問合せ」および「変更発生時のイベントの配信」を参照してください。

Coherenceでは、問合せの結果を連続問合せキャッシュにマテリアライズし、問合せでイベント・リスナーを使用してリアルタイムでキャッシュを最新の状態に保つことにより、連続問合せ機能を実装します。つまり、Coherenceの連続問合せは、決して古くなることのない、キャッシュされた問合せ結果になります。

連続問合せキャッシュの用途

連続問合せキャッシュには、次のような一般用途のカテゴリがあります。

使用例の1つは取引システムのデスクトップです。このデスクトップでは、トレーダーの未決済のオーダーおよびすべての関連情報を常に最新の状態で保持しておく必要があります。Coherence*Extend機能を連続問合せキャッシュと組み合せることにより、1つのアプリケーションで実際に何万人もの同時ユーザーをサポートできます。


注意:

連続問合せキャッシュは、クライアントベースやサーバーベースのアプリケーションを含む、ほとんどのアプリケーション・タイプで使用可能です。連続問合せキャッシュでは、より大規模で分散されているキャッシュ・データ・セットで、その指定したサブセットの最新ローカル・コピーを非常に簡単かつ効率的に保持できるためです。

Coherenceの連続問合せキャッシュ

Coherenceの連続問合せの実装は、com.tangosol.net.cache.ContinuousQueryCacheクラスにあります。このクラスは、Coherenceのすべてのキャッシュと同様に、標準的なNamedCacheインタフェースを実装していますが、これには次の機能が含まれます。

ContinuousQueryCacheは、Coherenceのすべてのキャッシュと同様にNamedCache APIインタフェースを実装します。これは、使用方法が簡単で、必要に応じて別のキャッシュの代替機能として利用できます。

連続問合せキャッシュの構成

連続問合せキャッシュは、次の2つの項目で定義されます。

  1. 基礎となるキャッシュ

  2. 連続問合せキャッシュでキャッシュされるサブセットを構成する、基礎となるキャッシュの問合せ

基礎となるキャッシュは、別の連続問合せキャッシュを含む、任意のCoherenceキャッシュです。キャッシュは通常、CacheFactoryから取得します。これにより、開発者がキャッシュの名前を指定するだけで、アプリケーションのキャッシュ・コンフィギュレーション情報に基づいてキャッシュが自動的に構成されます。次に例を示します。

NamedCache cache = CacheFactory.getCache("orders");

キャッシュ・コンフィギュレーション情報の指定方法の詳細は、付録D「キャッシュ・コンフィギュレーションの要素」を参照してください。

この問合せは、次の用途で使用される問合せと同じタイプになります。

例3-1 連続問合せキャッシュの問合せ

Filter filter = new AndFilter(new EqualsFilter("getTrader", traderid),
                              new EqualsFilter("getStatus", Status.OPEN));

問合せの詳細は、第6章「キャッシュの問合せ」を参照してください。

通常、キャッシュを問い合せるには、QueryMapのいずれかのメソッドを使用します。たとえば、このトレーダーのすべてのオープンなトレードのスナップショットを取得するには、次のメソッドを使用します。

例3-2 連続問合せキャッシュのデータの取得

Set setOpenTrades = cache.entrySet(filter);

同様に、連続問合せキャッシュは次の2つの部分から構成されます。

例3-3 連続問合せキャッシュの構成

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter);

ContinuousQueryCacheに関連付けられているリソースのクリーンアップ

連続問合せキャッシュでは、基礎となるキャッシュに1つ以上のイベント・リスナーが配置されます。連続問合せキャッシュをアプリケーションの稼働中に使用する場合は、ノードがシャットダウンした場合やその他の理由で停止したときに、リソースがクリーンアップされます。ただし、連続問合せキャッシュを一定の期間のみ使用する場合は、アプリケーションによる連続問合せキャッシュの使用が終了した時点で、ContinuousQueryCacheでrelease()メソッドがコールされる必要があります。

キーのみのキャッシュまたはキーと値のキャッシュ

連続問合せキャッシュを構成するときに、キャッシュが問合せ結果のキーのみを追跡し、リクエストがあった場合にのみ基礎となるキャッシュから値を取得するように指定することができます。この機能は、非常に大きな問合せ結果セットを示す連続問合せキャッシュを作成する場合や、値がまったく、またはほとんどリクエストされない場合に便利です。キーのみをキャッシュするように指定するには、CacheValuesプロパティを構成できるコンストラクタを使用します。次に例を示します。

例3-4 CacheValuesプロパティを構成できるコンストラクタ

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter, false);

必要に応じて、CacheValuesプロパティはキャッシュがインスタンス化された後で変更することもできます。

例3-5 CacheValuesプロパティの設定

cacheOpenTrades.setCacheValues(true);

CacheValuesプロパティとイベント・リスナー

連続問合せキャッシュに標準的な（軽量でない）イベント・リスナーがある場合や、いずれかのイベント・リスナーがフィルタリングされている場合、CacheValuesプロパティは自動的にtrueに設定されます。これは、連続問合せキャッシュがローカルでキャッシュされた値を使用してイベントをフィルタリングし、発生させるイベントの新旧の値を提供するからです。

ContinuousQueryCacheのリスニング

連続問合せキャッシュは、それ自体が監視可能であるため、クライアントが1つ以上のイベント・リスナーを配置することができます。次に例を示します。

例3-6 連続問合せキャッシュへのリスナーの追加

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter);
cacheOpenTrades.addMapListener(listener);

キャッシュ内に存在するすべての項目、およびキャッシュに追加されるすべての項目に対してなんらかの処理を行う必要がある場合、次の2つの段階があります。まず、処理を行えるようにします。次に、リスナーを追加して、後から追加された項目を処理できるようにします。

例3-7 連続問合せキャッシュ・エントリの処理とリスナーの追加

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter);
for (Iterator iter = cacheOpenTrades.entrySet().iterator(); iter.hasNext(); )
    {
    Map.Entry entry = (Map.Entry) iter.next();
    // .. process the cache entry
    }
cacheOpenTrades.addMapListener(listener);

ただし、反復後、リスナーが追加される前のほんの一瞬に発生するイベントが見落とされるため、このコードは正しくありません。かわりに、イベントの見落しがないように、まずリスナーを追加してから処理を行います。

例3-8 リスナー追加後の連続問合せキャッシュ・エントリの処理

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter);
cacheOpenTrades.addMapListener(listener);
for (Iterator iter = cacheOpenTrades.entrySet().iterator(); iter.hasNext(); )
    {
    Map.Entry entry = (Map.Entry) iter.next();
    // .. process the cache entry
    }

ただし、同じエントリがイベント内とIterator内の両方に出現し、イベントが非同期になる可能性があるため、操作の順序が正しいことは保証できません。

解決策は、構成時にリスナーを指定することです。そうすることで、既存の（問合せに含まれていた）項目であるか、キャッシュの構成時または構成後に追加された項目かどうかに関係なく、連続問合せキャッシュ内の項目ごとにイベントが1つずつリスナーに送信されます。

例3-9 連続問合せキャッシュ構成時のリスナーの指定

ContinuousQueryCache cacheOpenTrades = new ContinuousQueryCache(cache, filter, listener);

安定したマテリアライズド・ビューの実現

ContinuousQueryCache実装にも同じ課題がありました。同じキャッシュから変更イベントのストリームを受信しながら、基礎となるキャッシュの正確なポイント・イン・タイム・スナップショットをいかにアセンブルするかということです。この解決策には複数の関係要素があります。まず、Coherenceでは同期イベントのオプションがサポートされており、これによって順序付けが保証されます。このオプションの詳細は、「変更発生時のイベントの配信」を参照してください。

また、ContinuousQueryCacheには初期移入の2フェーズ実装があります。これにより、基礎となるキャッシュを問い合せてから、第1フェーズで発生したすべてのイベントを解決することができます。イベントの見落しや反復なしでデータの可視性を保証することはかなり困難であるため、ContinuousQueryCacheでは、開発者が構成時にリスナーを渡すことができます。これにより、アプリケーション開発者は同様の複雑な作業をする必要はありません。

同期および非同期リスナーのサポート

デフォルトでは、ContinuousQueryCacheのリスナーにはイベントが非同期で配信されます。ただし、ContinuousQueryCacheでは、SynchronousListenerインタフェースで提供されている同期イベントのオプションにも対応しています。このオプションの詳細は、「変更発生時のイベントの配信」を参照してください。

ContinuousQueryCacheを読取り専用にする設定

ContinuousQueryCacheは、次のように読取り専用キャッシュにすることができます。

例3-10 ContinuousQueryCacheを読取り専用にする設定

cacheOpenTrades.setReadOnly(true);

読取り専用のContinuousQueryCacheでは、キャッシュ内でのオブジェクトの追加、変更、削除またはロックができません。

読取り専用に設定したContinuousQueryCacheを、読取り/書込みに戻すことはできません。

  戻る
戻る 		 次へ
次へ
  目次
目次