Re: [infinispan-dev] HotRod near caches
On 11 February 2014 07:55, Tristan Tarrant <ttarrant(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev