DotNetNuke Miscellany #1 – PurgeCache Scheduled Task

Welcome to a new series of short articles on miscellaneous tips, tricks and information for DotNetNuke Users and Developers.

Purge Cache Scheduled Task

Over the last few days I have been trying to solve an issue with the Scheduler in version 4.9.  There are a number of threads that discuss the issue in the DotNetNuke Forums.  One of the threads was concerned that the Purge Cache Scheduled Task wasn’t running properly, as the cache items were not being removed from the cache when this task completed.

While there was a “real” issue with the File Based Caching provider (which has been fixed), the user did not completely understand what the Purge Cache task actually does.

Of course, part of the confusion arises from the name given to the task, which could be read to mean that the task removes all the current items from the cache.  However, this is not what this task is designed to accomplish.

Both the File Based Caching provider and the Broadcast Polling Caching provider use mechanisms that can be used to synchronize the ASP.NET cache between servers in a web-farm. 

In the File Based Caching Provider, file stubs are saved to the Portals/_default/Cache folder which are used to create a file dependency on the cached items.  When the cache expires on one serer, the file is modified which causes the other servers to expire their copy of the cached item. 

Unless the cached item is explicitly removed (rather than scavenged) this file stub is left in the Cache folder.  Over time the number of file stubs will grow, so the Purge Cache task is used to clean up these file stubs.

So the Purge Cache task does NOT clear the ASP.NET Cache (there is a button in Host Settings that does that).  Also it is important to note that unless you are using a Web Farm you do not need to use this task at all, as the file stubs are only created in Web Farm scenarios.

I hope this helps.  If you have any ideas for this series of tips, let me know.