System.Web.Caching and Datasets

[Guest]

I've been reading about the ASP.NET cache object lately out of personal
curiosity and hope someone would enlighten me on a couple points.

It appears the cache object works at application scope, am I right in
assuming that all sessions on the web server will access the same dataset?
For a web site like ours where customers log in to the site this would be a
problem since a new dataset instance is created for each session.

I've traditionally saved the dataset as a session (object Session["myData"]
= myDS; ) before redirecting to a new page to save the dataset. When I open
the new page, I create the dataset from the session object. Would using the
cache instead be quicker and use less code?

Thanks in advance,

Andre

 

[Karl Seguin]

You are right about the scope, and you are right that how you are using
DataSets (one per-user) isn't exactly aligned with said scope.

However, you don't use the cache object because it's quicker or uses less
code. Rather you use the Cache because it uses a weak reference and doesn't
pin the data in memory. With the cache you kinda say: Is it in the cache.
No? Then go get it from the source. With the session, once something is
added, you are guaranteed it will stay there for the session's life.

As a side note, you can get around the scope of the cache via the cache key.
string cacheKey = "DataSet:" + userId.ToString()

Karl

 

[Guest]

It appears the cache object works at application scope, am I right in
assuming that all sessions on the web server will access the same dataset?
For a web site like ours where customers log in to the site this would be a
problem since a new dataset instance is created for each session.

You are correct. The cache is shared among user sessions. Its the place
where you would store data that is common to all users, such as datasets.
This has the advantage of reducing database load and increasing speed, but it
does require that you take into account the possibility of one user's
modifications of cache objects being seen by another user. That's why all
cached objects should be treated as read only. For instance, in the project
I'm working on, rather than returning datasets from the cache, I return
DataTable.Copy().DefaultView (haven't reached the conclusion that that's the
best solution, tho). I then store the dataview of the copy in each user's
session. A little checking on when said datasets were made and I can assure
that the session holds the freshest data available.

I've traditionally saved the dataset as a session (object Session["myData"]
= myDS; ) before redirecting to a new page to save the dataset. When I open
the new page, I create the dataset from the session object. Would using the
cache instead be quicker and use less code?

No. Storing data in the cache takes the same time and effort that storing
data in the session does. Just remember that you want to keep user specific
data in the session and read-only application specific data in the cache.

What can save you time and code is to abstract your data logic into three
layers -- database, cache, and session. When a page needs data, it requests
it from the session. The session layer looks at the session for the data.
If it is found, its age is compared to the cache data age via the cache
layer. If it is stale, or if it was not found, the data is requested from
the cache layer. The cache layer returns the data from the cache, if found,
or from the database if not. When data is not found in the cache, the cache
layer retrieves it from the database, stores it in the cache (with a callback
method to refresh the data), and returns the data to the session layer. The
session layer then saves the data in the session (updating its age) and
returns the data to the calling page. This is a very simple and straight
forward way to make sure you have the latest data available to your web
pages.