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.
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.