DotNetNuke has had 3 different caching providers. These have all tried to keep cached settings syncronised across multiple machines in a webfarm.
Types of Caching Providers
- BroadcastPollingCachingProvider -this used a backend database to handle cache syncronisation. However this had scaling problems and could mean that a site would lock up as the database was overwhelmed with requests. This was finally deprecated on June 23, 2009 and is no longer supported or will will receive updates.
- FileBasedCachingProvider. This is avaiable in both CE and PE, and uses a central file store to invalidate cache entries. It's biggest weakness (aside from requiring correct setup of permissions, application pools, domain users and code access security) is that it makes the file store (typically a SAN) the single point of failure. Whilst it typically works well, it can suffer from latency if there are a large number of web heads in the webfarm.
- WebBasedCachingProvider. This is a PE only provider, and is the recommended one for all PE customers. It's main advantages are that it requires minimal setup, and that there are no central points of failure. With this provider if you change an entry on one webserver cache if then makes requests to the other webservers via HTTP to expire their cache, avoiding the need for a central resource that could fail or slow down due to multiple requests.
Note: These only provide for cache invalidation. If a user is making site changes (e.g. uploading files, installing modules) they must still ensure that these files match on each webserver. This can be done in a number of ways such as using Microsft DFS, using a utility such as robocopy, or using a SAN as a central file store.