Variables in multiple sessions

  • Thread starter Thread starter Jacques Oberto
  • Start date Start date
J

Jacques Oberto

Hi All,

[newbie question]
My ASP.NET page does some processing using
data from user input. In the case of multiple
simultanous sessions, will the internal variables
of my application remain isolated between sessions
or is there danger of data mixing?
Thanks,

Jacques
 
Each page request, results in a specific instance of a page class being
created. As with any instance of an object, it's data is isolated from data
in other instances (even if it is another instance of the same kind of
object).

The only time you'll have to worry about one user accessing data that
another use may also be using is when you have a page access a "shared"
memory space, such as application variables or shared data, such as a
database.

-Scott
 
Hi All,

[newbie question]
My ASP.NET page does some processing using
data from user input. In the case of multiple
simultanous sessions, will the internal variables
of my application remain isolated between sessions
or is there danger of data mixing?
Thanks,

Jacques
Click to expand...

Yes, each active session is identified and tracked using a 120-bit
SessionID, generated using an algorithm that guarantees uniqueness.
The SessionID strings are communicated across client-server requests
either by means of an HTTP cookie or a modified URL with the SessionID
string embedded, depending on how you configure the application
settings.

More: http://msdn.microsoft.com/en-us/library/87069683.aspx
 
Hi All,

[newbie question]
My ASP.NET page does some processing using
data from user input. In the case of multiple
simultanous sessions, will the internal variables
of my application remain isolated between sessions
or is there danger of data mixing?
Thanks,

Jacques
Click to expand...
Yes, each active session is identified and tracked using a 120-bit
SessionID, generated using an algorithm that guarantees uniqueness.
The SessionID strings are communicated across client-server requests
either by means of an HTTP cookie or a modified URL with the SessionID
string embedded, depending on how you configure the application
settings.
Click to expand...
More: http://msdn.microsoft.com/en-us/library/87069683.aspx
Click to expand...

I don't believe the OP is asking about session object per se, I believe he's
just asking about the VB or C# code variables that are part of the page's
code, which are contained within each instance of the page.

-Scott
 
"Scott M." a écrit
Each page request, results in a specific instance of a page class being
created. As with any instance of an object, it's data is isolated from
data in other instances (even if it is another instance of the same kind
of object).

The only time you'll have to worry about one user accessing data that
another use may also be using is when you have a page access a "shared"
memory space, such as application variables or shared data, such as a
database.

-Scott
Click to expand...

Hi Scott,

No offense meant but your reply is confusing me. If the page data is
isolated
from data of other page instances, are the application variables isolated as
well or not?
Thanks,

Jacques
 
What are those "internal variables" ?

Static (or VB Shared members) and what you stored in application variables
or in the cache object is shared accross the application (and ASP.NET is a
single app used by multiple users so all users will use the same value). In
other cases, it (such as for session variable) it should be fine.

If you have a problem, tell us what you see, it will be easier to diagnose
than talking about generalities...
 
Jacques Oberto said:
"Scott M." a écrit

Hi Scott,

No offense meant but your reply is confusing me. If the page data is
isolated
from data of other page instances, are the application variables isolated
as
well or not?
Thanks,

Jacques
Click to expand...
Well, I think you need to clarify what type of "variables" you are referring
to. In your original post, you did not mention anything about "application"
variables, which are different from "session" variables, which are different
from the variables you create within your C# or VB .NET code to process the
page.

Application variables are just that, variables that hold data that is
specfic to the application and not any particular user. A hit count is a
good example of data stored at the applicaiton level. It doesn't matter
which user is asking for it, there is only one number that represents the
current hit count and that data needs to be shared across all user sessions.
Applicaiton variables look like this: Application("HitCount") = 1000.

Session variables are also what their name suggests. They are variables that
hold data that is specific to a particular user's session and is held in
memory for the duration of the session. Session variables are used when data
from one request/response cycle needs to be carried into the same visitors
next request/response cycle that is part of the same server session.
Session variables look like this: Session("UserName") = txtUser.Text.

Regular page variables (which is what I thought you were asking about and
what my reply is based on) are the simple variables you create within the
code of your page such as:

Public Class thePage
Inherits System.Web.UI.Page

Dim x As DateTime

Sub Page_Load()
x = DateTime.Now
End Sub

End Class

In this case "x" is a page level variable that holds data specific to this
particular "instance" of the page class and would hold data that is isolated
from other instances of the same page class. If I requested the page and
then you requested the page, the server would create two different instances
of "thePage" class and each instance would have different data in its x
variable that cannot be accessed by the other.

-Scott
 
"Scott M." a écrit
Public Class thePage
Inherits System.Web.UI.Page

Dim x As DateTime

Sub Page_Load()
x = DateTime.Now
End Sub

End Class

In this case "x" is a page level variable that holds data specific to this
particular "instance" of the page class and would hold data that is
isolated from other instances of the same page class. If I requested the
page and then you requested the page, the server would create two
different instances of "thePage" class and each instance would have
different data in its x variable that cannot be accessed by the other.
Click to expand...

Hi Scott,

