[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.aspnet.caching

Caching vs public variable for object storage

RickG

1/19/2006 3:35:00 PM

Can anybody clarify this please.
Is there any problem in a web app of saving an object in a public variable
as opposed to saving it in the cache?

In my case, I have an object containing a hash table of text labels and
their keys which I save in a public variable.

Any access to the object causes it to check if it has been initialised, and
if not it loads the hash table from the database, at which point it logs a
message to indicate the load has occurred. On examination of the log, I only
see it load once when the application starts, which is waht I want it to do.

The question is, am I going to have some problem doing it this way, and if
not, what benefit does the cache object have?

Thanks
Rick Gwadera
Software designer, programmer etc.
3 Answers

Joerg Jooss

1/19/2006 9:53:00 PM

0

Hello RickG,

> Can anybody clarify this please. Is there any problem in a web app of
> saving an object in a public variable as opposed to saving it in the
> cache?

A member's protection level is meaningless in this context. And using public
member is a plain aweful practice :-S

> In my case, I have an object containing a hash table of text labels
> and their keys which I save in a public variable.
>
> Any access to the object causes it to check if it has been
> initialised, and if not it loads the hash table from the database, at
> which point it logs a message to indicate the load has occurred. On
> examination of the log, I only see it load once when the application
> starts, which is waht I want it to do.

You didn't write in what kind of class you have created this public variable.
Is it static as well?

> The question is, am I going to have some problem doing it this way,
> and if not, what benefit does the cache object have?

If the hashtable was a non-static member of a Page class, it's lifetime would
be one HTTP request/response exchange. Thus, every page hit would become
a database hit. The cache on the other hand persists objects throughout the
ASP.NET's worker process lifetime (sort of a simplified view, but anyway).
Thus, there'll be only one database hit for as long as your hashtable isn't
removed from the cache.

Yes, you can get the same basic lifetime behaviour with a static class member,
but not cache's advanced functionality like automatic removal of "aged" objects
if you're running low on memory, depedencies on external resources like files
etc.

Cheers,
--
Joerg Jooss
news-reply@joergjooss.de

Luke Dalessandro

1/20/2006 9:32:00 PM

0

RickG,

>
>> Can anybody clarify this please. Is there any problem in a web app of
>> saving an object in a public variable as opposed to saving it in the
>> cache?

It certainly sounds like it's a static variable, particularly if you are
only seeing it initialized once.

>
> Yes, you can get the same basic lifetime behaviour with a static class
> member, but not cache's advanced functionality like automatic removal of
> "aged" objects if you're running low on memory, depedencies on external
> resources like files etc.
>

This is the real kicker. With the cache you can add a cache dependency
so that the hash is automatically re-loaded when the database changes. I
believe that if you are using SqlServer you can reduce the granularity
of the cache dependency to the table level, though I don't actually use
it much.

Now all of a sudden, you have a hash that appears to be static to the
world, but is updated when necessary.

Typically something like:

using System.Web.Hosting;

public static MyHashType Hash
{
get
{
MyHashType hash = HostingEnvironment.Cache["theKey"] as MyHashType;

if (null == hash)
{
hash = LoadHash();
HostingEnvironment.Cache.Insert("theKey", hash, new
CacheDependency()); // initialize the dependency as you'd like
}

return hash;
}
}

private static MyHashType LoadHash()
{
... does the db work
}

It's basically a lazy load, with built in hashing. The only caveat is
that an external call that needs to look up many things might want to
get a local copy of the cache object, rather than calling the property
directly all of the time.

Hope this makes things easier,
Luke

Luke Dalessandro

1/20/2006 9:35:00 PM

0

> It's basically a lazy load, with built in hashing. The only caveat is

Err.. that should read "built in caching" rather than "built in hashing"
of course.

Luke