I have the slight impression we are entering a non ending discussion ;-) Anyway, what you say is right ... as long as there is only one server in the memcached cluster.
If we go for 2, the *right* way to use the delayed flush would be something like flush +10 on server a and flush +20 on server b. At '+15', you read data that are hashed part to server a, part to server b, and you construct some new data that is hashed to let's say server a. At '+21', you have this new data on server a based on a part still there on a and a part that has been flushed on b. You're fooled ! Even worse, the 'b' part of this data age is not limited to the [+10,+20] interval, it can be whenever in the past ... The only way to have the global consistency you are describing is to flush all the nodes with the exact same delay, which is simply unapplicable to production cache. Since you can't ensure the *real* age of a data, basically the first time any part used to build it has been put in any of the node within the cluster, why not focus on something you can ensure, the time this particular data was put in cache? In which case, whatever the sign of the flush delay, we have the same semantic. --- Jean-Charles On Fri, Feb 20, 2009 at 18:32, Dustin <dsalli...@gmail.com> wrote: > > > On Feb 20, 2009, at 4:27, colin.pit...@gmail.com wrote: > > flush_all effectively removes everything from the cache. > > > flush_all +10 <=> flush_all executed in 10 seconds > > Effectively removes everything from the cache as a sort of > time-bomb. > > > flush_all -10 <=> flush_all executed 10 seconds ago > > Removes *some* stuff from the cache, and you can't be sure what > stuff > is removed and what stuff remains, nor what parts of things that were > retrieved in the last ten seconds and that were invalidated were used > to construct some of the things that still remain. > > -- > Dustin Sallings > > > >
