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:

Listing 1

And the corresponding callback method:

Listing 2

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.

 Listing 3

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.

Posted in: DotNetNuke


# Ryan
Wednesday, November 28, 2012 10:04 AM
Good Day,

I would just like to know where the cache timeout setting is set. Is it set per tab module or is there a global setting. I would also like to know if you can cache an object across the entire portal if multiple modules are using the same data.

Thank You
SuperUser Account
# SuperUser Account
Friday, November 30, 2012 12:20 PM
The CacheTimeout is an integer that you can set yourself. In this example i used a timeout value of a core object (DataCache.ModuleCacheTimeout), because that seemed fitting for the type of object that I was caching. But you can certainly pass your own Timeout and Priority.

The scope of the cache is something that you define yourself by way of the CacheKey. So if you want to cache something for the entire portal, you would use the PortalId in the cachekey. Remember that the cache by default is application wide (so across multiple portals). Doing cross portal caching is extremely rare though, so you would always at least limit the scope to the portal

Post Comment

Name (required)

Email (required)

 I am Erik van Ballegoij. I work for DotNetNuke corporation as Technical Lead and Evangelist. On this blog I blog about DotNetNuke tips and tricks and whatever else comes to mind

powered by dotnetnuke follow me on twitter linkedin rss feed