DotNetNuke Modules – Caching

food-swt-04 A couple of days ago I showed a method for finding a module on another page. Néstor Sánchez pointed out that on a large site, this could cause a significant performance issue. He suggested, instead, registering the location of the module with the database when it is created on the page it is on.

I was looking for a way that would allow the module to move around, and had initially thought that a module-centric method would require the end user to do something. Ah well, that’s one of the problems of working alone. (And one of the advantages of blogging about what you’ve done.)

So, let me show you the way I did solve the performance problem. It isn’t quite as efficient as what Néstor recommends, but it is usable in other situations and it is a performance solution you need to know about.

In the old days of ASP, when we wanted to store something across sessions, we’d put this information in the Application object. It was a solution, but had memory issues.

When ASP.NET was introduced, the Cache object was introduced, which allows us to store information in memory. But if that memory is needed for something else, the memory is swapped out. Meaning, we can use the memory for caching, but we always need to make sure that what is cached has the information we are looking for before we try to use it since it may have been swapped out.

The problem with ASP.NET caching is that it just isn’t practical in a shared hosting environment. Multiple applications running on the same server means the memory is almost always needed and nothing is cached.

DotNetNuke has its own caching mechanism that overcomes this limitation. You can choose to store the cache in memory, if you are running your application in an environment where this makes sense, or you can have it use hard drive space.

You will need to use a couple static methods hanging off of the DataCache class located in the DotNetNuke.Common.Utilities namespace.

To put something in the cache, you can call SetCache() using any of the 12 overloaded methods. To pull something out, you can call GetCache().

The various methods allow you to set dependencies just like you can with the .NET caching model. But, unlike the .NET caching model, you can tell the object to persist an application restart.

I’ve been able to use this throughout my code to avoid otherwise time-consuming operations in several locations including caching code-generated images. In this case, as I changed the source image, I needed to clear the cache. I did this by using the RemoveCache method.

By setting the sliding expiration to one day, I can take the performance hit for the lookup once a day and otherwise have the same performance I would have by storing the value forever in a table in the database.


Other post in DotNetNuke - Module Development

Like this Article? Subscribe to get every article sent to your email.

Related Post

  • DotNetNuke Modules – Creating Base ModulesDotNetNuke Modules – Creating Base Modules Now that we have DotNetNuke installed into Visual Studio we can go ahead and create our first modules. Actually, creating the modules is pretty simple. But it is even easier to do it […]
  • ASP.NET Substitution ControlASP.NET Substitution Control Tucked away on the toolbar is a little-used and often overlooked control.  Not using this control could be costing you in performance. The control I’m referring to is the […]
  • DotNetNuke Modules – Finding The Page a Module is OnDotNetNuke Modules – Finding The Page a Module is On Last week we talked a bit about Inter Module Communication, the ability of one module to notify another module on the page that something needs to happen without requiring a post back.  […]
  • DotNetNuke Modules – Making Content PortableDotNetNuke Modules – Making Content Portable The last main feature of module development that we need to discuss is the implementation of IPortable.If you've ever worked with other content management systems in a corporate […]
  • Cross Language References in ASP.NETCross Language References in ASP.NET Most ASP.NET programmers are aware that the environment allows programmers to write code in multiple languages.  This is what allows a programmer who prefers CSharp to write modules […]

About Dave Bush

Dave Bush is a .NET programmer and Certified ScrumMaster who is passionate about managing risk as it relates to developing software. When he is not writing or speaking about topics related to Application Lifecycle Risk Management (ALRM), he is an example to his peers as he develops web sites in the ASP.NET environment using industry best practices.