2

As of my empirically gathered knowledge suggests, .NET WebForms is probably using a queue of requests and when the first request is properly handled, the new first comes to the head of the queue and so on. This behavior recently led to a misunderstanding, where we thought that a feature is very slow, but as a matter of fact, some other features always running before it were the slow ones. But this is only a minor misunderstanding. I can imagine more serious problems, for instance a longer request blocking the other requests and I did not find the time yet to test this on multiple sessions, to see whether this queue is session-level, but I think it should be if I am even right about its existence. Hence my question: why are later requests waiting for earlier requests' parsing in .NET WebForms projects?

Lajos Arpad
  • 64,414
  • 37
  • 100
  • 175
  • Probably Session. Requests from the same session that use session state don't run concurrently. There is no blocking for calls from different sessions. Also no blocking for calls from the same client that have session state disabled or readonly (see https://msdn.microsoft.com/en-us/library/16kf4xz0.aspx) – Joe Oct 18 '16 at 19:25
  • Thank you, Joe. That is kinda confirming my observation and adds a few important facts to it. Can you convert your comment to an answer so future visitors will be helped as well? – Lajos Arpad Oct 18 '16 at 19:27

1 Answers1

2

Probably Session.

Requests from the same session that use session state don't run concurrently. This means that applications can use session state without needing to worry about race conditions.

There is no blocking for calls from different sessions. Also not blocking for calls from the same client that have session state disabled or readonly.

See the MSDN description of the PagesEnableSessionState Enumeration

Joe
  • 122,218
  • 32
  • 205
  • 338