Hey, Check this out: https://github.com/memcached/memcached/pull/484
You can't quite do this with the way metaget is now, though it's feasible to add some "value if cas match on mget" flag. I'd have to think it through first. For local caches though, unless your object is huge, simply waiting on a round trip to memcached to see if it's up to date removes most of the value of having the local cache. With a local cache you have to check it first, then check if it's fresh, then use it. It's likely the same speed to just not have the local cache at that point so you can avoid the CPU burn of the initial hash/test or trade it for CPU/network used in pulling in the value and having a simple system. However! If you have a limited size "hot cache" and you can asynchronously test if they need to update, you could (say once per second or whatever makes sense for how hot your objects are), kick off an async test which runs mget with options for no-bump (optionally), no value, and cas (no flags, size, etc) for a lightweight response of just the cas value. If the cas doesn't match, re-issue for a full fetch. This works okay for high frequency items since an update would only leave them out of sync briefly. Polling kind of sucks but you'd only do this when it would reduce the number of requests back to origin anyway :) I'm hoping to get metaget in mainline ASAP. Been hunting around for feedback :) Should be finishing up the code very soon, with merge once a bit more confident. On Tue, 17 Sep 2019, John Reilly wrote: > Hi all,I was just thinking it would be great to be able to cache the most > used items in a local cache on the client side and I think this would be > possible if there was a way > for the client to send a request to get a key, but only if the cas value is > not the same as the cas token of the value I already know about locally in > the client. I don't think > this is possible with either protocol today, but would be happy if told > otherwise :) > > Also, can anyone think of a reason why this would not work - if it is not > supported today, it might be a nice feature to add. > > Thanks, > John > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to memcached+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/CAJ__CS_0CaWLU-fqTV%2BeYRU6V3Pg6D8Rix%2B7Lbg_YyDs5tjxPg%40mail.gmail.com. > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1909171732430.1888%40dskull.
