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

[Johan Nedin]

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

[Hans Kesting]

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