By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,885 Members | 1,469 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,885 IT Pros & Developers. It's quick & easy.

Shared variables in ASP.NET environment

P: n/a
A consequence of the ASP.NET architecture on IIS has just hit home with a
big thud. It's to do with shared variables. Consider a module like this:

Public Module Functions

Public GlobalName As String ' this is ineffect a global
application object

End Module

As there is one aspnet_wp.exe process shared by all users, would all users
access the same GlobalName variable. So if user A runs the application and
sets it to "Fred" and user B sets it to "Bert", then User A sees the new
value?

This this right?

Cheers, Rob.
Nov 21 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a
> As there is one aspnet_wp.exe process shared by all users, would all users
access the same GlobalName variable. So if user A runs the application and
sets it to "Fred" and user B sets it to "Bert", then User A sees the new
value?


Answering my own question but yes, this is what happens. All users access
the same shared variables...

Cheers, Rob.
Nov 21 '05 #2

P: n/a
Hi,

Store it in session state.

Session("GlobalName")="Rob Nicholson"

http://msdn.microsoft.com/library/de...ssionstate.asp

Ken
------------------
"Rob Nicholson" <in******@community.nospam> wrote in message
news:et**************@TK2MSFTNGP10.phx.gbl...
A consequence of the ASP.NET architecture on IIS has just hit home with a
big thud. It's to do with shared variables. Consider a module like this:

Public Module Functions

Public GlobalName As String ' this is ineffect a global
application object

End Module

As there is one aspnet_wp.exe process shared by all users, would all users
access the same GlobalName variable. So if user A runs the application and
sets it to "Fred" and user B sets it to "Bert", then User A sees the new
value?

This this right?

Cheers, Rob.

Nov 21 '05 #3

P: n/a
> Session("GlobalName")="Rob Nicholson"

Hi Ken - I thought about that but the problem was that the variable was
needed deep in a middle tier layer which, I didn't think, new about the
current session. However, I then found:

System.Web.HttpContext.Current.Session("GlobalName ")

which means the middle tier can get at the session cache without having to
pass a pointer to it all over the place.

I assume that System.Web.HttpContext.Current is in effect a shared (static)
property that's available process wide and returns the HttpContext object
for the current request being processed which in turn gives the user's own
session state.

Cheers, Rob.
Nov 21 '05 #4

P: n/a
I clarified this for you a minute ago in another thread. However, I will
repeat my clarification for you:

"Global" and "Shared" are 2 different terms, with 2 different meanings. An
object with global scope (accessibility) may or may not be thread-safe. A
static (Shared) object is certainly NOT thread-safe. Now, this is not the
issue which you addressed specifically, but I am not sure what you meant by
the term "Shared." Any Shared (static) memeber of any class in an
application is, by definition, globally scoped to the application. You don't
even need to create an instance of it, or any class it may reside in. If the
class is included in your application, it is available to the entire
application, and it is globally scoped.

Putting an object into the Application Collection (which, BTW, is not
thread-safe in itself), or into the Application Cache (which is thread-safe
in itself) makes the object global to the application as well. However, in
this case, it is an instance of a class, not a singleton object residing in
the application heap. If you put an object into the Application Collection
or Application Cache, and the object itself is not thread-safe (such as a
Collection, for example), you will run into a whole different set of
problems, as multiple threads may try to access the object at the same time.
A Collection is the easiest example to illustrate. Imagine one thread
attempting to iterate through a Collection while another thread is removing
an item from the Collection.

Now, your remark is in regards to the fact that putting an object into the
Application Collection or the Application Cache makes it globally available,
and thus, when one thread changes its value, it is changed for all threads.
And that is indeed a problem, if you plan to change its value in, for
example, any page used by any user in your app. I just wanted you to
understand the terms, and the possible issues you may encounter.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

"Rob Nicholson" <in******@community.nospam> wrote in message
news:et**************@TK2MSFTNGP10.phx.gbl...
A consequence of the ASP.NET architecture on IIS has just hit home with a
big thud. It's to do with shared variables. Consider a module like this:

