Take the 2-minute tour ×

Reading Guru-Gu's blog post about ASP.NET MVC3 hitting RC, he says:-

Session-less Controller Support

You can now indicate whether you want a Controller class to use session-state – and if so whether you want it to be read/write or readonly.read/write or readonly.

Can someone explain what are some scenario's someone might want to have a session-less controller? or a read-only controller?

I've always been creating a separate IIS website which I use to handle all static images/content and then have this same website have session state turned off ... so no cookies are sent over the wire. Is this a similar scenario?

share|improve this question

1 Answer 1

up vote 24 down vote accepted

Gu commented about this. Quoting:

The release notes cover this more (you can download them from the download link above). Session state is designed so that only one request from a particular user/session occurs at a time. So if you have a page that has multiple AJAX callbacks happening at once they will be processed in serial fashion on the server. Going session-less means that they would execute in parallel.

This is a known scenario in ASP.NET in general. The session object for the same user is not thread safe. This means that if the same user (same session id cookie) sends multiple requests to a page which uses session those requests will queue and will be processed in series and not in parallel.

share|improve this answer
Oh wow. I never ever knew that (and i've been working with ASP since classic ASP). Wow. But ... that does make sense :) The session data is important and thus will need to be 'locked' I assume, forcing serial processing. Hmm... So this would be a great candidate to make all Ajax ActionMethods Session-less :) –  Pure.Krome Nov 9 '10 at 23:16
Absolutely, all AJAX calls should be made session-less. By the way I hate session, so in general I make my whole application session-less :-) –  Darin Dimitrov Nov 9 '10 at 23:18
So there's nothing you need in the session at all? logged in user? –  Pure.Krome Nov 9 '10 at 23:38
The logged in username is stored in the authentication cookie. As far as user data is concerned => datastore. –  Darin Dimitrov Nov 10 '10 at 7:04
@RPM1984, things like nick that change rarely could go into userData of the forms ticket and be fetched through a custom generic principal in a custom authorization action filter, rep and badges could potentially be changed by other users requests so those need to be fetched from the database. Of course to avoid hitting it on every request cache with expiration policies should be used and for better scalability this cache needs to be distributed and offloaded from the web server. –  Darin Dimitrov Nov 11 '10 at 5:07

Your Answer


