Recently, I uncovered an interesting little ‘gotcha’ while investigating a performance issue with an application that I was working on using a Silverlight/RIA Services stack.  Once I discovered what it was, I was quick to remember why, but I had a little problem on my hands as I had to find a way to resolve the issue without a major change of code.

As per MSDN regarding ASP.NET Session State:
“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.”

What does that mean in terms of Silverlight and RIA Services?

Often forgotten, but the use of session state can have a substantial impact on overall application performance especially in an asynchronous Silverlight environment utilizing RIA Services.  For example, if three RIA Service requests are made consecutively from the Silverlight application the server would only process one after another.  With the recent application I was working on, this soon became apparent – larger requests would prevent non-dependent and much smaller requests from executing until after the larger request was done, causing large load times.

All that said, there’s always a reason why and here is no different:  ASP.NET wants to make sure that your session data is thread safe.

I didn’t realize this, now what?

What if removing your use of session state wasn’t an option and you absolutely needed session state? You’re in luck!

But, before we dive into the technical details, what’s important to understand here is that ASP.NET really just cares about whether it needs to protect your session data.  So, if ASP.NET knew that for a given request, the session was in a read-only state, ASP.NET would ignore that you have established session state and it would attempt to process concurrently so long as all other pending requests are also in a read-only state.  Of course, if you’re not using session state, ASP.NET recognizes protection of session data is not necessary and will make concurrent requests without the developer being proactive about it.

New in .NET 4.0 is the ability to programmatically control the session state behavior.  We have a new method available thru the HTTP context called SetSessionStateBehavior which takes in a session state behavior enumeration called SessionStateBehavior.  You have four options at your disposal: Default, Required, ReadOnly and Disabled.  I’ll be spending time talking mostly about the read-only setting as it more closely pertains to the ability to keep session state available while allowing for concurrent requests.

Here is a primitive example that sets session state to read-only for each RIA Service request in the hosting ASP.NET application’s Global.asax:

(This example assumes that none of our RIA Service calls require the need to edit the session state… you may have greater need or more limited options depending on your use cases.)

Here's a little bit of detail ...

First and foremost, setting the session state behavior is on a per request basis and must be set before the AcquireRequestState event in the ASP.NET HttpApplication pipeline.

• Session state will be established on the first request that it’s behavior is not read-only (or disabled) and you attempt to add to it
• When session state behavior is set to read-only for a request, modifications that are made to session are not persisted*
• Concurrent requests are eligible so long as all pending requests have a session behavior of read-only or, of course, session state has not been established
• If a session state has been established, regardless of the session state mode, you do not lose session by changing the read-only flag

* Curious developers may notice that when using In-Process session state mode that you can modify an established session state and have the changes persisted.  While this might appear to be a nice shortcut, this is not recommended and you should be aware of potential thread safety issues.

What does all this mean?

If you are careful and your use cases permit, you can still utilize session with a Silverlight/RIA Services stack.

Have a look at what it did for the aforementioned application that I worked on (screenshots came from Fiddler).  Each horizontal line represents a RIA Service HTTP request – take note of the overall duration in seconds and length of overlap for calls before and after.

Before:

After:

Bottom line

If you are using session state with a Silverlight/RIA Services application you ought to consider the potential performance impacts.