Public Module Functions

Public GlobalName As String ' this is ineffect a global
application object

End Module

As there is one aspnet_wp.exe process shared by all users, would all users
access the same GlobalName variable. So if user A runs the application and
sets it to "Fred" and user B sets it to "Bert", then User A sees the new
value?

This this right?

Cheers, Rob.

Nov 21 '05 #5

P: n/a
CORRECTION!

Sorry to make my clarification unclear, but that last paragraph certainly
WAS unclear (and incorrect). I said that you were referring to using the
Application to store objects, when, in fact, you were referring to a Module,
which, by definition, contains all Shared (static) members. And, of course,
you wouldn't be storing Module members in the Application!

Apologies,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

"Rob Nicholson" <in******@community.nospam> wrote in message
news:et**************@TK2MSFTNGP10.phx.gbl...
A consequence of the ASP.NET architecture on IIS has just hit home with a
big thud. It's to do with shared variables. Consider a module like this:

Public Module Functions

Public GlobalName As String ' this is ineffect a global
application object

End Module

As there is one aspnet_wp.exe process shared by all users, would all users
access the same GlobalName variable. So if user A runs the application and
sets it to "Fred" and user B sets it to "Bert", then User A sees the new
value?

This this right?

Cheers, Rob.

Nov 21 '05 #6

P: n/a
> the term "Shared." Any Shared (static) memeber of any class in an
application is, by definition, globally scoped to the application. You don't

Actually, this is in a module and I assume that modules are in effect
shared:

Public Module Functions

Public GlobalName As String

End Module

Functions.GlobalName appears to be accessible from everywhere.
understand the terms, and the possible issues you may encounter.


We were using something akin to above but actually storing a reference to
our own application object so actually we had:

Public Module Functions

Public GlobalApp As OurApp

End Module

This was a no-no as all users (sessions) started sharing the same OurApp
which could have started the thread-safe problems you describe, e.g. one
user could clear OurApp.BigCollection whilst another user was using it.

I've made a simple change to our application environment to store OurApp in
the session cache instead which, AFAIK, will be fine as each other now gets
their own instance of OurApp.

Realising that all users are running in the same process with the same
instance of the DLLs et all plus shared memory and heap was a important
realisation for me. The penny dropped.

I've done a fair amount of multi-thread stuff in the past but not thought
about it too much in the ASP.NET environment.

Cheers, Rob.
Nov 21 '05 #7

P: n/a
Hi Rob,

Yes, see my self-correction which I posted almost immediately after the post
you reponded to. I realized that you were not talking about using the
Application to store data, but a Module. It is true that every member of a
Module is Shared (static), a singleton that is available throughout the
application.

Modules are a special kind of class, another accomodation of Microsoft for
VB6 developers. However, it is not good practice to use Modules at all, as
they present no accessibility control whatsoever. In addition, they often
confuse VB developers who are accustomed to using them in executable
applications, and do not understand the consequences of using them is a web
application, particularly one that is multi-threaded. Instead, use classes.
You can create classes which have both Shared (static) members and members
with other (instance-type) accessibility as well, which gives you full
control over the members in the class.

Shared (static) objects present a number of difficulties in a multi-threaded
environment. That is not to say that they are not useful. Shared methods,
for example, are often quite useful, as they reduce the stack size, and
therefore memory usage. Shared fields and properties are problematic, but
useful in certain situations (particularly when the classes which use them
do not change them). One excellent way of making sure that client classes do
not change them is to create a private Shared field, and expose it via a
public Shared read-only property. Example:

Public Class Foo

Private Shared _Bar As String
Public Shared ReadOnly Property Bar() As String
Get
Return _Bar
End Get
End Property

' Public Constructor
Public Shared Sub New()

End Sub

' Shared Constructor
Shared Sub New()
_Bar = "Foo Bar"
End Sub

