On 29 Sep 2009, at 10:19, Mircea Markus wrote:
On Sep 29, 2009, at 12:08 PM, Manik Surtani wrote:
> On 29 Sep 2009, at 09:57, Mircea Markus wrote:
>> Again, this is a feature from Coherence.
>> Basic idea is to execute a query against the cache, and hold the
>> result object. This result object will always have up to date
>> query result; this means that whenever something is modified in
>> the cache the result itself is updated. Advantage: if one performs
>> the same query very often(e.g. several times every millisecond)
>> the response will be fast and the system will not be overloaded.
> Is it really faster? Surely all you save is the construction of
> the various query objects, but the query itself would have to be re-
> run every time. Or does it attach a listener to the cache and
> check whether any new additions/removals should be used to update
> the result set?
this is the way it works. It is a sort of a near-cache, just that
instead of being invalidated it is updated whenever the cache is
updated. The documentation also suggests that they are using
> I don't see how that could be much faster though.
I think it might be if the you are running *the same query* tons of
times. Basically you don't do a map-reduce on all the nodes, but
rather on every insertion (especially if the number of insertion is
relative small compared to the number of same-query-bring-run) you
updated (if necessary) the cached query result.
Hmm. It would be pretty use-case-specific. It's hard to see how this
_generally_ performs better, since you need to make sure you are aware
of all changes happening all over the cluster to keep this result set
up to date (REPL-style scalability bottleneck!)
Lead, JBoss Cache