BizTalk/AppFabric/WCF Updating existing schema without redeploying the dll Considerations When Retrying Failed Messages in BizTalk or the ESB Toolkit Why Is This Still a Routing Failure in BizTalk Server 2009? Using static ports with ESB Handy XML Tool…

- ‘Peering’ of caches is really a separate issue to the cache invalidation mechanism itself, at least from an HTTP perspective.

- To say a problem is challenging doesn’t necessarily mean that it is infeasible and/or will not scale. I am interested to know if it has been proved that this is the case.

Hi Justin – Please could you explain the reasoning here?

Cache channels is often described as invalidation, but it’s really just a (potentially) perpetual extension of freshness — roughly, “if you’re still in touch with me, and I haven’t said that it’s stale, you can consider it fresh a bit longer.” That makes it compatible with the existing HTTP caching model, unlike invalidation, as you point out.

Cache invalidation is thinking of things the wrong way round. The HTTP cache header says “this may become this stale and the sky will not fall in”. If the sky will fall in, don’t add that header, and use etags and serve up 304s *quickly*.

Think of the cache expiry as a contract, you cannot revoke it once it has been signed. And invalidation really does not scale.

Oh, and if you do want to invalidate, just PURGE the URLs you want to purge as mentioned by Mark, rather than a POST to somewhere random like this API which is then going to have to find the right stuff on the proxies to purge.

Memories of writing Perl to do this from a database to 100+ caches around the world when I worked at Merrill Lynch back in the 90’s… when there was a Merrill Lynch :)

It worked well for maintaining local caches and was handy when I knew of remote target caches (reverse proxy caches). However, I never implemented a subscription model ala cache channels to make it possible for unknown third-party caches to receive the same information.

[1] http://exyus.googlecode.com/svn/trunk/Exyus.Samples/TaskList.cs

There has been a *lot* of research and proposals in this area. This sort of approach is simple and straightforward, but it requires the server to keep a lot of state, and doesn’t scale very well (at least not to Internet-scale, which is what we shoot for on the Web).

Generally what you find with invalidation is that you need to trade off immediacy vs. scalability vs. reliability; you can sometimes get two, but not all three.

For example, in this proposal, what happens when the server can’t get an invalidation to the client, due to a network segment, or the client’s IP changing?