What problems might I encounter by using the HttpCache to buffer data from a web service, as opposed to storing the same data in a database table? In a hypothetical situation whereby the service was temporarily unavailable, if the server needed to reboot during that time there would be no way to re-populate the cache. So for that reason, is it possible to persist the cache like you could do with SqlServer Session state?
I read the HttpCache is implemented using the Singleton 开发者_运维问答pattern. Does that mean I should be using Mutex when working with objects coming from the cache?
What will happen if the cache is being updated on the one hand by a separate threaded process while also being read by a different thread?
Thanks.
The biggest problem you'll encounter with a caching mechanism is stale data. Since data is cached, it can be as old as the cache lifetime. In transactional systems, this is unacceptable, but for other systems, it's fine. Just understand how old the data is. I don't know if the cache can be persisted, but if you're thinking of going to a database to do so, I would recommend against using a cache in the first place, since part of the point is fast in-memory access to your data.
Yes, caching uses a centralized in-memory store like a Singleton. The answer to your question on Mutexes is that it depends on your data access patterns. Most people use caches to populate data once. If the value times out, the cache nulls out their entry and they repopulate. Yes, you could protect the access with a Mutex (or more likely a lock
statement) to prevent multiple clients from racing to populate the cache all at once. But IMO that's more of a performance point than a data-consistence point, since in all probability the clients will be writing over one another with the same data (again, it does depend on your situation).
精彩评论