ASP.NET session variables

Question

I have a session variable: ID. Is there ever a possibility that two browsers on the same PC could share the same session variable and update it, therefore producing random results. I would expect there to always be two separate sessions with two separate sets of session variables.

I have researched this and I have come accross the following web page, which suggests that there are session locks to prevent this from happening:http://odetocode.com/blogs/scott/archive/2006/05/20/session-state-uses-a-reader-writer-lock.aspx. I have an ASP.NET application and there are random results suggesting that this could be happening.

I will produce some code if requested.

UPDATE 19:51 Tim Medora says: "two instances of the same browser type using the same session ID". Does this mean that if a user opens one browser and then closes it (because it takes too long to open) and then opens another browser (in another window) then the same session ID could be used and the session variables in window 1 are copied for window 2?

UPDATE 19:35 24/10/2012 Tim Medora says: "However there is a very real possibility of two tabs in the same browser, or two instances of the same browser type using the same session ID". Will the session information be separate in these cases. For example, if a user opens a browser and then closes it (before the response has loaded) and then opens the same window with a different set of session variables then is there a risk that session A and session B have the same session variables.

Answer 1

The possibility of a random collision is extremely low.

However there is a very real possibility of two tabs in the same browser, or two instances of the same browser type using the same session ID¹. Session IDs may also be reused, adding to the confusion.

Does this mean that if a user opens one browser and then closes it (because it takes too long to open) and then opens another browser (in another window) then the same session ID could be used and the session variables in window 1 are copied for window 2?

Yes, the session ID may be reused and the same session may be active. I did a quick experiment with Chrome and I was able to copy a URL (which uses Session) to new tabs and new instances of the browser, and the same session stayed active.

However, the session variables are not copied for the new window; they are the same values.

Session Locking

Locking Session only means that two writers can't update it at exactly the same time. More specifically, a lock is placed on Session from the beginning of the request until the end of the request; only one write can alter it during that period. But that period of time is usually very small, and (while the locking prevents some issues) it doesn't prevent two different sources from altering the same data at different times.

Avoiding Collision

One way to minimize collision is to use unique session keys. Let's say a user (in the same session) opens two different records for editing. If you have a session key of "ActiveRecord", the probability for data corruption/mismatch is very high. However, if each page stores a unique key in a hidden field, that unique key can then be used to retrieve the appropriate value from Session, and each value can be manipulated discretely.

In other words, unique keys allow you to safely open two different instances of the same item at the same time. This does not prevent issues with two windows editing the same item at the same time. Though they will have separate keys, the end result will probably be undesirable when the data is committed.

^{1 - this seems to be the case in all modern browsers, but I can't definitively say that it is always the case. Would welcome a reference.}

Answer 2

I faced similar situation recently. In create user screen, multiple addresses can be entered for the user. Initially I used session for storing addresses. Since session is shared across browser tabs, functionality didn't work well. And also I realized storing data in session is not a good approach due to various reasons like overhead in maintaining session state in webfarm scenario, etc. So, I had to switch back to DOM manipulation (since its mvc application) to store addresses. If it is web forms, viewstate might be alternative for session.

As mentioned in already posted answer, it can be achieved through sessions by using unique key per request i.e., in my case, storing addresses in session[userid] or you can use any random key to hold the values and have hidden fields to persist that key across web requests. However, I was not convinced by other reason that they will not be cleared automatically when user closes the tab.