ASP.NET sessionstate mix-up, static question

[=?iso-8859-1?B?Sm9oYW4gU2r2c3Ry9m0=?=]

It seems that many people experience problems with mix-ups and
non-intentional sharing of sessions in ASP.NET. This is often tracked
down to the use of static variables for user data, which are indeed
shared and overwritten among all users.

I have this problem as well in one of my applications. However, there
are no static variables, but there are static methods in my (sealed)
SessionStateManager class, like this one:

public static User CurrentUser
{
get
{
if(HttpContext.Current.Session[SessionUser]==null)
{
User currentUser = new User();
HttpContext.Current.Session[SessionUser] = currentUser;
return currentUser;
}
else
{
return (User)HttpContext.Current.Session[SessionUser];
}
}
set
{
HttpContext.Current.Session[SessionUser] = value;
}
}


Will this design cause trouble? I mean, HttpContext.Current.Session
should still be unique, right or wrong?

Cheers,
Johan Sjöström
MSc, MCAD, MCTS, MCITP

 

[Cowboy \(Gregory A. Beamer\)]

I am not sure why you are doing what you are doing, but static methods do
not pose a huge problem. The output will be determined as the routine is run
and it will not, as written, cache anything.


It seems that many people experience problems with mix-ups and
non-intentional sharing of sessions in ASP.NET. This is often tracked
down to the use of static variables for user data, which are indeed
shared and overwritten among all users.

I have this problem as well in one of my applications. However, there
are no static variables, but there are static methods in my (sealed)
SessionStateManager class, like this one:

public static User CurrentUser
{
get
{
if(HttpContext.Current.Session[SessionUser]==null)
{
User currentUser = new User();
HttpContext.Current.Session[SessionUser] = currentUser;
return currentUser;
}
else
{
return (User)HttpContext.Current.Session[SessionUser];
}
}
set
{
HttpContext.Current.Session[SessionUser] = value;
}
}


Will this design cause trouble? I mean, HttpContext.Current.Session
should still be unique, right or wrong?

Cheers,
Johan Sjöström
MSc, MCAD, MCTS, MCITP

 

[=?iso-8859-1?B?Sm9oYW4gU2r2c3Ry9m0=?=]

Thanks Gregory,

I am trying to pin-point the reason why the sessions in my ASP.NET 1.1
web application sometimes get mixed up, i.e. why userA all of the
sudden sees userB's data. This topic has been dealt with before in this
newsgroup, and it often comes down to the (mis)use of static variables.
Some have insinuated that there are bugs in ASP.NET due to the high
frequency of posts similar to this one. More often that not though,
coding errors prove to be the cause.

The example showed one of the typical methods in my SessionStateManager
class. I use static methods but not static variables. Even so, session
mix-ups do occur sometimes. Not often, but too often to be neglected.

But you confirm that this method, as displayed, should be safe to use
in a multi-(inproc)-session web application? (In that case, the error
is elsewhere and is not static-related).

Cheers,
Johan Sjöström
MSc, MCAD, MCTS, MCITP


Cowboy (Gregory A. Beamer) skrev:

 

[bruce barker]

your sample code is thread safe. static methods are fine, only static
data is shared. object methods are really static, they just have access
to the instance data.

another common problem of mixed data is using a sta com object, and not
telling asp.net to use a single thread for each request (aspcompat). of
course the only supported way to use a sta in a webservice is to start
your own thread.


-- bruce (sqlwork.com)

Thanks Gregory,

I am trying to pin-point the reason why the sessions in my ASP.NET 1.1
web application sometimes get mixed up, i.e. why userA all of the
sudden sees userB's data. This topic has been dealt with before in this
newsgroup, and it often comes down to the (mis)use of static variables.
Some have insinuated that there are bugs in ASP.NET due to the high
frequency of posts similar to this one. More often that not though,
coding errors prove to be the cause.

