Question

In our application a page is served which subsequently is supposed to make a bunch of asynchronous calls for more data in parallel. These calls were being queued and I read that calls using the same session are queued because of complications that can arise from having more than one request write to the same session.

I also read that a controller can be set to [SessionState(SessionStateBehavior.Disabled)] or [SessionState(SessionStateBehavior.ReadOnly)] if sessionless or we do not need to write to the session.

I have tried these as I don’t need to write to the session so I figured the requests would be served concurrently, or if I was using the session without realizing it, an exception would be thrown.

Neither of these is the case. Requests from a same user are still being queued.

How can I verify that my directive [SessionState(SessionStateBehavior.ReadOnly)] is being respected?
What could be causing this problem?

In case it is relevant, we are working within the context of Orchard.

Answer 1

It’s because the underlying HTTP handler that’s being used for every Orchard route request is implementing IRequiresSessionState interface. It’s the reason every request is actually queued…

It’s a known issue and we’ll be trying to fix that in the next Orchard version, as long as it won’t imply a breaking change. There are couple of core features (and unknown number of external, custom ones) that rely (or may rely) on Session, so simple removal of the IRequiresSessionState interface is not an option. We need to refactor things first and implement some opt-in/opt-out mechanism.