We used to flush cache on rollout of new code that we knew would be binary incompatible, but that was very painful. So we do "versioned" objects and write conversion methods so that when new code rolls out, it can read the previous object, see that it's an old version and apply the necessary transformation. This works particularly well for us because we don't have long running sessions or, really, any sort of state between requests.
On Thu, Jul 30, 2009 at 1:54 AM, Matt Ingenthron<[email protected]> wrote: > > blazah wrote: >> >> What do folks do with the objects stored in memcached when a new >> version of the software is deployed? There is the potential that the >> data could be stale depending on the code changes so do people >> typically just flush the cache? >> > > The most common approach here is to add something to the key prefix which > matches the version of the application. If you work this out, you can > actually even do 'rolling upgrades' of the application (assuming users have > long lived sessions). As things roll over from the old prefix to the new > one, the old objects will just naturally expire or LRU out. > > If you have a heavy workload, a flush_all could be pretty bad for your > users. > >> Is there information on best practices and/or how memcached is used in >> production? > > There's quite a bit on the FAQ: > http://code.google.com/p/memcached/wiki/FAQ > > Hope that helps, > > - Matt > > -- awl
