<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 29, 2009, at 12:24 PM, Manik Surtani wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On 29 Sep 2009, at 10:19, Mircea Markus wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Sep 29, 2009, at 12:08 PM, Manik Surtani wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On 29 Sep 2009, at 09:57, Mircea Markus wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Again, this is a feature from Coherence[1].<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Basic idea is to execute a query against the cache, and hold the <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">result object. This result object will always have up to date <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">query result; this means that whenever something is modified in <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the cache the result itself is updated. Advantage: if one performs <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the same query very often(e.g. several times every millisecond) <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the response will be fast and the system will not be overloaded.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Is it really faster? Surely all you save is the construction of <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the various query objects, but the query itself would have to be re- <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">run every time. Or does it attach a listener to the cache and <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">check whether any new additions/removals should be used to update <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the result set?<br></blockquote></blockquote><blockquote type="cite">this is the way it works. It is a sort of a near-cache, just that <br></blockquote><blockquote type="cite">instead of being invalidated it is updated whenever the cache is <br></blockquote><blockquote type="cite">updated. The documentation also suggests that they are using <br></blockquote><blockquote type="cite">listeners.<br></blockquote><blockquote type="cite"><blockquote type="cite"> I don't see how that could be much faster though.<br></blockquote></blockquote><blockquote type="cite">I think it might be if the you are running *the same query* tons of <br></blockquote><blockquote type="cite">times. Basically you don't do a map-reduce on all the nodes, but <br></blockquote><blockquote type="cite">rather on every insertion (especially if the number of insertion is <br></blockquote><blockquote type="cite">relative small compared to the number of same-query-bring-run) you <br></blockquote><blockquote type="cite">updated (if necessary) the cached query result.<br></blockquote><br>Hmm. It would be pretty use-case-specific. </div></blockquote>I think there are many usecases for this(from coherence doc):</div><div><li><p>It is an ideal building block for Complex Event Processing (CEP) systems and event correlation engines.</p>
</li>
<li><p>It is ideal for situations in which an application repeats a
particular query, and would benefit from always having instant access
to the up-to-date result of that query.</p>
</li>
<li><p>A Continuous Query Cache is analogous to a <span class="italic">materialized view</span>,
and is useful for accessing and manipulating the results of a query
using the standard NamedCache API, and receiving an ongoing stream of
events related to that query.</p></li><blockquote type="cite"><div>It's hard to see how this <br>_generally_ performs better, since you need to make sure you are aware <br>of all changes happening all over the cluster to keep this result set <br>up to date (REPL-style scalability bottleneck!)<br></div></blockquote>yes, the performance questions would definitely be in the case of DIST. Even for this, one way of handling it is to migrate the queries on each node, on put, the node would determine weather it should replicate to a certain node's(the query owner) near cache. These would reduce the replication overhead to a minimum.</div><div><blockquote type="cite"><div>Cheers<br>--<br>Manik Surtani<br><a href="mailto:manik@jboss.org">manik@jboss.org</a><br>Lead, Infinispan<br>Lead, JBoss Cache<br>http://www.infinispan.org<br>http://www.jbosscache.org<br><br><br><br><br>_______________________________________________<br>infinispan-dev mailing list<br>infinispan-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/infinispan-dev<br></div></blockquote></div><br></body></html>