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.
14  1740 
> 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.
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.
> 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.
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.
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.
> 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.
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.
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.
> 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.
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/
> 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.
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
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: ton |
last post by:
Hi,
I keep several variables in a statevalue like:
Dim session As SessionState.HttpSessionState =
System.Web.HttpContext.Current.Session
session("connect") = " FKHFSF "
I thought that these...
|
by: Joe Fallon |
last post by:
I have a Shared varibale in a base class and all the Shared methods in the
sub-classes use it (and CHANGE it).
I thought I was saving myself the "trouble" of Dimming this variable inside
each...
|
by: Rob Nicholson |
last post by:
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...
|
by: Iain Mcleod |
last post by:
Hi
This must be an often encountered problem. I want to declare an abstract
class or an interface with nothing but several static constants so that I
can use polymorphism when I call each of them...
|
by: Confused ! |
last post by:
I am writing an ASP.NET application and I want to use shared members on the
data layer to retreive information from the SQL Server.
If I declare a Function to be Shared, how will this affect...
|
by: Mr Newbie |
last post by:
I'm still thinking around this subject, and I find myself unsure about a
couple of things.
When a new users launches an ASP.NET application, this must be on a new
thread. When it encounters a...
|
by: Simon |
last post by:
Hi all,
We have an ASP.NET 1.1 application running on IIS6 on Server 2003.
Most of the base objects we are using in this application are taken from a
windows application also written by us. We...
|
by: gmax2006 |
last post by:
Hi,
I am using RedHat Linux 4. and I developed an oracle 10g based
application by using cx_Oracle (cx_Oracle-4.1-10g-py23-1.i386.rpm) and
Python 2.3.4.
When I run the application through...
|
by: Michael.Thomlinson |
last post by:
Hello fellow coders,
I have run into an issue that is otherwise painfull for my brain to
think about at this point so i turn to you guys for input.
Scenario.
For my application i have...
|
by: netkadirisani |
last post by:
Hi,
i built a dll (used vb.net) that has some shared variables. the basic idea of using the shared variables is to read some values from the database and save them in the shared variables during the...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
