[infinispan-dev] HotRod near caches

[Sanne Grinovero]

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.

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.

> - 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.

> - 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