views:

175

answers:

2

I just noticed this about a week ago. I'm storing data about the current puzzle a user is playing (www.wikipediamaze.com) like this:

HttpContext.Current.Session.Add("puzzleInfo", currentPuzzleInfo);

I know that storing data in the session using the "InProc" mode is very volatile and will get reset whenever the web.config changes or any number of other factors including recycling the app pool.

However my data is only staying for a few seconds at a time (the time is variable but literally not long at all) and then disappearing. I'm in a shared hosted environment so I don't know if that would have anything to do with it.

Any idea what's going on? Would I be better off just storing it directly on the client as a cookie? Please help.

Thanks!

+2  A: 

Troubleshooting

Losing data every few seconds is unusual, there could possibly be a problem with your shared hosting provider -- sounds like the server is constantly dropping sessions for some reason. You could display the sessionID (Session.SessionID) and see if it changes.

There could be a process crash going on, caused by someone else on the server. Here's an msdn blog post on troubleshooting this type of problem (scroll down about 25% of the way through): http://blogs.msdn.com/webtopics/archive/2009/07/22/in-proc-session-state-management.aspx

This won't be much help to you in a shared hosting environment, but you could pass it up the support chain. Maybe they could look at the event logs and determine who is breaking IIS and give them the boot.

As stated by Sean McDonough:

...given that you're in a shared hosting environment, there's a decent chance that there is more than one web server hosting your site. If multiple servers are serving up your site and a load balancing mechanism is in-use that doesn't maintain any sort of session affinity, you could simply be bouncing to a different web server and starting a new session; after all, in-proc session is not going to follow you across boxes.

Alternatives for State Persistance

At any rate, I have always found InProc to be intermittently unreliable even on dedicated servers, and so I avoid it.

Be cautious with cookies -- cookies get transmitted along with each request (images, scripts, etc) and should be kept down to the bare minimum. You may think, "Meh, this project doesn't need to scale," but once you make the project-wide design decision that you're going to use cookies to persist your state, you are cruising for a proverbial bruising.

And by that I mean, you are stepping out of best practices and may run into some ugly situations, like that time I needed to persist an xml document for a second. That would not be a good idea in a cookie!

If you don't have a way to set up session state server (which is really easy by the way) because you're in a shared hosting environment, you could look into SqlSessionStateStore, which lets you store your session data in a SQL Server.

Brian MacKay
+2  A: 

Brian's suggestions are excellent, and I couldn't agree more with the points he makes. I'd also like to offer one additional possibility.

Do you know much about the environment in which your application is being hosted? I ask for the following reason: given that you're in a shared hosting environment, there's a decent chance that there is more than one web server hosting your site. If multiple servers are serving up your site and a load balancing mechanism is in-use that doesn't maintain any sort of session affinity, you could simply be bouncing to a different web server and starting a new session; after all, in-proc session is not going to follow you across boxes.

Food for thought :-)

Sean McDonough
Great point. Upvote, but marked Brian as answer.
Micah
Good thought Sean. Hopefully they wouldn't do something like that without session affinity, but you never know...
Brian MacKay
Heh ... yeah, I would hope they wouldn't bounce requests around without establishing affinity (at least without saying so), but figured it wouldn't hurt to mention it :-) Regardless, glad that Micah got the answer he needed from Brian!
Sean McDonough
It could also be related to Application Pool recycles. You can check in IIS or have your host company tell the settings for your application pool. There are limit in minutes, a fixed time of the day and resource based (e.g. virtual memory reaches 500mb)
Flavio