4

I'm reading ASP.NET 4 Unleashed and I came to this sentence. "When Session state is stored in-process, it is stored on a particular web server. In other words, you can't use in-process Session state with a web farm."

Ooops. I'm building a web app that uses and depends on storing dictionaries in the session. Now I know that there's some problem with serialization of dictionaries when using sessions but with InProc sessions, there's no serialization so I thought I'd be ok. But now I'm wondering: will I have any nasty surprise when I go to host my application?

Thanks.

frenchie
  • 51,731
  • 109
  • 304
  • 510

1 Answers1

5

First of, if your app runs on a single server (and possibly on a shared hosting), in-proc session is OK and probably the only way to go.

But, if you have more than one server (web farm) or even more than one process on the same server serving your web site (web garden) in-proc will not work unless you use sticky sessions: your load balancer will need to be configured to send requests to the same server after the session is started.

Do not worry about dictionary serialisation, session handling must be able to sort it out, be it state server or SQL Server.

Generally, however, any reliance on an in-proc session or state limited to the process boundary is considered bad design and is highly discouraged.

Aliostad
  • 80,612
  • 21
  • 160
  • 208
  • The reason is mainly scalability, if your requirement changes and you have to get more than one server then you can be in trouble and might end up redesigning. Also designing stateless web app generally produces much better code. It is usually not too difficult to achieve `statelessness`, if there is such a word :) – Aliostad Feb 01 '11 at 00:13
  • I keep hearing it's bad design but I don't understand why. Here's my plan: when a user pulls a report for a certain date, I store this report in the session so that subsequent request retrieve the data from the session instead of calling the database. These reports don't change because they're historical. Why is this considered bad design? – frenchie Feb 01 '11 at 00:13
  • Have a look also here: http://stackoverflow.com/questions/3902506/asp-net-session-use-or-not-use-and-best-practices-for-an-e-commerce-app/3905154 this is me asking the same question – Aliostad Feb 01 '11 at 00:15
  • `when a user pulls a report for a certain date, I store this report in the session` this is the job for output cache. Don't use session for this, see my other response here: http://stackoverflow.com/questions/4845354/using-sessions-am-i-abusing-it/4845474#4845474 – Aliostad Feb 01 '11 at 00:17
  • In fact it was **your question** I just realised! – Aliostad Feb 01 '11 at 00:18
  • I know, I'm wondering what's the best way to build my app. I want to store the report in the session so that I can do sorting and paging more efficiently by not having to go back to the data source each time the user wants to sort of filter the report. If instead of caching every report I just cache the last report so that I can do the paging/sorting/filtering, is this better? – frenchie Feb 01 '11 at 00:29
  • I see. I suppose this approach can work and actually be beneficial if: 1)amount of data stored in the session is small and 2)Going to DB everytime is really expensive. My personal experience is,going to DB is usually much less expensive than we think so I would suggest you runs some tests and collect metrics. Storing large objects in the session can basically kill your server. – Aliostad Feb 01 '11 at 00:48