Few queries on atomicity of requests

Daniel memcached at puptv.com
Thu Jun 19 06:02:35 UTC 2008


I have a couple other ideas I'll share in case anyone likes them...

1.) Let the application decide when an object is "too stale."

Currently memcached is setup so an expired element is never available,
even though it's still in memory.

Perhaps another way memcached could work is to report pack, with the
data, the age of the data.  Then the app can decide if that is too old
or not, based on it's needs, and refresh as necessary.

2.) Rather than having a dog pile, you could set a magic "I'm getting
that" which is written to the cache on a miss. (best if it's even part
of the original get request actually) Other processes, rather than
jumping to the database just wait in a loop with some random timeouts
calling memcached repeatedly until the data is available.

Now, for the big question I've been sitting on for months...

Has anyone worked out a system using memcached that guarantee's
memcached has the most recent data? Essentially, tying memcached to the
database so memcached is never allowed to contain any stale data?

I've looked at some soutions involving a timestamp with every record, a
revision code, database row locking, etc.  I think I've determined that
it can be made to work work with the data itself, by disabiling caching
when multiple writes are being processed, however I was hoping to find
out if anyone's actually made it work.

>From what I understand, a system like this can only work if every
application that accesses data does it part, but I haven't seen any
proven examples, and it seems to be a highly complex interface that
would require some real amazing programming magic.



On Thu, 2008-06-19 at 00:04 -0400, Stephen Johnston wrote:
> Thank you. I figured that something of that nature was involved. It's
> good to hear some approaches that are actually being used.
> -Stephen

More information about the memcached mailing list