1. Is this the best and fastest approach?
best: it depends
fastest: it depends
also the 2 are mutually exclusive. the best approach may not be the fastest and vice versa.
2. Is locks working the same way in ASP.NET so I can create any static object as look and then prevent HTTP requests to retrieve/update a static dictionary while another request is updating it?
i'm having difficulty understanding this statement? you will always have request/response anytime you retrieve data from the server. that is asp.net. if you roll your own's cache then you need to consider locking. if you use asp.net cache locking it built in.
if you roll your own you also need to consider how you will be expiring the cache. As data becomes stale you need to reload it.
I view caching as a last resort option to loading data. I optimize my data access/processing as much as possible before I implement caching. Once I do implement caching I try to be as conservative as possible.
here are some factors to consider:
1. is data access the bottleneck? profiling the application with a tool like JetBrain's DotTrace or Ant's Profiler will show me where my pain points are and how much latency they introduce.
2. is there a notably, perceived improvement by caching data? if not then it's not worth it.
3. what is the cost of caching on the web server vs. querying the database? how much data? how long will it be cached? where will it be cached?
4. how will caching influence the overall architecture of my system? If all the code is forced into code behind (assuming webforms) then caching will only make the code more difficult to understand. if the system has any amount of SoC then caching should be able to fit easily into the system without too much disruption to the overall code base. in other words the presentation layer shouldn't know whether the data is cached or not, it should only receive the data.
Jason Meckley
Programmer
Specialty Bakers, Inc.
faq855-7190
faq732-7259
