This project is read-only.

HttpCachingService Configuration

Jan 4, 2010 at 9:29 PM
Edited Jan 4, 2010 at 9:30 PM

The HttpCachingService is currently configured via Container.Components.config:

 

<configuration>
  <components>
    <component id="VelocityNamedCachingService"
               service="WhoCanHelpMe.Framework.Caching.ICachingService, WhoCanHelpMe.Framework"
               type="WhoCanHelpMe.Infrastructure.Caching.HttpCachingService, WhoCanHelpMe.Infrastructure"
               lifestyle="singleton">
      <parameters>
        <enabled>true</enabled>
        <cacheDurations>
          <dictionary>
            <item key="VeryShort">60</item>
            <item key="Short">120</item>
            <item key="Medium">300</item>
            <item key="Long">10800</item>
            <item key="Permanent">86400</item>
          </dictionary>
        </cacheDurations>
        <caches>
          <dictionary>
            <item key="AdHoc">Medium</item>
            <item key="MvcTempData">Short</item>
          </dictionary>
        </caches>
      </parameters>
    </component>
  </components>
</configuration>

 

I am interested in the possibility of being able to selectively override the settings of individual caches. I think this could be achieved in two ways:

1) Cache "Enabled" attribute:

 

<cacheDurations>
<
item key="AdHoc" enabled="true">Medium</item>

2) A "Do Not Cache" Cache Duration definition:

<caches>
<item key="None">0</item>

 

What do you think? I am leaning towards the latter.

Best regards, Martin

Jan 4, 2010 at 9:39 PM

Also, since the component is configured via Castle as a Singleton Lifestyle, what would be the implications of changing a config setting on the fly?

Would an IIS app restart be required in order to apply the changes? Or would this be something that would be picked up by ASP.NET automagically, like when web.config is modified?

Jan 4, 2010 at 11:02 PM

Hi Martin,

For the first question, I agree that the second approach is better. In fact, there's already a member of the CacheDuration enumeration called CacheDuration.NotCached. You don't need to define this in the cacheDurations element, and you can use it in the caches element like this:

        <caches>
          <dictionary>
            <item key="AdHoc">NotCached</item>
            <item key="MvcTempData">Short</item>
          </dictionary>
        </caches>

On your second question, changes will not get picked up automatically because the Container.Component.config is not monitored for updates - so regardless of the lifestyle configured, it will be necessary to restart the app to get changes picked up. I did think there was a way to get Windsor to monitor the external config file automagically and to reinitialise the container when changes are made, but a quick Google didn't get me very far - and I have no idea how this would play with the fluent registration we use for the majority of the components.

Hope this is useful.

Cheers, Jon

Jan 4, 2010 at 11:17 PM
For the first question, I agree that the second approach is better. In fact, there's already a member of the CacheDuration enumeration called CacheDuration.NotCached. You don't need to define this in the cacheDurations element, and you can use it in the caches element like this:
        <caches>
          <dictionary>
            <item key="AdHoc">NotCached</item>
            <item key="MvcTempData">Short</item>
          </dictionary>
        </caches>

Hi Jon,

Thank you so much for the reply.

I have tried the NotCached value as you suggested, and it works perfectly. Great stuff!

Jan 4, 2010 at 11:22 PM

On your second question, changes will not get picked up automatically because the Container.Component.config is not monitored for updates - so regardless of the lifestyle configured, it will be necessary to restart the app to get changes picked up. I did think there was a way to get Windsor to monitor the external config file automagically and to reinitialise the container when changes are made, but a quick Google didn't get me very far - and I have no idea how this would play with the fluent registration we use for the majority of the components.

Hi Jon,

This is what I suspected as well.

However, it seems as if I spoke too soon.

I re-looked at this, and it turns out that, at least in my current config, I am able to get the settings in Container.Component.config recognized by doing the following:

 

1) Change a value in Container.Component.config as desired

2) Touch web.config using the old trick: modify something harmless and save it, then modify it back, and save it again

 

By doing this, the changes I made to Container.Component.config are reflected in the next web request, without having to restart the IIS app.

Jan 4, 2010 at 11:38 PM

Yep, that would work - but touching web.config actually restarts the app anyway, so you'll still get 20 seconds or so of downtime as the app startup code reinitialises, populating the container and reloading the NHibernate config. Assuming you have the app running in it's own app pool, wouldn't it just be easier to recycle the app pool?

Cheers, Jon

Jan 5, 2010 at 11:27 PM

Hi Jon,

Thank you for your suggestions. I will do more research on this and post here if I find anything interesting. Thank you!