Session and concurrent request

Hi

 

We all have worked with Asp.Net session objects in some point of time. An interesting question came in between the discussion with my colleagues on concurrent request and session state.  Here is what I have to share with all on session and concurrent users.

 

In asp.net session state is exclusive for each request and session. This means that if two different users access the session there session will be concurrent. Not only that even if two concurrent requests are mode from same session (with same session ID) the first session will have exclusive rights to the session information. The second request will not be executed till the first request is complete. The second request execution will only start after the first request execution is finished or the exclusive lock on the session has freed (due to timeout) in the first session.

 

Remember if the session state for the page is read-only then the request will not have exclusive lock on the session data. However, read-only requests for session data might still have to wait for a lock set by a read-write request for session data to clear.

 

Vikram

 

P.S. You can check my previous Blogs on session here and here

 

3 Comments

  • Your post is a bit confusing, since if there are two different users, they will each have their own separate session dictionairy and even though these are concurrent requests to the server, they will never access the same data, so this is not really concurrent access. However as you noted in the previous Blog, if you open a new window within IE you get the same sessionID and it is possible to have both windows send a request to the server at the same time, thus causing concurrent access to the very same session dictionairy. Someone also claimed that the same is true is your page uses frames. This is when one request has to wait if their page lock type is different. If the session stuff is kept in a SQL server, this makes sense, since the session dictionairy seems to be retrieved from the server by the code that handles the HTTP request before the page starts its life cycle, and it is saved back to the SQL server after the page has been sent out to the browser. During that time, I think it actually keeps a transaction lock in the SQL server, which is nice if you might have the request split over a webserver farm, since I think it is possible that each request might be processed on a separate server then simultaneously. Also, since the entire dictionairy is deserialized and serialized, the objects can be modified without locking each and every object while you are modifying the values in the session dictionary. I have seen examples where after modifying the object, the object is "stored" in the dictionairy again, which makes no sense, since it only holds references, and thus if you modify the object it is modified anyhow.
    If the session in inproc, then I suppose that state server will keep a similar lock on the memory.

    Does this make sense or am I wrong?

    Ernest.

  • Is there any solution to it?
    For concurrent access to same sessionID.

  • Is there any solution to it?
    For concurrent access to same sessionID.

Comments have been disabled for this content.