magnattic
magnattic

Reputation: 13038

Is working with the Session thread-safe?

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

Answers (4)

Peter Ruderman
Peter Ruderman

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

Drew Marsh
Drew Marsh

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

Jacob Krall
Jacob Krall

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

Adriano Carneiro
Adriano Carneiro

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

Related Questions