ASP.NET Cache - Callback versus Refresh - How to decide?

Question

Does a callback put more strain on a server in terms of cpu because it has to watch for a change all the time?

I suppose a refresh makes code a little less manageable in that you have to find the place where the cache is being refreshed and there might be a tendency to forget to add the refresh?

When the cache is being refreshed, the page called will seem to load longer when cache is being refreshed, a callback, might be less noticeable?

For refresh, it may not happen for awhile until a page is hit, so there is possibly stale data? Page hit, change in data immediately after.

Thoughts? The above I wrote assume caching is done for data from a database.

Answer 1

Callbacks are special events. It does not watch for the changes , once the events are triggered the callback happens Refresh is a form of requesting page again. Depends on what kind a app you are using.

Rather than using a refresh on the whole page , use AJAX parts to refresh that specific info. ( since I don't know , you refresh the whole or partial )

Cache might cost more , if you did not create a good caching mechanism.

Answer 2

Using the callback doesn't result in the server "watching" for a change. I'm sure that it keeps a timer that periodically expires and causes all the current items to be checked to see if they have expired. When an item is accessed, the expiration time is adjusted if the expiration is a sliding window. The process of checking for expiration might take some small amount of time, but it's not as if the cpu is constantly watching to see when the item should be removed. I think the deciding factor should be if you want to remove unused items from the cache automatically on your schedule or if you want to keep them until they are dirty (the values have changed) then refresh them to make sure that the most recent values are always available.

Answer 3

Having a callback will not impose significant resource costs while the data has not expired (ASP.NET is not checking every milli if it should call your callback). It will however cause that the data is always present in your cache (assuming that you use the callback to refresh), even if you needed this particular piece only once.

In general, you should not try to be too smart about this and just load the cache when you find it empty. That way, you only store data in cache that you actually use every now and then. Only if the time for refreshing get unacceptably long, should you start pre-emptively loading data.

Answer 4

If by ASP.Net Cache callback you refer to SqlCacheDependency, then see this article The Mysterious Notification to understand how the callback works. This link it is a must read if you want to correctly appreciate the cost of the callback. There is not only the cost associated with delivering the notification (firing, delivering, receiving are all database writes), but there is also cost associated with the simply having the notification set up that affects every update/insert/delete statement that touches the cached table. Again, read the linked article for details. How does the callback compare with a refresh? When correctness is added into the picture a callback will run circles around your custom refresh any day or night...

The real question is never Callback vs. Refresh. If you can do callbacks, do callbacks as they will always be more efficient and far less bug prone than a refresh. The real question is to cache or not to cache.