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
