Richard Creer
Richard Creer

Reputation: 9

ASP.net SessionState Scope

In my experience it is not unusual for a web app to be open in more than one tab in the same browser instance. It may be that the user wants to look at two parts of the database side by side or perhaps there are two different apps in the same domain.

Now in my naivety I had assumed that two instances of the same app would have their own set session variables so instance A could have Session(“user”) = “John” and instance B could have Session(“user”) = “Sally”. But I’ve discovered to my horror that this isn’t always true, and usually isn’t. My testing shows that if in web.config SessionState section cookieless=true/UseUri then the two instances have their own set of Session variables. But if cookieless=false/UseCookies then they share one set. Of course cookieless=true is not a good idea and AutoDetect/UseDeviceProfile are almost always going to be the same as false.

So if instance A does Session(“user”) = “John” then instance B does Session(“user”) = “Sally”, instance A now sees Session(“user”) = “Sally”.

This is so patently awful that I feel I must be missing something so can anyone put me right?

If that’s the way it has to be, what are the alternatives? Use ViewState? But another horrible thought, I’m saving ViewState in SessionState.

An example and further thoughts

Imagine you have an ASP.net web page that lets the user look up a customer in a list then view its details. The code stores the customer no. in Session(“custno”) and uses that as the key in an SQLDataSource. You could argue that this is poor programming technique but I’m using it simply as an example to illustrate what can happen.

The user sits in front of his computer and looks up customer 1234. The code duly does Session(“custno”) = 1234. Before he has finished working on 1234 the user needs to look up customer 5678. So he opens the page in another window, selects 5678 and the code now does Session(“custno”) = 5678. Having finished with 5678 he goes back to 1234, changes something vital, saves the change and to his horror finds he has updated 5678. Surely in a well organised society this should not happen.

Session variables are often recommended as a good way to pass variables between pages with the implication that a ‘session’ is one client sat in front of one computer using one app. And it can do exactly that if SessionState is set to cookieless=true but not if cookieless=false (and we don’t really want to use cookieless=true).

I was hoping that someone would say “just do this and it will work the way you expect” but it seems I’ve been mistaken all along and I suspect many others have been too.

So what to do about it? A comment offers several solutions for which I say thank you however none seem to me to be particularly satisfactory.

Creating a different ID for each window and making it part of the URL looks very much like cookieless=true and with the same disadvantages.

Forcing a new session to be created for each browser window. I’d be interested to know how this is done because New Session for New window in ASP.NET suggests it is not possible (though it does demonstrate that someone has been this way before).

“Storing anything you need in the window itself” is I guess synonymous with using ViewState instead of the session. I can see that could work except I store ViewState in the session to reduce transmitted page size! And anyway ViewState has a number of disadvantages including not being available until well in to the page life cycle.

Creating a page id and saving it in ViewState as described by asp.net - session - multiple browser tabs - different sessions? at first looked promising but I fear it is not going to work well with a PageStatePersister. More experimentation needed.

Upvotes: 0

Views: 169

Answers (0)

Related Questions