thanks! My reasoning is that the performance hit from erasing the cache every, say, 15m should not be that much. And I like very much the peace of mind of knowing that, no matter what, the cache will not stay out-of-date for long.

The downside is that the admin people will not be able to see their modification immediately and they might think the application is buggy. Perhaps the best solution would be to use both cron job and after_update observer?

I was thinking that maybe you’re better off expiring the cache when a new product is added to the category instead of blindly let the cron doing it (unless you know categories are always updated at some point in time). You can use an after_update observer on the Category model, you can check if there are changes in the products association and invalidate the cache. If you do this, you don’t need the lazy proxy. But as I said, it depends on the situation. Good luck!

thanks for your comment. I don’t think there is a bug, as for every request a new proxy will be created. Either that, or I misunderstand you :-)

It turns out, however, that the lazy proxy behaviour is now standard in Rails 3. This technique might still be useful for Rails 2 though.

At that point, though, you basically have a cache that never expires. If you come up with ways to make it expire, then you’ll be to be careful about race conditions again. This is not to detract from your very elegant solution – just be careful. :)