End Class

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

"Rob Nicholson" <in******@community.nospam> wrote in message
news:e2**************@TK2MSFTNGP12.phx.gbl...
the term "Shared." Any Shared (static) memeber of any class in an
application is, by definition, globally scoped to the application. You

don't

Actually, this is in a module and I assume that modules are in effect
shared:

Public Module Functions

Public GlobalName As String

End Module

Functions.GlobalName appears to be accessible from everywhere.
understand the terms, and the possible issues you may encounter.


We were using something akin to above but actually storing a reference to
our own application object so actually we had:

Public Module Functions

Public GlobalApp As OurApp

End Module

This was a no-no as all users (sessions) started sharing the same OurApp
which could have started the thread-safe problems you describe, e.g. one
user could clear OurApp.BigCollection whilst another user was using it.

I've made a simple change to our application environment to store OurApp
in
the session cache instead which, AFAIK, will be fine as each other now
gets
their own instance of OurApp.

Realising that all users are running in the same process with the same
instance of the DLLs et all plus shared memory and heap was a important
realisation for me. The penny dropped.

I've done a fair amount of multi-thread stuff in the past but not thought
about it too much in the ASP.NET environment.

Cheers, Rob.

Nov 21 '05 #8

P: n/a
Kevin,

I can be mistaken however reading your messages, are you in my opinion
missing the point which is that a shared variable in an ASPNET persistent
however it is part of the application (as it is everywhere), however in
ASPNET belongs an application to all clients.

Persistent to a client action (postback) in ASPNET are
A viewstate item (belongs to the page)
A session item (belongs as IIS part to the client)
A shared variable (belongs to the application)
A cache item (is used by the total application)

A global item in ASNET is not persistent in the way as windowsforms where it
is almost forever persitent.

I hope this helps,

Cor

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:uo*************@TK2MSFTNGP12.phx.gbl...
Hi Rob,

Yes, see my self-correction which I posted almost immediately after the
post you reponded to. I realized that you were not talking about using the
Application to store data, but a Module. It is true that every member of a
Module is Shared (static), a singleton that is available throughout the
application.

Modules are a special kind of class, another accomodation of Microsoft for
VB6 developers. However, it is not good practice to use Modules at all, as
they present no accessibility control whatsoever. In addition, they often
confuse VB developers who are accustomed to using them in executable
applications, and do not understand the consequences of using them is a
web application, particularly one that is multi-threaded. Instead, use
classes. You can create classes which have both Shared (static) members
and members with other (instance-type) accessibility as well, which gives
you full control over the members in the class.

Shared (static) objects present a number of difficulties in a
multi-threaded environment. That is not to say that they are not useful.
Shared methods, for example, are often quite useful, as they reduce the
stack size, and therefore memory usage. Shared fields and properties are
problematic, but useful in certain situations (particularly when the
classes which use them do not change them). One excellent way of making
sure that client classes do not change them is to create a private Shared
field, and expose it via a public Shared read-only property. Example:

Public Class Foo

Private Shared _Bar As String
Public Shared ReadOnly Property Bar() As String
Get
Return _Bar
End Get
End Property

' Public Constructor
Public Shared Sub New()

End Sub

' Shared Constructor
Shared Sub New()
_Bar = "Foo Bar"
End Sub

End Class

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.

"Rob Nicholson" <in******@community.nospam> wrote in message
news:e2**************@TK2MSFTNGP12.phx.gbl...
the term "Shared." Any Shared (static) memeber of any class in an
application is, by definition, globally scoped to the application. You

don't

Actually, this is in a module and I assume that modules are in effect
shared:

Public Module Functions

Public GlobalName As String

End Module

Functions.GlobalName appears to be accessible from everywhere.
understand the terms, and the possible issues you may encounter.


We were using something akin to above but actually storing a reference to
our own application object so actually we had:

Public Module Functions

Public GlobalApp As OurApp

End Module

