windows azure caching - best practice for checking whether a key exist or not

Question

In Windows Azure Caching (http://msdn.microsoft.com/en-us/library/windowsazure/hh914161.aspx), Microsoft.ApplicationServer.Caching.DataCacheException is thrown (with ErrorCode: KeyDoesNotExist), when someone tries to get a not-cached object (i.e., the key of the object does not exist).

Instead of handling DataCacheException, is there any way to check if the key exists gracefully?

thanks,

Vaas

Answer 1

The DataCache.Get(key) method returns null if the provided key is not found.

Any other methods that require the key to be present such as those concerned with locking will result in a DataCacheException.

Wooer

So do you suggest to call DataCache.Get(Key) before any other methods (that require the key to be present) to avoid DataCacheException? Isn't it performance overhead? – Vaas

Azure cache is designed to provide extremely low latency operations. Are you using the shared cache (old style) or the role-based caching (new style)? I would go with the Get() call and as with all things measure the performance to be sure. – Wooer

Thanks for your comments, and I'm using the role-based caching. Why would you think that calling the cost of calling Get() method would be negligible? I think it can't be ignored because of the network round-trip cost (prob. more than several hundreds milliseconds?) What do you think? – Vaas

The Get() call latency won't be negligible but I seem to remember from my tests that it is around 10ms or less (which is probably why you don't see any async methods on DataCache). Instances in the same deployment are usually collocated on the same node in the azure data centre. – Wooer

do you know the overhead of handling DataCacheExcpetion (i.e., key-does-not-exist) Do you think the Get() call latency (~ 10ms) is smaller than the exception handling overhead? – Vaas

Write two endpoints on your app - each employing the above code paths. Deploy to azure and then load test. If the difference is negligible in terms of throughput and concurrency then I'd say that the Get() first approach makes more sense to me semantically. – Wooer