Re: Scope of Variable Declared Like This?

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Kevin Spencer (kevin_at_takempis.com)
Date: 03/17/04 

Date: Wed, 17 Mar 2004 13:42:01 -0500

> My understanding of
> http://samples.gotdotnet.com/quickstart/aspplus/doc/applications.aspx is
> that an ASP.NET application is loaded into a single "application domain",
ie
> all shared variables are really "shared" by all the application instances.

It's called "the heap". The heap is where the class definitions and code are
stored in memory while an assembly is in use. It is like a carbon copy of
the assembly in memory. The Stack is a memory space that sits on top of the
heap, and as classes and methods are instantiated and called, copies of them
are placed on the stack until they are finished executing, at which time
they are removed from the stack. This is how you can have multiple instances
of a single class in memory. Anything which is static is not copied and
placed on the stack, but is used directly from the heap.

The heap is created by the Application as it loads the assemblies it needs.
It is indeed part of the application domain. 

-- 
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
"Patrice Scribe" <nobody@nowhere.com> wrote in message
news:uaZMJkEDEHA.2908@TK2MSFTNGP09.phx.gbl...
> Never saw a definitive word on this.
>
> My understanding of
> http://samples.gotdotnet.com/quickstart/aspplus/doc/applications.aspx is
> that an ASP.NET application is loaded into a single "application domain",
ie
> all shared variables are really "shared" by all the application instances.
>
> My first reaction is to be still reluctant though at storing things in
> shared (static) variables :
> - most often, the cache could be still a better choice for application
wide
> data (easy to reload, may handle priority, remove items under pressure
> etc...)
>
> You can still have type safety by having a class with shared properties
that
> uses the Application, Session, Item or the Cache objects (possibly
restored
> from a database if needed) as the underlying store... (and you have a
unique
> class for the current states whatever scope they have) plus you could use
> use it to wrap synchonization issues...
>
> Still wondering though as it seems to have very litllte materila about
> shared variables vs application state and/or cache ;-)
>
> Patrice
>
> -- 
>
> "Bill Borg" <anonymous@discussions.microsoft.com> a écrit dans le message
de
> news:368473F6-057D-4225-86FC-BD37CE6526D1@microsoft.com...
> > George, thanks for raising this one up; it's a good discussion.  I
learned
> something from your look at what's happening in the public module.  I
> invariably scope to the page level, because it's the norm that I *want*
> these things to be unique to the particular request.
> >
> > To the group:  Does a variable I declare at the module level hold its
> value across sessions and requests the entire time the application is
> running--i.e. in global.asax speak from Application_Start to
> Application_End?  If so, then why isn't that a better way to handle app
> variables, to gain strong typing and (I would guess) better performance
than
> using Application state?
> >
> > Likewise, is it also true that I can trust my shared/static members to
> maintain their values for the entire run of the application?
> >
> >      ----- Kevin Spencer wrote: -----
> >
> >      Modules should be avoided, unless one specifically wants that type
of
> Shared
> >      (static) functionality, and even if so, one would then properly use
a
> class.
> >
> >      -- 
> >      HTH,
> >      Kevin Spencer
> >      ..Net Developer
> >      Microsoft MVP
> >      Big things are made up
> >      of lots of little things.
> >
> >      "Patrice Scribe" <nobody@nowhere.com> wrote in message
> >      news:OXZZGqADEHA.3608@TK2MSFTNGP10.phx.gbl...
> >      > The problem is likely that a module in VB.NET is implemented as a
> class
> >      with
> >      > shared members (if Private how can you check their values ?).
> >      > Under ASP.NET shared members seems to have an application wide
> scope
> >      > (probably because from an ASP.NET point of view, a web app, is a
> *single*
> >      > executing application).
> >      >> I would still suggest to resort to Session, Application or Item
> variables
> >      as
> >      > appropriate. You could wrap data access around a stateless
> class....
> >      >> Patrice
> >      >> -- 
> >      >> "George" <------@----.---> a écrit dans le message de
> >      > news:H7T5c.37700$H44.690872@bgtnsc04-news.ops.worldnet.att.net...
> >      >> Hey Bill,
> >      >>>> Here is what I did for my test, and I am still confused as to
> what,
> >      > exactly, is happening.
> >      >>>> I declared a number of variables and arrays as Friend in that
> Public
> >      > Module at the very top of the
> >      >> page, above the Public Class module, as such:
> >      >>>> Public Module Module1
> >      >>      Friend var as whatever
> >      >>      Friend var1 as whatever
> >      >>      Friend var3(5,5) as whatever
> >      >>      Friend var 4(10,10) as whatever
> >      >>      [and so on]
> >      >> End Module
> >      >>>> Then in the following:
> >      >>>> Public Class aspxPage
> >      >>      [on button clicks, various processing occurs, calculations
> are
> >      made,
> >      > and]
> >      >>      [all the variables and arrays above have values assigned to
> them]
> >      >>      [subsequent button clicks cause more info to be added to
the
> >      arrays]
> >      >> End Class
> >      >>>> If I am understanding you correctly, everytime this page comes
> back from
> >      > the server, all the values
> >      >> in all those Friend variables and arrays should be wiped out,
and
> they
> >      > should be recreated from
> >      >> scratch -- with nothing in them -- right? That is what I assumed
> would
> >      > happen, too, when I did the
> >      >> test.
> >      >>>> If I declare them all Private within and at the top of the
> aspxPage
> >      Class,
> >      > they do get wiped out and
> >      >> recreated from scratch, but that doesn't happen when they are
> declared
> >      as
> >      > Friend in the Public
> >      >> Module.
> >      >>>> The values in all those Friend variables and arrays are
> preserved no
> >      > matter how many round trips are
> >      >> made to the server AND I can access those Friend values from an
> instance
> >      > of a different page class
> >      >> opened at the same time in a different window, although both
pages
> are
> >      in
> >      > the same session. I am not
> >      >> doing anything to facilitate that, either, such as
> saving/restoring
> >      > to/from session variables. As I
> >      >> said, if I am understanding you, that shouldn't be happening.
> >      >>>> What I am needing to do is preserve those values for the life
of
> the
> >      > session, but I do NOT want them
> >      >> to be accessible by other sessions. I know I can use session
> variables
> >      to
> >      > do that, but got curious
> >      >> about this way, and it worked. However, I don't know for sure,
but
> I
> >      > *suspect* those Friends
> >      >> declared like that would be virtually the same as an application
> >      variable,
> >      > and that would make them
> >      >> accessible across multiple sessions, and they may still be left
on
> the
> >      > server from my test. If so,
> >      >> that would mean multiple users in multiple sessions would be
> walking all
> >      > over each other's values. I
> >      >> certainly don't want that because those variables and arrays
will
> hold
> >      > information that is session
> >      >> and user specific.
> >      >>>> I don't have a clear understanding of what's going on here
> (still
> >      > learning), and hope someone can
> >      >> clear it up for me. I have read through the docs and looked on
the
> 'Net,
> >      > but can't seem to find
> >      >> anything specific to this. My gut feeling is Public Module and
> Friend is
> >      > not the way to go. ;-)
> >      >>>> Thanks for your overview.
> >      >> George
> >      >>>>>> "Bill Borg" <anonymous@discussions.microsoft.com> wrote in
> message
> >      >> news:0FD2CCE9-7EA1-48A7-9C9B-B45E2AEBDD2D@microsoft.com...
> >      >>> Hi George,
> >      >>>>>> Not sure if this will help, but my comments:
> >      >>>>>> From what I gather below, you're interchanging "scope" and
> "state",
> >      > which in a Windows app you can
> >      >> typically do because if I can *see* that variable instantiated
in
> >      another
> >      > class somewhere I can go
> >      >> get its value, but *only* because that class instance has
remained
> >      > resident the whole time and so
> >      >> the data's still hanging around.  A variable that I declare at
the
> very
> >      > top (i.e. global)  is one I
> >      >> can use and set throughout the app, and it's there as long as
the
> app is
> >      > there--days, weeks, months,
> >      >> etc.
> >      >>>>>> In an ASP.NET app on the other hand, which is stateless, you
> might
> >      give
> >      > the right scope to your
> >      >> variables so that you can see them across class instances and
> won't get
> >      > squiggly lines, but chances
> >      >> are decent that there's nothing there to see unless you've
planned
> >      > otherwise.  Remember that each
> >      >> time the page loads, a new instance of that page class is
created,
> even
> >      on
> >      > postback, and everything
> >      >> that was there is long gone (it was already gone at page
unload),
> except
> >      > for what either you or MS
> >      >> do to restore state from Viewstate, Session, Application, Cache,
> etc.,
> >      > because for all the app knows
> >      >> you're never coming back.
> >      >>>>>> So, yes, as you say below, each visit to the page generates
a
> *new*
> >      > var1.  One time you can run
> >      >> into conflict is if you are trying to coordinate global values
> across
> >      user
> >      > sessions, such as in
> >      >> Application state, and you've got two people writing to it at
the
> same
> >      > time (e.g.
> >      >> Application("MyGlobalVar")="xyz"), or even two different threads
> within
> >      > the same session.  That's
> >      >> why there's Application.Lock, which forces all threads to hold
off
> on
> >      > accessing the Application
> >      >> object until the locker call Application.Unlock.  If you haven't
> seen
> >      it,
> >      > there's a pretty good
> >      >> discussion of all this under "Application State" in the docs.
One
> line
> >      I
> >      > like:  "unlike for an
> >      >> individual Web page, in which all resources are torn down at the
> >      > conclusion of a Web request".
> >      >> Lends a nice brutality to the whole process.
> >      >>>>>> Anyway, I'm no expert, but hopefully this is some additional
> food for
> >      > thought.
> >      >>> hth,
> >      >>>>>> Bill
> >      >>>>>>      ----- George wrote: -----
> >      >>>>>>      VS.NET 2002/VB
> >      >>>>>>      I am trying to understand the scope of variables and
was
> curious
> >      > about a variable declared as
> >      >> Friend
> >      >>>      in a Public module outside the page class, but within the
> .aspx
> >      > page file, such as:
> >      >>>>>>      Imports System.Whatever
> >      >>>>>>      Public Module Module1
> >      >>>      Friend var1 as Whatever
> >      >>>      End Module
> >      >>>>>>      Public Class aspxPage1
> >      >>>      [various code for the page]
> >      >>>      [var1 will be updated here, too]
> >      >>>      End Class
> >      >>>>>>>>>      Is this type of variable declaration every done?
> >      >>>      What is the scope of var1 when declared like this?
> >      >>>>>>      I know var1 would be accessible to the entire project,
> but does
> >      > that mean that any and all
> >      >> visitors
> >      >>>      that request that page will be using the same var1? And
they
> will
> >      > be walking on each other's
> >      >> var1
> >      >>>      values? Is that somewhat like an application variable? Or
> will
> >      each
> >      > request for that page
> >      >> generate a
> >      >>>      new var1 for each visitor and the scope would be to that
> >      > visitor/session only?
> >      >>>>>>      Thanks,
> >      >>>      George
> >      >>>>>>>>>>>>>>>>>>>>>
>
Quantcast