471,573 Members | 1,717 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,573 software developers and data experts.

SQLSession vs InProcess Session State object references problem (C#)

Hello!

I have a problem with SQLSession state on my ASP.NET pages.

SQLSession state behaves very different from InProcess session state,
which I think is very bad.

I can understand some of the differences, e.g that every object you
store in SQLSession state have to be serializable, but other
differences are very unfortunate.

Look at the following Example:
// Page_Load
....
if(!IsPostBack)
{
Session["A"] = "A";
Session["B"] = Session["A"];
bool aEqualsB = Session["A"] == Session["B"];
return; //Just to place a breakpoint
}
***
in Page_Load, aEqualsB == true in both SQLSession State and InProcess
Session State

but
// In button eventhandler
....
bool aEqualsBAfterPostback = Session["A"] == Session["B"];
return; //Just to place a breakpoint
***
in a Button_Click eventhandler after a postback, aEqualsBAfterPostback
== false
if you use SQLSession State and true if you use InProcess State.

This is really bad!

I have an application where I wan't to isolate the state for every
page, and not overwrite state used by different pages by accident.

I use a framework similar to the User Interface Process (published on
Microsoft Pattern and Practices web site), which allow me to pass
objects between controllers. Each Page has a controller associated to
it, and State is stored in the controller.

Sometimes you DO want to pass state between controllers WITHOUT using
state properties public to the entire application.

This works flawless when using InProcess Session State, but works VERY
bad using SQLSession State.

This results in stupid behavior when users use the back button
functionality, when for example switching between a OrderList and
OrderDetails page, since changing something on the OrderDetails page
doesn't show on the OrderList page, when using the back button. (Using
InProcess State everything works)

Since my application has thousands of users I have to prepare for a
"worst case scenario" where InProcess state isn't enough.

My questions are:
1. Is Microsoft aware of this problem (probably)?
2. Is the behavior acceptable/desirable (probably not)?
3. Is there a good workaround to the problem?

Any help/input appreciated
/ Johan Nedin
Nov 19 '05 #1
1 2268
Johan Nedin wrote:
Hello!

I have a problem with SQLSession state on my ASP.NET pages.

SQLSession state behaves very different from InProcess session state,
which I think is very bad.

I can understand some of the differences, e.g that every object you
store in SQLSession state have to be serializable, but other
differences are very unfortunate.

Look at the following Example:
// Page_Load
...
if(!IsPostBack)
{
Session["A"] = "A";
Session["B"] = Session["A"];
bool aEqualsB = Session["A"] == Session["B"];
return; //Just to place a breakpoint
}
***
in Page_Load, aEqualsB == true in both SQLSession State and InProcess
Session State

but
// In button eventhandler
...
bool aEqualsBAfterPostback = Session["A"] == Session["B"];
return; //Just to place a breakpoint
***
in a Button_Click eventhandler after a postback, aEqualsBAfterPostback
== false
if you use SQLSession State and true if you use InProcess State.

This is really bad!

I have an application where I wan't to isolate the state for every
page, and not overwrite state used by different pages by accident.

I use a framework similar to the User Interface Process (published on
Microsoft Pattern and Practices web site), which allow me to pass
objects between controllers. Each Page has a controller associated to
it, and State is stored in the controller.

Sometimes you DO want to pass state between controllers WITHOUT using
state properties public to the entire application.

This works flawless when using InProcess Session State, but works VERY
bad using SQLSession State.

This results in stupid behavior when users use the back button
functionality, when for example switching between a OrderList and
OrderDetails page, since changing something on the OrderDetails page
doesn't show on the OrderList page, when using the back button. (Using
InProcess State everything works)

Since my application has thousands of users I have to prepare for a
"worst case scenario" where InProcess state isn't enough.

My questions are:
1. Is Microsoft aware of this problem (probably)?
2. Is the behavior acceptable/desirable (probably not)?
3. Is there a good workaround to the problem?

Any help/input appreciated
/ Johan Nedin


What I think happens is this:

with Session["B"] = Session["A"]; both A and B use the *same* reference.
If you immediately check Session["B"] == Session["A"] then you will get a
"true" result, as this "==" checks for equality of *reference* (as Session["whatever"]
returns an object, not what it really was).

With inproc store there will be no change, as everything remains in memory.
With external session state (StateServer, SqlServer), then both Session["A"]
and Session["B"] will get serialized. When you refer to A or B again, they are
retrieved from the session store. The values are still the same, but now
they are independant objects (separate references), so an equality check
(on those *references*) will return false!

One solution would be not to check references, but to check values, as in:
(string)Session["A"] == (string)Session["B"]
As you are now comparing *values* (of course both need to be strings
for this exact code to work) the result will be what you want.

Hans Kesting

Nov 19 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by adam | last post: by
2 posts views Thread by martin | last post: by
1 post views Thread by mirek | last post: by
5 posts views Thread by ASP.Confused | last post: by
13 posts views Thread by | last post: by
3 posts views Thread by codegreen9 | last post: by
6 posts views Thread by Bhagya | last post: by
reply views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by lumer26 | last post: by
reply views Thread by lumer26 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.