I agree that the behavior has to be clearly documented, negative TTL may not be obvious for everyone, but I don't feel this is too misleading: this is really exactly the same behavior than the flush, only reference time for item drop is in the past.
Also, if functionally this does not change a lot versus a plain flush, this can make a huge difference operationally speaking. I mean if for any data consistency reason, you need to flush your cache on a regular basis (or at least more than 1 time a year!), doing it on a few dozen nodes is not as light as it could appear: even if everything is sized to work fine, you still have to monitor the whole process that will for sure last some time (if you don't plan to overload you DB ;-) and any issue on a working memcached node can jeopardize the whole process. While with a negative TTL set accordingly to the global update rate of your data, this really is a transparent operation: in one shot and a very limited induced cache misses, you have ensured the freshness of your data. On Sat, Jan 24, 2009 at 02:49, Dustin <[email protected]> wrote: > That is, it feels like it could lead to a lot of confusion when the > time ends up overlapping due to values newer than the flush timeline > being built upon items that are older than the flush timeline. > --~--~---------~--~----~------------~-------~--~----~ > > I am not sure to get your point here. Each item in the cache has only one clearly defined creation timestamp: the time when it was last added/set/replaced. Ok, this can be more an "update" timestamp from client perspective, but this timestamp is clearly defined as the time when the key and this associated data was put in cache. So whatever the history of the key (if any) we only deal with the last update time, so no overlapping issues, or did I miss something? Jean-Charles
