Possible session state race condition about session

[hishamco]

/cc @Tratcher @kichalla

[davidfowl]

/cc @lodejard

[Tratcher]

All of your observations are correct, and this is the intentional design. In previous versions of ASP.NET locking the session caused crippling problems with parallel request processing, especially across multiple servers. The new design acknowledges the lossy nature of sessions and does not attempt any concurrency guarantees (except non-corruption).

Serializing all of the values together as a coherent session helps avoid inconsistencies between related keys. We may eventually provide an alternate implementation for incoherent sessions (e.g. each key cached separately). This could also be provided by the community.

Note session will always have an initial race condition if multiple requests are made before the session cookie is set on the client. Each of those parallel requests may create its own session and cookie and then the browser will only keep the last one.

[wanton7]

It's true that there could be a race condition when session is first created, but usually it's a page load that creates session and not an ajax call so it's highly unlikely.

Locked update scope would allow to keep multiple related keys consistent and also allow you to even increase a session based counter correctly if session state was refreshed after lock was taken.

In our company's software we do lot of session updates via ajax. When we move to new Asp.Net we probably have to write our own session store to avoid this situation.
It's really great that with this new middleware system we can do that easily.