[infinispan-dev] HotRod near caches

[Mircea Markus]

On Feb 13, 2014, at 6:24 PM, Sanne Grinovero <sanne at infinispan.org> wrote:

> On 11 February 2014 07:55, Tristan Tarrant <ttarrant at redhat.com> wrote:
>> Hi people,
>> 
>> this is a bit of a dump of ideas for getting our HotRod client in shape
>> for supporting near caches:
>> 
>> - RemoteCaches should have an optional internal cache. This cache should
>> probably be some form of bounded expiration-aware hashmap which would
>> serve as a local copy of data retrieved over the wire. In the past we
>> have advocated the use of combining an EmbeddedCacheManager with a
>> RemoteCacheStore to achieve this, but this is only applicable to Java
>> clients, while we need to think of a solution for our other clients too.
> 
> True we need a general solution, but only as a design: we can still
> think of using an EmbeddedCacheManager as an implementation detail for
> the JVM based clients right?
> For other languages, I'd probably pick a mature and well known cache
> from each language.

+1

> 
> We'd probably want to mask Flag usage: for example SKIP_CACHE_LOAD
> should only apply on the server nodes.
> 
> Also we'd probably want to verify that a failure of an operation on
> our "cachestore" is not going to provide misleading messages, or being
> ignored altogether when running in independent threads.

Having the RemoteCacheManager and EmbeddedCacheManager following a common ancestry has caused a lot of confusion in the community, with people trying to replace one with the 
other and not succeeding. Might be worth splitting them, and then add/keep the relevant flags for HotRod java client only.

> 
>> - Once remote listeners are in place, a RemoteCache would automatically
>> invalidate entries in the near-cache.
> 
> This is the point concerning me the most: I suspect there are so many
> different ways in which this could get out of synch!
> Essentially let's consider that a client requiring this level of
> consistency is becoming part of the distributed system.
> I'm not against doing it, just that I'm having the impression its
> complexity is being underestimated.
> 
>> - Remote Query should "pass-through" the near-cache, so that entries
>> retrieved from a query would essentially be cached locally following the
>> same semantics. This can be achieved by having the QUERY verb return
>> just the set of matching keys instead of the whole entries
> 
> +1, or even better - to avoid multiple roundtrips - we just store the
> indivual results in the local cache.
> The downside is that the gathering phase of query results might not be
> taking advantage of the locally stored individual entries (when they
> match); the good news is we have a similar case with Hibernate
> Search/ORM dealing with 2nd level cache, for which we expose an option
> to get a hint from the user: we could do the same.

also this would not work if the queries project data, instead of returning fully fledged entries.

> 
>> - Optionally we can even think about a query cache which would hash the
>> query DSL and store the resulting keys locally so that successive
>> invocations of a cached query wouldn't go through the wire. Matching
>> this with invalidation is probably a tad more complex, and I'd probably
>> avoid going down that path.
> 
> I'd agree especially in the first phase, but if needed that is
> essentially just a continuous query so we can build on top of that.
> 
> Thanks for starting this!
> Sanne
> 
>> 
>> Tristan
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)