A long time ago I blogged about the caching enhancements in DotNetNuke 5, and a recent blog post by Mitchel Sellers about using DotNetNuke Caching in Custom Modules triggered me into revisiting my old post.
In his excellent post, Mitchel describes a way to abstract from some of the available methods in the DotNetNuke .Common.Utilities.Datacache class. This is indeed a great way to simplify using the DotNetNuke entity cache in your own modules.
One thing that is not so great about those base methods is that they are not geared to be used in high traffic applications. The DataCache.GetCache method for instance is in itself not thread safe. Remember that in the “old” days of DotNetNuke 4.9, quite a few sites had caching issues because of this. Another reason to use this caching pattern is that it allows you to also set the cache timeout and cache priority very easily.
The Caching pattern that was introduced in DotNetNuke 5 has since been enhanced and optimized for performance and thread safety. One of the enhancements is that there is now also support for cached dictionaries.
In rereading my old blog post, i realized that it was still not very clear how to use that pattern in your own code.. it lacked a simple example. So in the rebound, I will point to another, simpler, example in the Core, and also show an example of how this caching pattern that will be used in the new version of the Announcements module.
Let’s first look at the method that the core uses to retrieve all pages for a portal, DotNetNuke.Entities.Tabs.TabController.GetTabsByPortal:
And the corresponding callback method:
As you can see, this is also extremely simple to use. In the backend, CBO.GetCachedObject calls DataCache.GetCachedData, which you could call directly yourself from your code. However, the way CBO (which stands for Custom Business Objects) is architected, it is DotNetNuke’s own object factory. The class has all kinds of handy methods to help create your objects. So using that same object factory to retrieve objects from cache makes sense.
In the upcoming version of the Announcements module, caching will be one of the things that will be focused on, especially since the current version has some funky caching issues. The new version of the module has to keep track of the URL of a single item in the announcement module, in order to be able to generate a proper ATOM feed (the module will support both RSS and ATOM feeds). One option was to store that URL in the database, but that would cause issues when a module is moved to a different page. I decided to make this a calculated field, however, since that calculation is not very efficient, the result of the calculation needs to be cached.
In this case, the PermalinkCallback method is only ever called if the data is not in cache, in all other cases, the value is loaded in a thread safe manner from the data cache.
If your custom code does not use caching, then it would be a very good idea to start experimenting with it. DotNetNuke makes it very easy for you to start using caching, and does a pretty good job abstracting from the inner workings of a good caching pattern.
This post is cross posted from my personal blog.