caching/state management

[baffled]

I have both datatables and custom objects that are specific to a session and
need to be cached for such things as paging, sorting, etc... As far as I
can tell, there would be 2 basic ways to do
this:

1. Use session state to store these objects.
2. Use the System.Web.Cach ing namespace to cache the objects using a session
specific key.

So, is one of these approaches better (more efficient & scalable) than the
other or is there another approach the is best? Using the database is not a
viable option for a variety of reasons, including query speed and load...

Thanks

[Karl Seguin [MVP]]

They are both viable solutions, they both have advantages. Session specific
keys can be ugly and messy. I wish that there was a SessionCache that took
the wonderfulness of the cache object, and made it session-based. On the
flip side, sessions pin stuff in memory. I much prefer the cache approach,
where you aren't guaranteed it'll be there. By using weak references, the
Cache allows ASP.NET to manage it's own memory much better than the session
object does. You have to code more defensively (check if it's in the cache
first, since it might not be), but in the end it's much more powerful code.

Also, remember, Sessions scale better because you can go out of process if
you need to, cache object is always going to be per-machine. Use the
session object if you think you might need to go out of process.

Without knowing more details, I'd probably go the way of the cache.

You could built a wrapper than abstacts the implemnentation , thus letting
you switch between the two easily.

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"baffled" <ba*****@discus sions.microsoft .com> wrote in message
news:7E******** *************** ***********@mic rosoft.com...

I have both datatables and custom objects that are specific to a session
and
need to be cached for such things as paging, sorting, etc... As far as I
can tell, there would be 2 basic ways to do
this:

1. Use session state to store these objects.
2. Use the System.Web.Cach ing namespace to cache the objects using a
session
specific key.

So, is one of these approaches better (more efficient & scalable) than the
other or is there another approach the is best? Using the database is not
a
viable option for a variety of reasons, including query speed and load...

Thanks

[Matt Dinovo]

It depends on the scope of the cached data. If it's a per user scope, then
you might use the session; on a per application scope, then the data cache
would be a better option. From your post, it looks like it's per-session
scope (since you mentioned the "session specific key"). In this case you
want to use the session state -- if you used the data cache and mis-handled
your expiration, then your cached object could live far beyond the scope of
the session impacting performance.

Hope this helps,

Matt Dinovo

"baffled" <ba*****@discus sions.microsoft .com> wrote in message
news:7E******** *************** ***********@mic rosoft.com...

I have both datatables and custom objects that are specific to a session
and
need to be cached for such things as paging, sorting, etc... As far as I
can tell, there would be 2 basic ways to do
this:

1. Use session state to store these objects.
2. Use the System.Web.Cach ing namespace to cache the objects using a
session
specific key.

So, is one of these approaches better (more efficient & scalable) than the
other or is there another approach the is best? Using the database is not
a
viable option for a variety of reasons, including query speed and load...

Thanks