This was a no-no as all users (sessions) started sharing the same OurApp
which could have started the thread-safe problems you describe, e.g. one
user could clear OurApp.BigCollection whilst another user was using it.

I've made a simple change to our application environment to store OurApp
in
the session cache instead which, AFAIK, will be fine as each other now
gets
their own instance of OurApp.

Realising that all users are running in the same process with the same
instance of the DLLs et all plus shared memory and heap was a important
realisation for me. The penny dropped.

I've done a fair amount of multi-thread stuff in the past but not thought
about it too much in the ASP.NET environment.

Cheers, Rob.


Nov 21 '05 #9

P: n/a
> VB6 developers. However, it is not good practice to use Modules at all, as
they present no accessibility control whatsoever. In addition, they often


We don't use them much at all - our Functions module has just three system
wide modules. And in fact, they could probably be included in the basic App
class anyway. I saw the OOPs light many years ago :-)

Cheers, Rob.
Nov 21 '05 #10

P: n/a
On Thu, 15 Sep 2005 17:09:05 +0200, "Cor Ligthert [MVP]"
<no************@planet.nl> wrote:

A global item in ASNET is not persistent in the way as windowsforms where it
is almost forever persitent.


How do you define a global item?

A field declared as static in C#, or shared in VB.NET, behaves exactly
the same in ASP.NET and forms based applications. The field will be
around for the duration of the application domain.
--
Scott
http://www.OdeToCode.com/blogs/scott/

Nov 21 '05 #11

P: n/a
> I can be mistaken however reading your messages, are you in my opinion
missing the point which is that a shared variable in an ASPNET persistent
however it is part of the application (as it is everywhere), however in
ASPNET belongs an application to all clients.
Missing WHAT point? What exactly is THE point?

Persistence and Scope are 2 rntirely different topics.

The scope of my discussion was confined to the scope and behavior of various
types of global objects. Of course, I did mention that Shared (static)
objects reside in the application heap, which implies, of course, that they
are permanently memory-resident for the lifetime of the application.
A global item in ASNET is not persistent in the way as windowsforms where
it is almost forever persitent.
Your use of the term "global" is ambiguous. "Global" scope refers to any of
several different types of scope. An object can be scoped globally to a
page, to a Session, to an application, to a machine, to a domain, to an
enterprise, or to the entire Internet. Assuming that we are confining our
discussion to an ASP.Net web application, that still leaves Page scope,
Session scope, and Application scope.

Items stored in the Application Collection are persistent throughout the
lifetime of the Application , just like Windows Forms. Shared (static) items
are also persistent throughout the lifetime of the Application , just like
Windows Forms. Instantiated items stored in the Application Cache can be
persistent for as short or as long a time as the developer requires,
including the lifetime of the Application, just like Windows Forms.
Instantiated items stored in Session are persistent throughout the lifetime
of the Session.

