Menu
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?
503
Session is not threadsafe. If you are using requests with an explicit Session object in a multithreaded program, you should create one Session per thread.
Thread safety becomes a concern if there is at least a single entry point which can be accessed by multiple threads. If a piece of code is accessed by multiple threads and is calling other method/class/etc., then all this code tree becomes vulnerable.
HttpContext access from a background threadHttpContext isn't thread-safe. Reading or writing properties of the HttpContext outside of processing a request can result in a NullReferenceException.
It offers thread safety as it'll ensure that it'll create a session for each thread if session not exist. transaction and automatic session closing is attached to this. It's not thread safe. developer manually needs to manage transactions and session flush and close operations.
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.
83
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.
39
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
