Consistency is good - so is backward compatibility - our CloudCache implementation relies upon ActiveSupport::Cache, so prefer that nothing be deprecated, and if so, with a long lead time.
Thanks, m getCloudCache.com On Sat, Apr 24, 2010 at 11:48 AM, Brian Durand <br...@embellishedvisions.com > wrote: > > 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<rubyonrails-core%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > -- 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.
