Reputation: 13038
Consider a user making multiple requests at the same time, do I have to lock all code that works with the Session?
If for example I have the following scenario, where in one tab of his browser the user opens a page and in the second he logs out.
Request 1:
if(Session["user"] != null)
lblName.Text = Session["user"].Name;
Request 2:
if(logout)
Session["user"] = null;
Is it possible that Request 1 throws a NullPointerException when accessing the Name property? Do i need to lock the code in Request 1, to make sure user still exists after checking for null? Or does ASP.NET deal with this automatically somehow?
Upvotes: 24
Views: 11124
Reputation: 12485
As always, the answer depends on what you mean by "safety." In ASP .NET, each request gets exclusive access to its session state. This means that you don't have to worry about synchronizing access within the scope of a single request. If Session["user"] is non-null, then it will be non-null for the entire duration of the current request. In your example, request 1 will never throw a null reference exception.
Upvotes: 12
Reputation: 33379
Two requests to an ASP.NET application for the same same session, where the handlers do not use the IReadOnlySessionState
marker interface or have the EnableSessionState="ReadOnly"
turned on for your pages, will be serialized by the ASP.NET runtime to guarantee consistency of the state. So if you have two pages that are able to write to the session state, they will be accessed serially no matter what the client does on their side.
It's up to your application code to signal to ASP.NET with the afforementioned techniques whether or not a page/handler is going to write to the session state. If you do not, all requests will be serialized and the performance of your web application will suffer.
Upvotes: 17
Reputation: 28835
In ASP.NET, the Session module uses a pair of reader/writer locks per session, so Request 1 will have consistent reads, and Request 2 will block until Request 1 completes.
Upvotes: 5
Reputation: 58665
Yes, Session is thread-safe.
There's no need to lock anything. However, the need to check the values never cease to be essential.
Update
Check @Peter Ruderman's answer :)
I will have the decency of not copying it :)
Upvotes: 1