Why is ConfigurationCache persisted between startups?

Topics: Core
Jan 16, 2015 at 3:31 PM
Edited Jan 16, 2015 at 3:57 PM
The following code can be found in SessionConfigurationCache.cs in GetConfiguration

   // Return previous configuration if it exists and has the same hash as
            // the current blueprint.
            var previousConfig = ReadConfiguration(hash);
            if (previousConfig != null)
                _currentConfig = previousConfig;
                return previousConfig.Configuration;
this means that the cache configuration is only effectively changed on the enable event of a module.

Why is this persisted? It doesn't seem to take a long time to create a new ConfigurationCache object on startup (about a second)

To explain why I'm asking, we want to vary the cache keys based on the build version of our product (a way of naturally invalidating cache on deployment). We have implemented IDatabaseCacheConfiguration as follows
public void Configure(ICacheConfigurationProperties cache) 
            var buildVersion = ConfigurationManager.AppSettings["Deployment.BuildVersion"] ?? "NA";

            cache.UseQueryCache = true;
            cache.RegionsPrefix = buildVersion  + "_" + _shellSettings.Name;

            Logger.Information("Configured NHibernate cache provider '{0}' with regions prefix '{1}'.", typeof(RedisCacheProvider).Name, _shellSettings.Name);
But this will only get called currently if we re-enable the module - ruling out the possibility of changing any of these settings on startip or on the fly. I presume there was a reason for the way the code currently exists. I was hoping to understand it before I start tinkering :D

EDIT: I've only just realised that this is the class that creates the notorious mappings.bin :)
Jan 18, 2015 at 8:38 PM
I guess the initial idea was to shave down the performance impact of having to re-build mappings on startup. However if you have a small number of tenants you can safely disable the cache from HostComponents.config.