|Developing with Pivotal GemFire / Continuous Querying|
Clients subscribe to server-side events by using SQL-type query filtering. The server sends all events that modify the query results. CQ event delivery uses the client/server subscription framework.
SELECT * FROM /tradeOrder t WHERE t.price > 100.00When the CQ is running, the server sends the client all new events that affect the results of the query. On the client side, listeners programmed by you receive and process incoming events. For this example query on /tradeOrder, you might program a listener to push events to a GUI where higher-priced orders are displayed. CQ event delivery uses the client/server subscription framework.
Your clients can execute any number of CQs, with each CQ assigned any number of listeners.
CQs do not update the client region. This is in contrast to other server-to-client messaging like the updates sent to satisfy interest registration and responses to get requests from the client's Pool. CQs serve as notification tools for the CQ listeners, which can be programmed in any way your application requires.
When a CQ is running against a server region, each entry event is evaluated against the CQ query by the thread that updates the server cache. If either the old or the new entry value satisfies the query, the thread puts a CqEvent in the client's queue. The CqEvent contains information from the original cache event plus information specific to the CQ's execution. Once received by the client, the CqEvent is passed to the onEvent method of all CqListeners defined for the CQ.
CQ events do not change your client cache. They are provided as an event service only. This allows you to have any collection of CQs without storing large amounts of data in your regions. If you need to persist information from CQ events, program your listener to store the information where it makes the most sense for your application.
Region operations do not translate to specific query operations and query operations do not specifically describe region events. Instead, the query operation describes how the region event affects the query results.
|Query operations based on old and new entry values||New value does not satisfy the query||New value satisfies the query|
|Old value does not satisfy the query||no event||CREATE query operation|
|Old value does satisfies the query||DESTROY query operation||UPDATE query operation|
You can use the query operation to decide what to do with the CqEvent in your listeners. For example, a CqListener that displays query results on screen might stop displaying the entry, start displaying the entry, or update the entry display depending on the query operation.
The region <region name> specified in CQ creation is neither replicated nor partitioned; only replicated or partitioned regions are allowed in CQ creation.In addition, you cannot create a CQ on a replicated region with eviction setting of local-destroy since this eviction setting changes the region's data policy. If you attempt to create a CQ on this kind of region, you will receive the following error message:
CQ is not supported for replicated region: <region name> with eviction action: LOCAL_DESTROYSee alsoConfigure Distributed, Replicated, and Preloaded Regions for potential issues with setting local-destroy eviction on replicated regions.