> This I'm not so sold on, expires in is a memcached implementation > specific feature and adding it to all the other cache stores simply > seems to add overhead for very little gain. No one is seriously going > to be using MemoryStore or FileStore in production and wanting to use > :expires_in. What was it you needed this for?
Mostly what I wanted was for the caches to be consistent. I think having caches support a time to live on write is a pretty fundamental feature of a cache because otherwise you are stuck needing to know what every cache entry is so you can expire it when necessary. For a small site on a single server, I think MemoryStore or FileStore could be a perfectly viable option. > > * Add support for :race_condition_ttl to fetch. This setting can > > prevent race conditions on fetch calls where several processes try to > > regenerate a recently expired entry at once. > > Can you expand on this? The logic is that if you specify a race condition ttl, and a process finds a recently expired entry in the cache during a fetch, it will first put it back in the cache with an expiration time shortly in the future. It will then regenerate the entry and store it in the cache. The advantage is that it can reduce race conditions when a cache entry expires and you can have potentially dozens of processes trying to regenerate the entry at the same time. If the process that is regenerating the entry fails, another process will try again shortly when the old entry expires again. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