As I mentioned in my OP, it's the "application variables" I'm interested in.
Your example above makes everything crystal clear.
Thank you for your help.

Jacques
 
"Patrice" a écrit dans
What are those "internal variables" ?

Static (or VB Shared members) and what you stored in application variables
or in the cache object is shared accross the application (and ASP.NET is a
single app used by multiple users so all users will use the same value).
In other cases, it (such as for session variable) it should be fine.

If you have a problem, tell us what you see, it will be easier to diagnose
than talking about generalities...
Click to expand...


Hi Patrice,

What you are saying seems to differ from the VB example + explanation given
by Scott M in this same thread. It looks like I am not the only one to have
problems with this...

Jacques
 
Hi All,

[newbie question]
My ASP.NET page does some processing using
data from user input. In the case of multiple
simultanous sessions, will the internal variables
of my application remain isolated between sessions
or is there danger of data mixing?
Click to expand...

If you have attached the data to a session, then they cannot cross
contaminate via the session variables.

Except, if you have a piece of state (Property/Field) marked as static
(C#) or Shared (VB), as those are part of the class and not part of the
object created from the class (ie, they are shared amongst all
instances).

In other words:

public class MyClass
{
public static MyVariable { get; set; }
}

will shared across all instances, even if you have the following:

Session["MyClass"] = instanceOfMyClass;

Peace and Grace,


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
"Gregory A. Beamer" a écrit
If you have attached the data to a session, then they cannot cross
contaminate via the session variables.

Except, if you have a piece of state (Property/Field) marked as static
(C#) or Shared (VB), as those are part of the class and not part of the
object created from the class (ie, they are shared amongst all
instances).

In other words:

public class MyClass
{
public static MyVariable { get; set; }
}

will shared across all instances, even if you have the following:

Session["MyClass"] = instanceOfMyClass;
Click to expand...

I got it now. Thanks Gregory.

Jacques
 
Jacques Oberto said:
"Patrice" a écrit dans


Hi Patrice,

What you are saying seems to differ from the VB example + explanation
given
by Scott M in this same thread. It looks like I am not the only one to
have
problems with this...

Jacques
Click to expand...

Patrice is talking about yet another form of data storage, but not quite a
variable. It doesn't conflict with what I've said it's just an additional
way that data can be shared. It doesn't change my previous description.

This really isn't something that there is a lot of confusion on. You pick
the right kind of storage for the persistence you need.

Applicaiton level persistence = appliation variables
per user persistence = session variables / cookies
per page persistence = page level variables

-Scott
 
As Scott said, it's just that "internal variable" is no clear enough.


I didn't catch that "internal variables of my application" were just what we
call just "application variables" (i.e. stored in the Application object)
and I was suspected you were using shared or static variables (which is
still something else)...


They are specifically done to be shared accross the whole application so if
this is a "danger" you shoudl use something else...
 
"Patrice" a écrit
I didn't catch that "internal variables of my application" were just what
we call just "application variables" (i.e. stored in the Application
object) and I was suspected you were using shared or static variables
(which is still something else)...


They are specifically done to be shared accross the whole application so
if this is a "danger" you shoudl use something else...
Click to expand...


Hi Patrice,

Please notice that your reply can be interpreted <again> in opposite ways.
"They" in the second paragraph refers to what?
-application variables
or
-shared and static variables

????

Thanks,

Jacques
 
Please notice that your reply can be interpreted said:
"They" in the second paragraph refers to what?
-application variables
or
-shared and static variables
Click to expand...

Both, actually "application variables" are stored in a container that is
available accross the whole application. So all sessions will have access to
them.

A static or shared member is a class member. As a class (and not instance)
member it has a single value that is available to the whole application (and
as an ASP.NET app is a single application, all sessions will have access to
them).

I realize also that "Application variables" have a specific meaning when
used in the context of ASP/NET :
http://support.microsoft.com/kb/309018/en-us (that is variable stored in the
"Application" container)

Sorry for being unclear.
 
Jacques Oberto said:
"Patrice" a écrit



Hi Patrice,

Please notice that your reply can be interpreted <again> in opposite ways.
"They" in the second paragraph refers to what?
-application variables
or
-shared and static variables

????

Thanks,

Jacques
Click to expand...


A "shared" or "static" piece of data, which *could* be called a variable,
but is more often referred to as a class level "field" or "property" is
simply a piece of data that resides with the type and no particular
"instance" of that type.

While I don't think this is what you initially were asking about, since it's
come up, you should be clear on what it is.

The best example of this would be getting the current date and time. Rather
than making an "instance" of a DateTime type, you access the "Now" property
directly against the type without making an instance of it, as in:

DateTime.Now

Rather than:

Dim x As New DateTime
Dim theTime as DateTime = x.Now

Since anyone wanting the current date and time would need the same
information (albeit a changing peice of information) anyone just gets the
data directly from the type and as the data in the type changes (in this
case the current time is changing all the time), you don't go through an
instance to get the data, you just get it through the type.

In this way, the data is "shared" across all instances of the type and if
the data gets changed anywhere, it gets changes everywhere.

-Scott
 
Back
Top