18

This is kind of a hard question to formulate. I'm wondering how HttpContext.Current gets assigned a unique instance for every request considering it's a static object?

Thanks!

Micah
  • 111,873
  • 86
  • 233
  • 325
  • 2
    possible duplicate of [How does HttpContext.Current work in a multi-threaded environment?](http://stackoverflow.com/questions/1561036/how-does-httpcontext-current-work-in-a-multi-threaded-environment) – Micah Aug 05 '10 at 16:35

2 Answers2

24

Current is not a static variable, its static property, and get property is nothing but a static method which returns the current Context.

ASP.NET stores some information with current thread, you can always get a local thread storage to store information which is kind of static only in the current thread, and which can be accessible by any method in current thread only.

So ASP.NET stores some local information in the thread in which the http context executes the requested application and from anywhere call to Current will fetch the local thread data and get required information.

You can also look at [ThreadStatic] attribute which does things almost in similar way.

Update

From ASP.NET 4.5 and after, Current HttpContext is passed through CallContext instead of [ThreadStatic], so context remains available through out async calls in single logical context instead of current thread as each async call may end up on different threads.

Akash Kava
  • 39,066
  • 20
  • 121
  • 167
  • Except, it also works from a different thread (serving the same request), which is the main reason of using HttpContext to store contextual values as opposed to using thread – Sheepy Jan 13 '15 at 10:35
  • Kelsey provides a more accurate answer below, and should be the accepted answer. HttpContext is not kept simply using Thread, because it wont work if ur code uses plinq or async, for example – Sheepy Jan 13 '15 at 10:39
  • @Sheepy, Look at statement, "The CallContext provides a service extremely similar to thread local storage (except CallContext can perform some additional magic during a remoting call)." And also HttpContext.Current does not work with plinq and async as well without having to write any extra code. Although CallContext would be using ThreadLocalStorage internally, without which it cannot work. So please get all the details before putting such comment. If you provide a proof of CallContext not using ThreadLocalStorage, I will agree your point. – Akash Kava Jan 14 '15 at 08:33
  • It does work with plink and async, as long as they're executed within the scope of the request (instead of left hanging after the request has been completed). I have tried this before (plinq) and regularly (async), which is why I was interested in knowing how it works (and stumbled upon this thread). I'm trying to achieve the similar outcome for a tool I'm building (a CDI implementation for .net from Java EE), and using Thread alone doesn't work, now that multithreaded programming has become very common in .net – Sheepy Jan 15 '15 at 02:18
10

You should read this blog post:

http://odetocode.com/Articles/112.aspx

The section that starts with the following should be of interest to you. It's long or else I would quote more of it:

The curious among us will wonder just how HttpContext.Current can find the context for the current request.

Kelsey
  • 47,246
  • 16
  • 124
  • 162