On Feb 20, 10:29 am, Jean-Charles Redoutey <[email protected]> wrote:
> 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. I've also argued for the removal of flush with delay. It was semantically confusing with delete with reserve (which was remove), and is really easy to do as a client feature. I don't think it makes sense to exist as a server function at all. > 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. Well, flush them at the same time. If you issue a flush on my client, it does all of them as concurrently as possible. It's about reducing the window of error. As you've pointed out, the larger the window is, the more of a chance there is. > 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. I suppose the difference of opinion regarding the semantics is that in the non-negative case (existing code), *all* records are invalidated within memcached. Does anyone actually use a "future" flush that can't be done client- side?
