Cache object vs Session, Application state for datagrid

[marina.sukhnev]

Hi Guys!
I have a question to you,if you know...
What is the best way to cache dataset for web application.
Is it Cahce object, session state or application state.
What a pros and cons? Perfomance,Scalability etc.

Thanks a lot,

Marina

 

[Josh Twist]

If you cache something in session state then you'll have one per
session (i.e. one instance per user). If this isn't what you need use
the Cache - it's exactly what it's built to do and comes with heaps of
features like sliding expiration, absolute expiration and is tuned to
work well in a multi-threaded (IIS/ASP.NET) environment.

Josh
http://www.thejoyofcode.com/

 

[marina.sukhnev]

Hi Josh,
Thanks for you reply,
I tried both,Session and Cache,
When I deal with datagrid that bound to dataset that may have about 900
-1000 records and trying to edit,delete,update some rows,very soon I'm
getting out of memory exception. Is 900 rows it too much to handle?
I'm not setting any features for cache or session,just
cache("myds")=ds
session("myds")=ds
Any suggestions?

Thank you,
Marina

 

[Josh Twist]

I doubt it's the 900 rows themselves causing you problems (it's not
that many) and if the dataset wasn't cached you'd have one instance
loaded into memory for each request (so potentially using even more
memory on a busy server).

Maybe there is something about the modification of datasets that makes
it chew up memory?? Also, you need to bear in mind that IIS/ASP.NET is
a multithreaded environment so different threads could be accessing the
dataset at the sametime. MSDN has this to say about the thread safety
of datasets: "This type is safe for multithreaded read operations. You
must synchronize any write operations."

Are you synchronising your write operations? This is a pitfall to
beware of, though I'm not sure this is what would be causing your
memory to be chewed up.

I'm afraid DataSets are not something I use in ASP.NET [see links
below] so It's really not an area I'm very strong in. If I was in your
position now I might use the CLR Profiler to see what's happening to
all your memory:
http://msdn.microsoft.com/library/en-us/dnpag/html/scalenethowto13.asp?frame=true

links
http://aspnet.4guysfromrolla.com/articles/050405-1.aspx
http://aspnet.4guysfromrolla.com/articles/051805-1.aspx

Good luck

Josh
http://www.thejoyofcode.com/

 

[marina.sukhnev]

I doubt it's the 900 rows themselves causing you problems (it's not
that many) and if the dataset wasn't cached you'd have one instance
loaded into memory for each request (so potentially using even more
memory on a busy server).

Maybe there is something about the modification of datasets that makes
it chew up memory?? Also, you need to bear in mind that IIS/ASP.NET is
a multithreaded environment so different threads could be accessing the
dataset at the sametime. MSDN has this to say about the thread safety
of datasets: "This type is safe for multithreaded read operations. You
must synchronize any write operations."

Are you synchronising your write operations? This is a pitfall to
beware of, though I'm not sure this is what would be causing your
memory to be chewed up.

I'm afraid DataSets are not something I use in ASP.NET [see links
below] so It's really not an area I'm very strong in. If I was in your
position now I might use the CLR Profiler to see what's happening to
all your memory:
http://msdn.microsoft.com/library/en-us/dnpag/html/scalenethowto13.asp?frame=true

links
http://aspnet.4guysfromrolla.com/articles/050405-1.aspx
http://aspnet.4guysfromrolla.com/articles/051805-1.aspx

Good luck

Josh
http://www.thejoyofcode.com/

Thanks Josh for your help,
I'll try CLR Profiler...