The example showed one of the typical methods in my SessionStateManager
class. I use static methods but not static variables. Even so, session
mix-ups do occur sometimes. Not often, but too often to be neglected.

But you confirm that this method, as displayed, should be safe to use
in a multi-(inproc)-session web application? (In that case, the error
is elsewhere and is not static-related).

Cheers,
Johan Sjöström
MSc, MCAD, MCTS, MCITP


Cowboy (Gregory A. Beamer) skrev:

I am not sure why you are doing what you are doing, but static methods do
not pose a huge problem. The output will be determined as the routine is run
and it will not, as written, cache anything.


It seems that many people experience problems with mix-ups and
non-intentional sharing of sessions in ASP.NET. This is often tracked
down to the use of static variables for user data, which are indeed
shared and overwritten among all users.

I have this problem as well in one of my applications. However, there
are no static variables, but there are static methods in my (sealed)
SessionStateManager class, like this one:

public static User CurrentUser
{
get
{
if(HttpContext.Current.Session[SessionUser]==null)
{
User currentUser = new User();
HttpContext.Current.Session[SessionUser] = currentUser;
return currentUser;
}
else
{
return (User)HttpContext.Current.Session[SessionUser];
}
}
set
{
HttpContext.Current.Session[SessionUser] = value;
}
}


Will this design cause trouble? I mean, HttpContext.Current.Session
should still be unique, right or wrong?

Cheers,
Johan Sjöström
MSc, MCAD, MCTS, MCITP

 

[=?iso-8859-1?B?Sm9oYW4gU2r2c3Ry9m0=?=]

Thanks for the acknowledgement Bruce.

I'll keep looking for other type of coding errors then.

Cheers,
Johan Sjöström
MSc, MCAD, MCTS, MCITP


bruce barker skrev:

your sample code is thread safe. static methods are fine, only static
data is shared. object methods are really static, they just have access
to the instance data.

another common problem of mixed data is using a sta com object, and not
telling asp.net to use a single thread for each request (aspcompat). of
course the only supported way to use a sta in a webservice is to start
your own thread.


-- bruce (sqlwork.com)

Thanks Gregory,

I am trying to pin-point the reason why the sessions in my ASP.NET 1.1
web application sometimes get mixed up, i.e. why userA all of the
sudden sees userB's data. This topic has been dealt with before in this
newsgroup, and it often comes down to the (mis)use of static variables.
Some have insinuated that there are bugs in ASP.NET due to the high
frequency of posts similar to this one. More often that not though,
coding errors prove to be the cause.

The example showed one of the typical methods in my SessionStateManager
class. I use static methods but not static variables. Even so, session
mix-ups do occur sometimes. Not often, but too often to be neglected.

But you confirm that this method, as displayed, should be safe to use
in a multi-(inproc)-session web application? (In that case, the error
is elsewhere and is not static-related).

Cheers,
Johan Sjöström
MSc, MCAD, MCTS, MCITP


Cowboy (Gregory A. Beamer) skrev:

I am not sure why you are doing what you are doing, but static methods do
not pose a huge problem. The output will be determined as the routine is run
and it will not, as written, cache anything.


It seems that many people experience problems with mix-ups and
non-intentional sharing of sessions in ASP.NET. This is often tracked
down to the use of static variables for user data, which are indeed
shared and overwritten among all users.

I have this problem as well in one of my applications. However, there
are no static variables, but there are static methods in my (sealed)
SessionStateManager class, like this one:

public static User CurrentUser
{
get
{
if(HttpContext.Current.Session[SessionUser]==null)
{
User currentUser = new User();
HttpContext.Current.Session[SessionUser] = currentUser;
return currentUser;
}
else
{
return (User)HttpContext.Current.Session[SessionUser];
}
}
set
{
HttpContext.Current.Session[SessionUser] = value;
}
}


Will this design cause trouble? I mean, HttpContext.Current.Session
should still be unique, right or wrong?

Cheers,
Johan Sjöström
MSc, MCAD, MCTS, MCITP