None of these facts contradicts my (and Microsoft's) recommendations
regarding the use of Modules or Shared (static) objects. Of course, I can
only guess that this is what you are taking issue with here.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:ep*************@TK2MSFTNGP10.phx.gbl... Kevin,

I can be mistaken however reading your messages, are you in my opinion
missing the point which is that a shared variable in an ASPNET persistent
however it is part of the application (as it is everywhere), however in
ASPNET belongs an application to all clients.

Persistent to a client action (postback) in ASPNET are
A viewstate item (belongs to the page)
A session item (belongs as IIS part to the client)
A shared variable (belongs to the application)
A cache item (is used by the total application)

A global item in ASNET is not persistent in the way as windowsforms where
it is almost forever persitent.

I hope this helps,

Cor

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:uo*************@TK2MSFTNGP12.phx.gbl...
Hi Rob,

Yes, see my self-correction which I posted almost immediately after the
post you reponded to. I realized that you were not talking about using
the Application to store data, but a Module. It is true that every member
of a Module is Shared (static), a singleton that is available throughout
the application.

Modules are a special kind of class, another accomodation of Microsoft
for VB6 developers. However, it is not good practice to use Modules at
all, as they present no accessibility control whatsoever. In addition,
they often confuse VB developers who are accustomed to using them in
executable applications, and do not understand the consequences of using
them is a web application, particularly one that is multi-threaded.
Instead, use classes. You can create classes which have both Shared
(static) members and members with other (instance-type) accessibility as
well, which gives you full control over the members in the class.

Shared (static) objects present a number of difficulties in a
multi-threaded environment. That is not to say that they are not useful.
Shared methods, for example, are often quite useful, as they reduce the
stack size, and therefore memory usage. Shared fields and properties are
problematic, but useful in certain situations (particularly when the
classes which use them do not change them). One excellent way of making
sure that client classes do not change them is to create a private Shared
field, and expose it via a public Shared read-only property. Example:

Public Class Foo

Private Shared _Bar As String
Public Shared ReadOnly Property Bar() As String
Get
Return _Bar
End Get
End Property

' Public Constructor
Public Shared Sub New()

End Sub

' Shared Constructor
Shared Sub New()
_Bar = "Foo Bar"
End Sub

End Class

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.

"Rob Nicholson" <in******@community.nospam> wrote in message
news:e2**************@TK2MSFTNGP12.phx.gbl...
the term "Shared." Any Shared (static) memeber of any class in an
application is, by definition, globally scoped to the application. You
don't

Actually, this is in a module and I assume that modules are in effect
shared:

Public Module Functions

Public GlobalName As String

End Module

Functions.GlobalName appears to be accessible from everywhere.

understand the terms, and the possible issues you may encounter.

We were using something akin to above but actually storing a reference
to
our own application object so actually we had:

Public Module Functions

Public GlobalApp As OurApp

End Module

This was a no-no as all users (sessions) started sharing the same OurApp
which could have started the thread-safe problems you describe, e.g. one
user could clear OurApp.BigCollection whilst another user was using it.

I've made a simple change to our application environment to store OurApp
in
the session cache instead which, AFAIK, will be fine as each other now
gets
their own instance of OurApp.

Realising that all users are running in the same process with the same
instance of the DLLs et all plus shared memory and heap was a important
realisation for me. The penny dropped.

I've done a fair amount of multi-thread stuff in the past but not
thought
about it too much in the ASP.NET environment.

Cheers, Rob.



Nov 21 '05 #12

P: n/a
Kevin,

You are replying your own messages. Read mine, I don't write that you are
wrong in your answers. I only write that you are in my opinion missing the
most important factor (point). An Aspnet application (the dll) belongs to
all clients, a windowsform (UI) application (the exe) to one client.

Cor
Nov 21 '05 #13

P: n/a
I'm not missing anything, Cor. Not missing any points, not misunderstanding
anything.

If you want to believe what you're saying, you are welcome to. I might point
out, for example, though, that a DLL is not an application. It is a file
containing code that is loaded into the application memory when the
application starts. And that there are quite a few more than one DLL loaded
when the application starts, most of them in the Global Assembly Cache, and
often more than one in the Application bin folder. And that clients, in the
case of ASP.Net, are HTTP client applications residing outside of the
Application domain of an ASP.Net application, and therefore, have no access
at all to the ASP.Net application.

Finally, this is not helpful to the OP, and it's just plain irritating to
me, so how about quitting?

--

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:Oa**************@TK2MSFTNGP09.phx.gbl...
Kevin,

You are replying your own messages. Read mine, I don't write that you are
wrong in your answers. I only write that you are in my opinion missing the
most important factor (point). An Aspnet application (the dll) belongs to
all clients, a windowsform (UI) application (the exe) to one client.

Cor

Nov 21 '05 #14

P: n/a
Kevin,

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:ud***************@tk2msftngp13.phx.gbl..
..
I'm not missing anything, Cor. Not missing any points, not
misunderstanding > anything.


What can I add to this, so I don't do it, you show it yourself to good.

Cor
Nov 21 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.