J
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
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