On Fri, Oct 3, 2008 at 1:47 AM, Dustin <[EMAIL PROTECTED]> wrote: > > > 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. >
The way I've implemented it is to cache objects that contain a refresh time stamp. First call that gets an item after the refresh time, immediately updates memcached with the a refresh time = expiration and then repopulates the object. Any calls made between the point in time the refresh time is reset and the object is refreshed in the cache get stale data. That does also require some other code to handle the possibility that more than one process is going to try to get the data but all of this has been implemented in the standard data layer so it's very easy to implement. > > 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. I agree with that 100%. But I wouldn't want it set for every object. Not every object that I cache *can* return stale data so certain objects have the refresh time set to > expiration. Being able to have the server handle those would both simplify life and improve most of the caching in use by folks. > > > > 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). > I look forward to seeing it! Josef -- "If you see a whole thing - it seems that it's always beautiful. Planets, lives... But up close a world's all dirt and rocks. And day to day, life's a hard job, you get tired, you lose the pattern." Ursula K. Le Guin
