[sorry for top-posting, in a bit of a hurry]
There has been a lot of strategies for managing stampedes. I think the basic idea here makes sense, but I've a couple of comments: 1) Before adopting this strategy, I'd want it to be reversed -- expiration date should be when the object expires always. I've seen similar proposals for probabilistically returning NOT_FOUND as expiration approaches. 2) It feels like this would need some kind of protocol support. It's great for more complex, larger objects that might live for a while, but I also end up with a lot of short-lived objects that such a system would render nearly useless unless the entire caches were partitioned. 3) People do this on the client side with a couple different strategies, and that would solve both issues. On Oct 2, 10:14 am, 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
