Pivotal GemFire のオープンソース版としてリリースされた Apache Geode ですが、GemFire と違い、Continuous Query（CQ）がサポートされていません*1。
＃ソースコードみる限り、Geode で CQ 使おうとすると、IllegalStateException がスローされて、"CqService is not available." と怒られる風の実装になっている。
CQ は、あらかじめ SQL ライクな OQL の select 文をサーバー側に設定しておけば、その select 文の条件に合致するデータに更新があった場合に、クライアントが当該データ更新内容をイベントとして受信する的な機能。例えば、金融業界だと、サーバー側に各銘柄の株価データを保持しておき、OQL の select 文で設定しておいた株価上昇とか下落があればそれをイベントとしてクライアントに通達、クライアント側でそれに基づいて株価の売買を行ったりとかという処理に使えるといったイメージ。
これ風のことを Geode で何とかできないかと思い、まずはその１として、クライアント側の CacheListener での実装アイディアを考えてみました。以下、サンプルのソースコードと cache.xml ファイルを添付します。
- サンプルソースコード： MyCQClient.java
- クライアント cache.xml： client-cache.xml
サーバーは、添付 cache.xml と同じ名前のリージョンを適当に作っておきます。あと、ロケーターホストとかポートとか、cache.xml の配置場所とか環境に合わせて適当に変更してやります。
実際の CQ と違うのは、とりあえずデータ更新イベントは全て受け取っていることと、それで駆動された CacheListener で OQL の select 文を実行し条件に合致しているかどうか判断しているところです。クライアントコードで生成したクライアントリージョンを CacheListener コードから参照するので、両コードを合体させて、static 初期化子でリージョン生成と select 文の初期化を行うというベタな実装です。で、実際受け取ったイベントのデータと select 文の実行結果を比較して条件合致したら、標準出力に "This event is matched with the given CQ:..." みたいなメッセージが出力されるというだけのものです。
メリットとしては、クライアントサイドの実装で閉じることができコード変更による影響度が小さくて、実装が簡単であること。デメリットとしては、とりあえず全てのイベントを受信するので、選択的に受信する実際の CQ よりも効率が良くない（サーバーからの、select 文に合致しないイベント送信でネットワークトラフィックが増加する）ことですかね…（ま、あらかじめ registerInterest で受信するイベントをある程度絞っておくことは可能ですが）。
気が向いたらそのうち、その２として、サーバーサイド CQ というか、実際の CQ に近いものを考察してみたいと思います。
*1:2017 年現在は、Apache Geode で CQ はサポートされています
