I'm seriously considering DiscountASP as a replacement WebHost4Life who continue to fail to get my web app working. I've ticked most of the boxes with DiscountASP but just remembered the fun & games I had with session state. My application relies, like many ASP.NET apps on session state. I originally developed my app using inproc session state which worked fine on my development environment where the worker process only recycled if the process was idle for 20 minutes. When the site was hosted on WH4L, I was rather shocked how often they recycled the worker process (often as little as a couple of minutes). This was so bad that the web app just annoyed the users. They could pause entering some data into a form for a minute or so and on click save, all their information was lost because the worker process restarted with a new session thus loosing all their transient/login information. So I recoded my app to use StateServer where a the session state is shunted backwards and forwards using serialisation. It was a bit of a pain to implement serialisation across all the objects because they hadn't been there since the start. But since doing that, the app was rock solid - until they sold WH4L and attempted to migrate me to their new platform but that's whole other story! I've read a couple of old posts on here state DiscountASP doesn't support StateServer with only inproc and SQL. I'm reluctant to switch to the later as it'll be much slower (or will it?). Therefore inproc would be the only option. This will be fine if DiscountASP don't do unwanted things with recycling the worker process like recycling it after a certain (low) number of requests or <20 minutes idle. Is this the case? Cheers, Rob.
Yes it is. Specifically, your application pool would not recycle here due to a low number of requests, but zero requests for 20 minutes would cause a recycle and the application would be dropped from memory. That's pretty standard. A server running hundreds of sites needs to control memory use. If we didn't have those controls in place, the servers would very quickly become unusable.
Thanks for this. It does further indicate that DiscountASP is a professional outfit used by professional developers. I have no problem with the worker process being recycled after 20 minutes of inactivity as this is (IMO) a reasoanble time for a page/session to timeout. What WH4L does I think is put multiple applications in a shared application pool and set the other recycle options such as "Recycle after 1,000 requests". Cheers, Rob.
I wouldn't be surprised. But then just about every server at WebHost4Life had a different configuration (according to a couple guys who used to work for them). Now that Endurance bought WebHost4Life, all of that will be standardized. Not for the better, but standardized.
In my experience, you won't really be able to tell the latency with SQL session unless you are storing something massive in session (which is not a good idea anyway). With SQL session, the more common concerns is serializable objects cannot be stored in SQL session.
My banks website pops up a modal dialog when there has been no activity for a while telling me my session is about to timeout in approximately one minute and giving me the option to logoff or continue. Does anyone know how they detect that the session is about to time out without any interaction by the user?
I suspect it's going to be a timing algorithm performed client side in JavaScript as opposed to a client/server handshaking mechanism over http.
