Doing Caching Badly

by coatta 10/25/2009 10:34:00 AM

I had my first real encounter with ASP.NET caching the other day and it was not a happy one.

We're doing QA on a new release of one of our applications and one of the bugs was turning out to be difficult to reproduce. The bug was caused by quickly clicking twice on an ASP.NET control. In some cases, this would result in a null object exception. The null object in question was a user control (.ascx file) also included on the page. During debugging we observed that the control was fine on the first request, but was sometimes null on the second request. I found this baffling, since ASP.NET is supposed to be responsible for initializing all the controls on the page.

Eventually, I asked one of the ASP.NET gurus in the office, and he asked whether caching was enabled for the user control. We took a look at the code, and sure enough, there was the OutputCache directive at the top of the .ascx file. Oddly the cache time was set to 1 second. Of course, this explained the non-deterministic behaviour we had been seeing. If there was enough latency over the network, even rapidly clicking on a control twice will not produce two requests with less than 1 second of separation. This also explained why we were able to reliably reproduce the bug when the browser and the application were actually running on the same machine.

At this point, I was happy to have the bug resolved. However, my happiness was shortly replaced with being pissed off with whoever decided that this was a good way to implement caching. It totally violates the principle of encapsulation. An internal feature of the implementation of the user control (that is, the OutputCache directive) can break code in pages which use the control. Furthermore, when the code breaks, it does so in a way that does not jump up and down and scream "you've turned on caching you fool!" The way the feature works is that when a cached version of the contol is used, the control reference in the containing page is set to null rather than to an instance of the control. If you have code on the containing page that accesses the control, you get a null reference exception. Those unaware of this feature of ASP.NET might find themselves beating their head against the wall for a few hours trying to figure out what is wrong with their code.

I really should bring something to work next week to fill in those dents in the wall.


<<  May 2024  >>

View posts in large calendar


My opinions are my own, but you can borrow them if you like.

© Copyright 2024

Sign in