What are some scenario's of having a Session-less Controller in ASP.NET MVC3?

Question

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?

Sorcha

Answer 1

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.

Scrawny

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 :) – Sorcha

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 :-) – Scrawny

So there's nothing you need in the session at all? logged in user? – Sorcha

The logged in username is stored in the authentication cookie. As far as user data is concerned => datastore. – Scrawny

interesting. some of the guys here were guessing how u were handling that -> so your manually setting and reading the cookie? – Sorcha

No, I am using User.Identity.Name in my controller. Nothing manual. – Scrawny

@Darin Dimitrov - that's fine (and normal - username is stored in cookie), but consider the scenario on StackOverflow top menu for the user (displayed on every page) - you've got nick, rep and badges. If not in the session, where? Would you be making a hop to the DB on every request? Or would you stick extra info in the Forms Auth ticket? – Erigena

@Darin Dimitrov - and another question :) relating to your answer. Do you have any ideas why they've made the attribute only applicable to the class (can't decorate action methods). So if you want some session-less ajax calls, you'd have to put them in a seperate controller, which means more routes, and could get messy. Any ideas? I can only assume they did this because it needs to be done at the instantiation-point for the controller, not at the execution-point for the action. – Erigena

@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. – Scrawny

@Darin Dimitrov - yep, makes sense. Cheers. :) – Erigena

REpresentational State Transfer FTW. – Kerry

@Darin Dimitrov i have a page /email/edit/3 where the user can change it's email address. How do i prevent the user from altering the id in the url and thus post data for email address 4 while it is editing email address 3 other then storing the id in the session. – Nation

@Michel, if you need to prevent the user from altering something in the url, then this something should not be part of the url. It should be encrypted, probably as part of the authentication ticket cookie if you are using forms authentication for example. Or alternatively if the id needs to be part of the url then you will need to query your database to ensure that this id belongs to the currently authenticated user before performing an update. This verification could be done for example in a custom Authorize filter. – Scrawny

@Darin Dimitrov ah, ok, but when storing data in the cookie i'm always scared that i miss a specific scenario in which a user can workaround my solution, like first edit record 3, then copy the cookie, and then edit record 4, restore the cookie etc. I'm not sure if that's a plausible scenario but the key of this comment is: i feel safer when the data is stored on the server and less easy to manipulate (i won't say impossible, because i don't know that :-)). Or is this fear of storing data in the cookie and cookie copy/paste overreacted? – Nation