Why is this a design error? When you put something in the cache then you already have a reference to it right? Ofcourse it could be the case that the item is removed by te scavenger between the .Contains(..) and the .GetData(..). But that's a very minor change... This can easily be tested when cached objects can never be null.

object cacheObject

do{
if(!CacheManager.Contains(cacheKey)) {
cacheObject = CreateVeryExpensiveObjectX();
}else{
cachedObject = CacheManager.GetData(cacheKey);
}
}while(cachedObject!=null);

Your solution should work, true.

Though the API could have been more intuitive on this point. Bugs that have a very minor change to occur are hard to trace, did you know? ;)


Looping through code seems like a bit confusing, when reading the code out of the context.

IMHO the right way to pul items from a Cache should look something like this:

Apple o = CacheManager.GetData(cacheKey) as Apple;
if (o == null)
{
CacheManager.SetData(cacheKey, o = GoFetchAnApple());
}

Nice and compact, isnt it?

Worst thing that could happen know is adding the item multiple times to the cache, because we did not write syncronisation code (could be just a single lock around the code snippet). But we'll never end up without an apple at the end of this code.

Hi Olaf -

I agree that your code snippet is problematic, but I disagree with the conclusion that there is a design flaw. The Contains method is there to support a different (and admittedly minor) scenario where you want to check if an item is in the cache but don't want to actually pull it out. You may want to do this to determine whether an item should be proactively retrieved from the master data source.

There is always a risk that people will use some features incorrectly - we try to mitigate this by showing the correct techniques in the code samples and QuickStarts.

Tom