Does ASP.NET Make Request Scheduling Decisions Based Upon SessionID?

I know that a properly implemented SessionStateStoreProvider maintains an exclusive lock on session data for the duration of a request. However, considering that multiple requests could arrive simultaneously (e.g. via IFRAMEs) all but one would开发者_开发技巧 be able to make forward progress. All the other requests would block for a bit and reduce the number of worker threads available during that time.

It seems if ASP.NET "peeked" at the session IDs on the requests early on, it could avoid running requests simultaneously that were on the same session. This would improve throughput under load for pages that didn't want to give up using IFRAMEs.

This seems plausible enough that it might be true.

According to Chapter 10, Improving Web Services Performance, State Management, MSFT p&p, May 2004 (link text):

"[...] If you keep data in session state, Web services calls made by one client are serialized by the ASP.NET runtime. Two concurrent requests from the same client are queued up on the same thread in the Web service [...]"