6

Can CallContext be relied upon, through-out the whole request, when using asp.net Web API?

I have read the decade-old blog post and I'm not sure it still applies (as asked there).

Assuming Thread-Agility kicks in, if I set data in a global filter, is it safe to assume it will be there through-out the request?

Berlo
  • 134
  • 8
  • I have tested with CallContext.LogicalSetData and async controller (to make it switch threads before and after) and it seems to work fine. However that's quite a complex subject and it's hard to be sure by just performing simple tests. – Evk Feb 21 '17 at 08:43

1 Answers1

3

You lose your CallContext if ASP.Net switches threads. In an asynchronous model, the asp.net task scheduler will take care of joining async calls back to a request thread with the same HttpContext, but not necessarily the same thread.

Example: A request starts and then you go off to asynchronously wait for some slow IO before returning - while you're waiting for that slow IO there's no reason for your request thread to be sitting around doing nothing so it may get used for another request.

ASP.Net is a big exercise in Thread Agility (google it), and there is also a great discussion about this here: CallContext vs ThreadStatic vs HttpContext

caesay
  • 16,932
  • 15
  • 95
  • 160
  • 1
    CallContext.LogicalSetData and .LogicalGetData is supposed to work for async. – imukai Feb 07 '18 at 12:54
  • @imukai `CallContext` was designed for remoting, and you're right - it should work for async, but on who's word? It was designed before Async even existed. It isn't documented anywhere that I could find; the only info I have is from reading other threads of people discussing and nobody seems to agree on the behaviour of `CallContext` inside asp.net. It's much better to use an `AsyncLocal` as it was designed for this purpose and *is* documented. – caesay Feb 07 '18 at 13:14
  • `You lose your CallContext if ASP.Net switches threads.` Is this correct? I am also looking at this post: https://stackoverflow.com/questions/273301/callcontext-vs-threadstatic – themefield Aug 27 '19 at 17:18
  • @themefield: A quote from the question you linked: `Very often a request will use the same thread throughout, but it certainly won't always be the case`. This means that very often your CallContext might be the same one, but it might not always be. Check out `AsyncLocal` for an async safe way to store thread specific data. – caesay Aug 27 '19 at 17:32
  • @caesay I think the sentence `Very often a request will use the same thread throughout, but it certainly won't always be the case` is saying that very often the thread might be the same one, not that the `CallContext` might be the same one. – themefield Aug 27 '19 at 17:40
  • @themefield If I remember, the thread is the same, the CallContext will be the same - if the thread has been changed, the CallContext will be new. Although, you could test yourself to verify if this is important to you! – caesay Aug 27 '19 at 18:17