HttpContext Class and its Thread Safety

Question

I have an Singleton object in application that has following property:

private AllocationActionsCollection AllocationActions
{
    get
    {
        return HttpContext.Current.Session["AllocationOptions.AllocationActions"] as AllocationActionsCollection;
    }
    set
    {
        HttpContext.Current.Session["AllocationOptions.AllocationActions"] = value;
    }
}

I'm dealing with one error (HttpContext.Current.Session["AllocationOptions.AllocationActions"] is null even though it is supposed to me always set to valid instance...). I just read in MSDN that HttpContext instance member are not guaranteed to be thread safe! I wonder if that could be the issue. There could be a resources race somewhere in application and the moment where HttpContext.Current.Session["AllocationOptions.AllocationActions"] is null is the moment where AllocationActions setter is used using this statement:

AllocationActions = new AllocationActionsCollection(Instance.CacheId);

My questions are:

a) I'm shocked that HttpContext.Current.Session is not thread safe. How to safely use that property then? b) do you have any ideas why that Session variable can be null (even though I'm pretty sure I'm setting it before it's used for the first time)?

Thanks,Pawel

EDIT 1:

a) line that initializes session variable is set every 2 minutes with following statement (executed in Page_Load)

AllocationActions = new AllocationActionsCollection(Instance.CacheId);

b) code that calls getter is called in event handlers (like Button_Click)

c) there is not custom threading in application. only common HTTP Handler

OK, so what is calling this code? Is this an explicit threading situation ( calling Thread.Start) or by threading is this a web service, or HTTP handler, or what? — Brian Mains, Sep 27 '11 at 13:08
When do you execute code that returns null session? In page constructor Session IS null; In Page_Init or Page_Load Session IS NOT null — Emanuele Greco, Sep 27 '11 at 13:10
you need to show more source code - esp. where this is set and clarify the threading situation... if for example you access HttpContext.Current outside an IIS thread (i.e. in a thread you started separately) while being hosted in IIS this would yield "interesting" results... — Yahia, Sep 27 '11 at 13:12
What the docs mean is that a particular HttpContext instance may only be safely used from one thread at a time. This is desired behaviour because it is tied to the thread that is processing the page request. — Nick Butler, Sep 27 '11 at 13:12

Emanuele Greco · Accepted Answer · 2011-09-27T15:40:42.287

2

A singleton object is realized by restricting the instantiation of a class to one object.

HttpContext.Current.Session is an area dedicated to a single user; any object stored in Session will be available only for the user/session that created it.

Any object stored in Application will be available only for every user/session.

Any static object also, will be available only for every user/session. Suggested implementations always use static objects.. why didn't you?

edited Sep 27 '11 at 15:40

answered Sep 27 '11 at 14:11

Emanuele Greco

12,551
7
51
70

Thanks, for I moment I got confused. Of course it turned out that there was a bug in application where Session variable wasn't set... – dragonfly Sep 28 '11 at 07:30

Joe White · Answer 2 · 2022-09-14T05:36:30.590

2

HttpContext.Current returns a separate HttpContext instance for each request. There can be multiple threads processing requests, but each request will get its own HttpContext instance. So any given instance is not being used by multiple threads, and thread safety is not an issue.

So unless you're manually spinning up multiple threads of your own for a single request, you are threadsafe.

edited Sep 14 '22 at 05:36

answered Sep 27 '11 at 14:26

Joe White

94,807
60
220
330

3

This is not true. IIS will spin off new threads when certain loads are reached and if you're storing configuration information or something in a static variable, that data won't be reachable from the new thread. – Don Rolling Sep 25 '12 at 03:51
@DonRolling, got a citation for that? I've never heard of IIS starting more than one thread for the same request, and I'm not sure what that would even mean. – Joe White Sep 26 '12 at 12:21
I don't have a citation, but the issue has happened to me. It doesn't happen during a single request. It happens if you're storing something like db config values in a static variable. If IIS begins a new thread due to traffic, then those config values weren't available to the new thread. – Don Rolling Dec 21 '12 at 21:03
3

@DonRolling, you're confusing threads with appdomains. Statics are shared across all threads within an appdomain, so those values *will* be available to the new thread. It's only if it spins up a new appdomain that you'd get a new copy of the static variable. And even then, your init code should still run and initialize the variable, just like it did in the first appdomain. – Joe White Dec 22 '12 at 02:10
1

Further discussion of how ASP.NET migrates HttpContext between threads here: http://stackoverflow.com/questions/8109526 – user423430 May 11 '15 at 22:17
@JoeWhite - `it's a static member. So it's threadsafe` - Why are you implying that because it is a static member it is thread safe? My understanding is a static member is shared across all instances. – variable Jun 16 '22 at 10:53
1

@variable You know, I have no idea what point 11-year-ago me was trying to make with that sentence. I trimmed my answer to be more to-the-point and hopefully clearer. – Joe White Sep 14 '22 at 05:39

score 1 · Answer 3 · answered Sep 27 '11 at 13:12

The thread safety of the HttpContext class is pretty standard for .NET. The basic rule of the thumb (unless explicitly specified) is that static members are thread safe and instance members aren't.

In any case it is hard to tell why your session variable is null without looking more into the code that sets/resets it. Or perhaps you are calling your get_AllocationActions method from a different session than the one you set it in. Again, more code would help.

score 1 · Answer 4 · answered Sep 27 '11 at 13:16

1

To access the session property safely you would just wrap the access in a lock statement and use the SyncRoot object of the session class.

answered Sep 27 '11 at 13:16

Lee Dale

1,136
9
20

HttpContext Class and its Thread Safety

4 Answers4

Linked