GemStone Systems has announced a 30-day evaluation program for GemFire Real-Time Events (RTE), a distributed main-memory event processing and analytics solution based on continuous querying. Unlike a traditional relational database where applications execute queries on static data, GemFire RTE enables Java/J2EE applications to continuously process and analyze events, delivering a real-time view of critical data without the need to re-execute queries. C++ and C# applications can also plug into GemFire RTE via a standard adapter provided by GemStone. GemFire RTE provides an in-memory relational data store that allows clients to register SQL-92 queries via JDBC. With any event/data update, RTE automatically evaluates queries that have been impacted, regenerates a new view for those queries and delivers updated result-sets or "row deltas" to distributed client applications. As deltas are pushed from RTE to client applications, RTE invokes client API callbacks with the set of row deltas as arguments, enabling users to build code that handles exact deltas to the JDBC results set. The continuous query (CQ) functionality allows users to obtain new, updated results from the in-memory database without having to issue the same query repeatedly. RTE offers a client-programming model involving a JDBC-compatible driver along with a simple extension to receive "delta" events on cached result sets from servers. GemFire RTE's continuous querying technology works through an engine that groups and filters predicates from large numbers of queries, enabling the following to occur:

• When the server first receives a continuous query, it not only replies with an initial result set, but it analyzes the query predicates (selection criteria) in order to logically group it with other similar queries.
• The engine can then quickly identify what continuous queries are affected by any given data modification (an insert, update or delete against the relationally structured operational data).
• The engine can send only the deltas to each CQ client needed to update its existing result set, in effect exactly the data necessary for the client to hold a materialized view of data from the server.

GemFire, the Enterprise Data Fabric (EDF), provides a scalable, distributed platform to manage increasing volumes of enterprise data and streaming events with little latency. The GemFire product suite includes GemFire Enterprise, GemFire Enterprise - C++ and GemFire Real-Time Events.

What is the effort to retrofit an existing JDBC aplication with a large number of users? Is there any replication or clustering involved?

For many applications, the JDBC client can simply switch to using the RTE JDBC driver instead of the previous one and will continue to work as before (it will only be doing RTE "ad-hoc" queries). To take advantage of the Continuous Query capabilities, you implement our CQCallback interface to receive notifications of changes (deltas) to your underlying JDBC ResultSet. The callback arguments give you everything you need to performs functions like updating a GUI or driving some analysis component that depends on moving data. Thus implemented, GUI end-users simply see the data update as if they had pressed their "refresh" button--but without database overhead! The ease of an RTE retrofit depends on a couple of key factors, but it is generally quite easy to realize a significant benefit over alternative approaches. One factor is that RTE supports SQL-92 and many parts of SQL-99, so consider the degree to which your existing SQL is compliant with these standards (or how easy it would be to re-factor the SQL for the same). Another factor is how much reliance you have on stored-procedure code. RTE supports Java stored procedures, but a system with extensive logic in RDBMS SP's would require additional migration work. Note that RTE can also be configured to write-though or write-behind to existing RDB's, so existing SP logic that isn't tied to immediate client application feedback could still fire and may be ok as-is. RTE supports clustering and in-memory replication both for scalability and high-availability. Client applications can be configured to connect to multiple RTE instances for easy load balancing and transparent failover. Instances of RTE may also be added dynamically to increase capacity without system shutdown. Cheers, Gideon GemFire--The Enterprise Data Fabric

This sounds similar to the Continuous Query capabilities in Coherence: http://wiki.tangosol.com/display/COH32UG/Continuous+Query It's too bad that JDBC didn't support two-way communications, e.g. events, or this type of functionality could have been truly drop-in. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

This sounds similar to the Continuous Query capabilities in Coherence:

http://wiki.tangosol.com/display/COH32UG/Continuous+Query

It's too bad that JDBC didn't support two-way communications, e.g. events, or this type of functionality could have been truly drop-in.

Peace,

Cameron Purdy
Tangosol Coherence: The Java Data Grid

If I am not mistaken, Coherence added this feature in Feb 2006, right? We have had this in *production* at a large investment management firm since early 2005.

If I am not mistaken, Coherence added this feature in Feb 2006, right?

Judging by our download logs, you would know better than I. ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid