mca blog

last night i threw together a GetHandler base class that just takes a string (or a string pile from a disk file) and renders that at the specified URL(s). basically puts the UriPattern service in bewteen server content and clients. quick, easy, cool.

but it created a challenge for my caching pattern.

first, if the string is just compiled into the class, there's no caching issue. the content will stay the same until a new compile and that's just fine. done.

but the file-based content is a different tune. when the content is read and delivered, it gets placed in the CacheObject collection and is picked up by the CacheCopyAvailable((Handler)this) function for each request. that's fine and all works nicely. the trouble starts when the underlying disk file is edited. my service has no way (currently) to know that! it's done *outside* the system - not through the normal POST, PUT, DELETE process. it's true i can use HEAD or GET with Cache-Control:no-cache and it all works grand, but i need to flush old stuff out of the cache *automatically* when the underlying file is updated.

i think i have a way to do this. first, i need to place the file contents in my local memory cache, with the full URL as the key and with a dependency directly on the file that was loaded. then, i need to register a callback event for then the object falls out of the cache. when that happens, it will fire off a HEAD, Cache-Control:no-cache request to the URL and force the fresh data to be loaded into the cache. this automatically updates the ETag and dates and will be honored by clients when they validate against the cache.

this work-around takes advantage of the ability to use the local cache and dependencies. this works fine for the local ASP.NET caching library, but would not work for distributed cache services like memcached.