OT: Storing object(s) in ASP.Net session

OT: Storing object(s) in ASP.Net session

Old forum URL: forums.lhotka.net/forums/t/5418.aspx


richardb posted on Wednesday, September 17, 2008

I notice in the ProjectTracker samples that when fetching an object, Rocky stores the object in a Session variable.  When the web page comes to save the work, it retrieves the object from the session (if it can find it) and then saves it, storing the result back into the session variable.

This saves network and database processing but the cost is memory on the web server.

Is this cost ever too high?  I've worked for clients before who frowned upon using the Session for absolutely anything (which was a real pain at times).

In a web farm / cluster scenario am I right in that when the page is submitted the chances are that you'll be on another web server anyway so the object won't be found in the Session anyway.  Although can't you configure ASP.Net to store it's Session in a SQL database in this situation - which might mean it's not worth doing anyway - you might as well get it from the database again - ah but hold on the data may have changed so I probably wouldn't want to do that, would I?

This question might be better off in an ASp.Net forum, but hey - the people who post here seem to be much more on top of the game, so any thought as much appreciated.

Richard.

JoeFallon1 replied on Wednesday, September 17, 2008

All valid questions.

Here is my take on it.

1. If you need Session then use it.

2. In a high throughput web site with hundreds of thousands of users you should probably avoid it if at all possible.

3. In a line of business application with tens of users (or hundreds) it is a tradeoff.

4. The key for me is to keep data entry form BOs in Session so that the user can postback and receive messages or go do something else and return later to what they were working on.

5. Other BOs are only in Session long enough to let the user do their work - when they "move on" then the BO is removed. I am thinking of result set pages here. The BO needs to be in session if the user re-sorts the list or changes pages. This assumes you do not want to hit the DB in those cases because the DB is a bottleneck and you would rather hold on to the list until they are done with it.

6. A users Session is kept in local memory by default. This is the fastest solution. But it is also the most high risk solution and fails when there is a web farm. The biggest risk comes from the ASP.Net appdomain getting recycled - which happens more often than many people realize. In that case your logged on user loses everything and can't recover. They have to log back  in.

7. There are two solutions for a web farm and the recycling problem.

First is the use of an ASP.Net State Server. You just change the config file and point it to a different web server with a huge amount of RAM on it. So if you have 3 web servers in a farm, you would add a 4th web server as a State Server and point the other 3 to it. Then the session object is serialized back and forth to each of the web servers in the farm, depending on who asked for it. So there is no session affinity in the web farm. No need for "sticky sessions". Note: the trade off here is time - it takes time to serialize data between 2 servers. But if the user is in the middle of something, you really can't hit the DB and force them to start over, can you?

The 2nd solution is the one you noted about using SQL Server to store session. The speed differential for serialization is about the same as a State Server. But a SQL DB has some advantages - permanent storage of sessions. So a power outage should let the user pick up where he left off. Whereas a State Server re-boot would lose all the transient data in RAM. More session data can be stored in SQL than in RAM. The tradeoff is cost - you have to pay for the SQL DB and server. The big thing you may be overlooking with this is that the SQL State Server does *NOT* have to be the same server or DB or box that you are using for your application!! It can be a totally different box. One that is not the bottleneck of your app. So the fear of overloading "the database" by adding sessions to it can be alleviated by using a different server and database.

HTH

Joe

 

richardb replied on Wednesday, September 17, 2008

That's excellent Joe - thanks for that advice.

Copyright (c) Marimer LLC