HttpContext.Current.Items after an Async operation
As I understand it during Async operations the ASP.NET thread originally running the operation is returned to the thread pool and a different thread may be used to finish the request after the Async operation has completed.
That is correct. But let's talk about async
on ASP.NET for just a minute.
async
requires .NET 4.5. Furthermore, ASP.NET 4.5 introduces a "quirks mode" on the server side, and you have to turn the SynchronizationContext
quirk off. You can do this by either setting httpRuntime.targetFramework
to 4.5
or using an appSettings
with aspnet:UseTaskFriendlySynchronizationContext
value of true
.
If your web.config does not have one of those entries, then the behavior of async
is undefined. See this post for more details. I recommend using the targetFramework
setting and fixing any problems that come up.
Does this affect the HttpContext.Current.Items collection? Is an item that was in the Items collection guaranteed to be there when the Request resumes?
The AspNetSynchronizationContext
preserves the current request context across await
points. This includes HttpContext.Current
(which includes Items
, User
, etc).
Another possibility is CallContext.Logical[Get|Set]Data
, which also flows across await
points. This is useful if you don't want a code dependency on HttpContext
, but has slightly more overhead.
I gave a talk at ThatConference a couple weeks ago on async
on the server side; you may find the slides helpful, particularly the ones dealing with Context and Thread-Local State.
Cutting a long story short, it normally should. Unless you are using ConfigureAwait(false)
which can have a side effect with continuation not flowing the context.
Alternatively try adding this setting in your app.
<appSettings>
<add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />
</appSettings>
UPDATE
NOTE!! Initially I put false. But it must be true so that context flows.