0

I am using MVC3. ASP.NET 4.5, EF5, SQL Azure, Azure Websites.

I want to get rid of my session variables due to:

1) Multi instance issues

2) Locking issues

I am only using about 5, and then they are for ids.

I have read MS's Azure recommendations for Azure web development, and they recommend removing session variables. They seem to recommend alternative persistent options, in order of preference:

1) Cookies (I would secure these ie hashing/encryption etc.)

2) Caching server

3) SQL Azure

I have seen some negative feedback on cookies, especially overhead, but cannot see an issue with ids only. Also there are security concerns, but with encryption etc these can be sorted fairly easily I would think. It seems cookies provide a simple solution without getting caught up in the complexities of caching, although SQL Azure would be simple as well, although less performant.

I would appreciate some recommendations on this.

1) Do you seek to avoid session vars in Azure website applications.

2) If so then how do you achieve it?

Many thanks.

SamJolly
  • 6,347
  • 13
  • 59
  • 125

2 Answers2

3

Best practice is to make your application stateless in the first place. If you need to store some type of state keep it either in a SQL database or have the user pass it to you with each request.

If you want to provide more details it would be easier to recommend what would work best for you

Zain Rizvi
  • 23,586
  • 22
  • 91
  • 133
  • Hi Zain, Really appreciate the help. Basically I have implemented a wizard type workflow where a sectionid needs to apply to all the steps. Trouble is I tend to use these ids in different classes etc which the steps use, so there would be a lot of parameter passing. I realise that have sessions in classes is a bit of a cheat, a expedient choice at the time. My current thought is to implement a state class, and move persistence to the SQL database alongside the user record. – SamJolly Jul 03 '14 at 08:03
  • A word about speed concerns with DB persistence. I currently use LINQ/EF5, but I guess DB access for the sessions could be speeded up specifically using ADO.NET calls. It would seem simpler than adding loads of parameters into URLs etc. Interesting that you back up the idea of using a SQL database. Thanks again. – SamJolly Jul 03 '14 at 08:04
  • And what about TempData since, as I understand it, TempData uses session state. So just a transient version of a session variable I guess ie over 2 requests. Perhaps TempData should go as well? However not as bad as full Session variables I guess as forced to unload after 2 requests – SamJolly Jul 03 '14 at 08:58
  • @SamJolly: You definitely want to avoid using %TEMP% location to store temporary data that you want to persist since if your VM goes down for any reason anything in %TEMP% will be gone. As far as Database latency is concerned, if you're using one of the Azure Storage offerings then you can consider latency to be zero. The database will be stored in the same location as your website, so the latency between your site and the database will be orders of magnitude less than the latency between your users and your site and won't be noticable – Zain Rizvi Jul 03 '14 at 18:53
  • Thanks for this. Sorry I did not understand %TEMP% location. I was talking about "TempData" which is a ASP.NET MVC temporary storage mechanism which persists state over 2 requests. It is memory based. – SamJolly Jul 03 '14 at 22:51
2

Although making the app stateless/RESTful would be ideal, before going too far down the path of creating a Session replacement, have you confirmed that you actually have a performance issue related to it? ASP.net is fully capable of handling multiple web instances via the <sessionState mode="Custom"> setting in web.config so that shouldn't be an immediate concern. Until you confirm that there really is an issue to be solved (which, perhaps, you already have) I would be hesitant to go too far down this path simply based upon that fact that it might lead to a performance problem.

https://softwareengineering.stackexchange.com/questions/80084/is-premature-optimization-really-the-root-of-all-evil seems like it may be relevant here.

Community
  • 1
  • 1
JimMSDN
  • 484
  • 4
  • 16
  • thanks for this.Yes I realise this, using the out of process modes. At present I am using "inproc". Also I am mainly using one instance, so not really an issue. I say "mainly" as I have "autoscaling" switched on, so potentially I could get n instances. So perhaps the improvement in the short term is to move this to "out of proc" , say SQL. However I am still a little concerned about locking due to "thread agility" issues. We have been picking up a few long "System.Web.HttpApplication.BeginRequest()" calls in NewRelic. Thanks again. – SamJolly Jul 03 '14 at 14:07
  • 1
    @SamJolly I guess it will depend upon what degree of scalability you need. But, first I'd try moving to `Custom` sessionState and then see what happens - esp. since you already have AutoScaling turned on. I found http://stackoverflow.com/questions/17064380/what-happens-in-beginprocessrequest which seems germane to the discussion. – JimMSDN Jul 03 '14 at 14:47