On Oct 2, 4:52 pm, Alon Diamant <[EMAIL PROTECTED]> wrote:
> Josef, Dustin,
>
> A major benefit that cannot be easily solved client side, without a
> round-trip to the cache server,
> is that the previous (read: expired) version of the item remains on
> the server for future clients.
One of the strategies is to create two keys for every item, one with
an expiry however less than the real expiry of the object and then
your get always asks for both.
If you get two objects back, you just do your normal thing.
If you get one object back, you do an add.
If the add fails, you do your normal thing.
If the add succeeds, you're the client that gets to reconstruct
stuff.
If you get zero objects, it's a complete miss.
> This way, instead of waiting for an updated version of the item,
> clients display the previous version
> until the newer version is updated by the signaled client. This is why
> the reversal of the strategy,
> as Dustin suggested it, is not appropriate.
Ah, that makes sense. That feels like it changes server semantics
quite a bit.
So do you just never have things expire by date? I assume you still
use the LRU, right?
> However, it is correct that database stampeding can be solved client
> side, and it is appropriate
> in many case. This suggestion is simply an alternative, server side
> solution which offers simpler
> development on the client side. It also offers, as noted, keeping the
> older version of the item with
> no big hassles.
Right -- I agree it's easier to dictate server behavior than try to
communicate design patterns to every memcached user.
> If you're interested in the global patch, let me know.
It's always good to send a patch to start a discussion. The code
most accurately expresses your intent so at least some of the
questions get out of the way a bit quicker (or at least are replaced
with ``did you mean to...'' kind of questions).
