NameValueList in Cache ? Problem

JoOfMetL posted on Thursday, September 07, 2006

I have the impression that that store NameValueList in cache brings problems.   

First case:  

 I use a rich customer and I use a data base located on a remote server. On my station customer, I store the list. I never modify it. Another person that me modifies this list, my list is not up to date any more

Second case :

I use an Internet site.The server store the whole as of the my NameValueList, the memory risk to be saturated  if my data base is of big size?

dean replied on Thursday, September 07, 2006

I believe you are correct in both of your points. The lists should be small and static (or static enough :). In the CSLA 1.0 book I know that Rocky introduced the use of a shared property as a cache as more of a poor man's cache system (don't remember what 2.0 book said). Otherwise you will need to decide what tradeoff's make sense for your system. Certainly there are solutions to the issues you bring up and you may want to search both the old and new forum for more info on these solutions.

Dean

RockfordLhotka replied on Thursday, September 07, 2006

Your first issue is one that is common across any caching technology out there. Stale data in the cache is a problem that needs to be addressed, and data that changes frequently is almost never a good candidate for caching.

There's a thought model for thinking about types of data. I first encountered it when listening to Pat Helland speak at an architect conference. Here's a summary:
 
1) Resource data - mutable data owned by your application - basically the data in your application's database that is edited/maintained by your application
 
2) Reference data - immutuable, versioned, data - data that, if changed, becomes a new version. Think of a price list valid from 1/1 to 6/15, then it changes and you have another price list from 6/15 onward. But the old price list is still there, and is ummutable. Or think of a daily newspaper - once printed it is immutable and versioned.
 
3) Activity data - mutable data being acted upon by your application - basically work-in-progress data - this is basically "resource" data that isn't in the database, along with any transient data needed by the application, but which is never really persisted in the resource database
 
4) Request/response data - data flowing over the wire to/from the database, or to/from a service
 
Using this model, you can get some good clarity on many topics. In the case of caching, the only truly viable type of data is Reference data.

Of course most of us try to cache some Resource data too, and if you are very careful about it you can get away with it - but you always have to remember that your cache can become stale without warning...

Regarding your second point, on the web server, there is a very viable solution there: System.Web.Caching. Microsoft has already built a good caching solution that you can use within ASP.NET. This is often preferable to the Shared/static approach I used in the book because their Cache mechanism will flush itself if the system starts to run low on memory. You can still use the same basic coding structure as I did in the book - just replace the use of a Shared/static field with calls to System.Web.Caching and you are ready to roll.

What isn't immediately obvious, but is pretty cool, is that you can use System.Web.Caching outside ASP.NET as well - even on a smart client! The memory management benefits aren't as great there, but it can be useful still, because they have options for cache expiration, etc.

JoOfMetL replied on Thursday, September 07, 2006

Thank you Rocky for your response.

I think that I will use 'System.Web.Caching'. I did not know.

That solves my second case.

Concerning the first : (rich client) : 
      Reference data : I think that I store the List on the Client.

But for the other types, I don't know how to do to have the list store on the server.

ajj3085 replied on Thursday, March 15, 2007

RockfordLhotka:

What isn't immediately obvious, but is pretty cool, is that you can use System.Web.Caching outside ASP.NET as well - even on a smart client! The memory management benefits aren't as great there, but it can be useful still, because they have options for cache expiration, etc.

Hi,

I was actually looking at doing this for my WinForms application.  Fortunately, I'm on .Net 2 which means that I probably can proceed down this route.  But I did come across this KB article that says you should not use the Cache object outside of Asp.net for .net 1.0 and .net 1.1.

http://support.microsoft.com/kb/917411

HTH
Andy