Hi Daniel,

Thanks for your post. I wonder if you can confirm the version of mojoPortal you were testing with? You can find the version under Administration > System Information.

The reason I ask is because we recently replaced our caching logic with a provider model so we could plug in AppFabric cache, and our new logic uses no locks at all.

The previous implementation did use locking and was based on this thread on stackoverflow. By reading that thread one might think that locking was always needed to update a cache item, but now as I understand it from this article, the cache is threadsafe for updating single objects. From the article:

The ASP.NET Cache and Application objects guarantee that no other concurrently running threads can ever interfere with the single read or write operation you're executing. However, if you need to execute multiple operations on the Cache object in an atomic way, that's a different story.

Since our use of cache is limited to single objects retrieved or added to the cache at a time our previous locking was not needed.

Really the siteSettings object is not needed to service a request for a .txt file but when runAllManagedModulesForAllRequests is true then ASP.NET does handle all requests including those for static files. In our httpmodules I've had it short circuit the logic for other expected static extensions like .js .css etc so that we don't access siteSettings unnecessarily for those requests. I'll add a similar check for .txt to avoid that, though .txt files are not used all that much in typical web sites which I guess is why it didn't occur to me to add the check for that extension when I was adding the checks for other static files.

Thanks and best regards,

Joe