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. 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.
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. The patch, as it is currently coded, works globally. The timeout is, also, global. The patch itself is very simple. It is possible implementing this on a per-item basis, but it will require at least 4-bytes overhead per item, and a bigger modification of the source code - to add protocol support, as you both noted. The change won't be dramatic, however... mostly adding a protocol command and modifying the item struct. But that is current of our current scope. If you're interested in the global patch, let me know. Thanks for the quick responses! :) Alon On Oct 2, 9:07 pm, "Josef Finsel" <[EMAIL PROTECTED]> wrote: > Alon, > > That's a great concept and I've actually implemented it client wise in our > code. But I wouldn't want to have it instituted globally because there are > some items that, when they expire, should stay expired. > > Does your patch allow for marking items to exhibit this behaviour or does it > do it for all items? Is it possible to change, on a per item basis, how long > the refresh is for? > > Thanks > > Josef > > > > On Thu, Oct 2, 2008 at 1:14 PM, Alon Diamant <[EMAIL PROTECTED]> wrote: > > > Greetings, > > > I work as a developer in Metacafe. In our company, we use memcached as > > our caching system, and have been using it for a few years now with > > great results. A while ago, we thought of a neat little concept that > > made working with memcached much more convenient for us. We patched > > the memcached code in-house, and have been using this patched code for > > a while now. We are now offering the concept (and the source code) to > > the project. > > > The idea is as follows: currently, whenever an item which has expired > > is requested from a memcached server, the server immediately unlinks > > (deletes) the item internally and returns an empty (or null) item to > > the client. We propose, instead, returning an empty item to the client > > and extending the expiration time of the item by X seconds (we use 60 > > seconds), thus returning the expired item to all clients who ask for > > it in the next X seconds. This behavior repeats itself, after X > > seconds, and so forth. This behavior should be controlled by a command- > > line argument, and is off by default. > > > The benefit is that the client which receives the empty item can > > refresh the item however it deems fit. There is no race situation and > > no database "stampede". The client can access a database and create a > > new item, storing it to server, knowing it is not racing another > > client. (Of course, if the server has just been launched or if the > > item is brand new - there might be a race, but this idea is not an > > attempt to fix this different issue.) > > > The code changed to implement this idea is minimal, and there is no > > interference with the standard lazy expiration/deletion logic. We are > > willing to submit the patch that we've tested internally and that we > > deem stable. > > > Let me know what you think and thanks for creating this wonderful > > application, > > > Alon > > -- > "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
