It would be nice if Umbraco didn't rely on ASP.NET Sessions (<sessionState />).
I can see that the code has been updated and dosen't access Session[], but the BaseRestHandler still implements IRequiresSessionState. This turns on sessions for that handler and since it is not read only (IReadOnlySessionState) every concurrent request by that session will be processed in order (serially, serialized, not parallel, ...).
To illustrate:
In scenario 1) we use IRequiresSessionState on our handler.. See that the server first processes the second request after the first has finished. In scenario 2) we use IReadOnlySessionState, now both requests are processed in parallel which often is faster.
It is possible to create a configuration section that determines whether to use IRequiresSessionState, IReadOnlySessionState or none of them. This could be implemented using a proxy class for the BaseRestHandler or three separate classes (BaseRestRequiresSessionStateHandler).
It should be taken in to consideration that removing IRequiresSessionState could result in race conditions or exceptions in current code, so maybe the default should be to use IRequiresSessionState, but recommend users to change their configurations.
Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished. (The second session can also get access if the exclusive lock on the information is freed because the first request exceeds the lock time-out.) If the EnableSessionState value in the @ Page directive is set to ReadOnly, a request for the read-only session information does not result in an exclusive lock on the session data. However, read-only requests for session data might still have to wait for a lock set by a read-write request for session data to clear.
Truly sessionless / stateless Umbraco
It would be nice if Umbraco didn't rely on ASP.NET Sessions (<sessionState />).
I can see that the code has been updated and dosen't access Session[], but the BaseRestHandler still implements IRequiresSessionState. This turns on sessions for that handler and since it is not read only (IReadOnlySessionState) every concurrent request by that session will be processed in order (serially, serialized, not parallel, ...).
To illustrate:
In scenario 1) we use IRequiresSessionState on our handler.. See that the server first processes the second request after the first has finished. In scenario 2) we use IReadOnlySessionState, now both requests are processed in parallel which often is faster.
It is possible to create a configuration section that determines whether to use IRequiresSessionState, IReadOnlySessionState or none of them. This could be implemented using a proxy class for the BaseRestHandler or three separate classes (BaseRestRequiresSessionStateHandler).
It should be taken in to consideration that removing IRequiresSessionState could result in race conditions or exceptions in current code, so maybe the default should be to use IRequiresSessionState, but recommend users to change their configurations.
Lastly a ref. to the Session State info on msdn:
Concurrent Requests and Session State (http://msdn.microsoft.com/en-us/library/ms178581(v=vs.100).aspx)
Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished. (The second session can also get access if the exclusive lock on the information is freed because the first request exceeds the lock time-out.) If the EnableSessionState value in the @ Page directive is set to ReadOnly, a request for the read-only session information does not result in an exclusive lock on the session data. However, read-only requests for session data might still have to wait for a lock set by a read-write request for session data to clear.
is working on a reply...