On Feb 13, 2014, at 6:24 PM, Sanne Grinovero <[email protected]> wrote:
> On 11 February 2014 07:55, Tristan Tarrant <[email protected]> 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 >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
