Comment #3 on issue 372 by [email protected]: no way to get without
bumping LRU, aka "peek"
http://code.google.com/p/memcached/issues/detail?id=372
peek is probably useful, but I'm not sure when we'd get to it.
"If I were you", I'd embed the creation time in the stored object. the
older the object is, the more often it tries to set some flag or log some
line to get itself rechecked.
Or at least some similar process wherein decently active data has a higher
chance of being recalculated early, and longer-tail less-hit data gets
booted on its own.
You can also leave "hints" in extra cache keys. For example, if an object
is created from three different sources, this makes it difficult to give it
a single namespace to invalidate it by.
So when an edit comes in for resource A, you add/set an extra key that
signifies "Source A has been updated" - when fetching the objects, you do a
multiget to grab the original object and any of these flag-keys if they
exist. If they do exist you can make a decision to recompute on the fly,
asynchronously schedule an update, etc. Also potentially factoring in the
age of the object.
You can also extend the LRU crawler to help with this, potentially.
Usually folks just try to not structure objects so far away from the edits
that you can't authoritatively say what affects which data. It's a known
limitation of distributed cache stores like this (without grossly slowing
things down). If you're stuck with it you have some options at least (LRU
crawler/etc).
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
---
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
