Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Caching / January 2006

Tip: Looking for answers? Try searching our database.

Caching vs public variable for object storage

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
RickG - 19 Jan 2006 15:35 GMT
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.
Joerg Jooss - 19 Jan 2006 21:52 GMT
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.
[quoted text clipped - 4 lines]
> 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,
Signature

Joerg Jooss
news-reply@joergjooss.d

Luke Dalessandro - 20 Jan 2006 21:32 GMT
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 - 20 Jan 2006 21:35 GMT
> 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

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.