Comments

5 responses to “Caching Method Results in ASP.NET 2.0 using Delegates”

1. 

   November 15, 2005

   http://

   You don”t need generics if you”re happy with using code that has race conditions in it. Think about what will happen if the caching engine decides to drop your object between the line that inserts it and the one that retrieves it. Anything you insert is not guaranteed to stay cached until it expires, only not to stay longer.

   The correct way:

   object value = HttpContext.Current.Cache[key];

   if( value == null ) {
   
   value = method();
   
   HttpContext.Current.Cache.Insert(key, value, …);
   
   }

   return value;
   

   Reply
2. 

   November 15, 2005

   James Crowley

   Ahh. Thanks! 🙂 Race conditions are still something that aren”t quite engrained into my brain yet!

   Reply
3. 

   November 15, 2005

   http://

   There is another condition when inserting an item by the way.

   Reply
4. 

   November 15, 2005

   http://

   Not really, there would be if we used Cache.Add instead of Cache.Insert. Insert will replace an existing key, if it manages to get inserted multiple times. You could lock the code around the check and insertion but that would be an unneeded bottleneck and imo it”s better to just evaluate the method multiple times.

   Reply
5. 

   November 19, 2007

   http://

   Hey, just a comment, appreciate you sharing your thoughts:

   >Hmm. Talk about over-engineering. I don”t think we >really need generics at all, provided we”re happy >with a cast outside the method instead of inside it.

   I just want to say that the whole reason i use generics is to ensure that people aren”t making casts outside the methods.

   Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.