Re: Scope of Variable Declared Like This?

From: Patrice Scribe (nobody_at_nowhere.com)
Date: 03/17/04


Date: Wed, 17 Mar 2004 18:55:25 +0100

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
>      >>>>>>>>>>>>>>>>>>>>>