The main case I find expiration useful: You have a database that contains very important data for a popular website. Since this data is so important and this website is so popular, the database obviously can't service every request, so you compute this data and give it an expiration that's a balance between "how much can my database handle" and "just how stale can data on the website be before users start to notice."
Another good case: You have a counter on your website that tracks the number of times a user performs a certain action in a day. You set this item's expiration for end of day and it automatically goes away when it's time to start a new counter the next day... On Tue, Aug 3, 2010 at 3:40 AM, Dustin <dsalli...@gmail.com> wrote: > > On Aug 3, 12:30 am, Peter <xuwenhao2...@gmail.com> wrote: > > Hi, I am new to memcached. I am wondering why expiration is necessary > > for the protocol. Why do we want an item to be expired if there is > > still space to keep it? Otherwise, we can still use some replacement > > algorithm to replace it or garbage collection algorithm to collect it? > > Sometimes, you don't control your source data production and can't > perform cache transformations when things change. > > Sometimes, you really want something to go away after a certain > amount of time because they're no longer relevant and you're best > suited by recomputing. > > Sometimes, you just don't trust that every event will be processed > correctly and having some part of your application be using incorrect > data for 15 minutes or an hour or whatever is an acceptable worst > case. > > Ideally, you're right -- all cache would be invalidated exactly when > things change and nobody should ever use an expiration date on their > caches. I have an application that does this, for everything else, > there's TTL. > -- awl
