does a change to an ASP.NET site kill active sessions?

views:

333

answers:

+4 Q:

does a change to an ASP.NET site kill active sessions?

I'm concerned about the possibility of my users' sessions getting swept away. I am using the default ASP.NET Session object and session cookies. I know that sessions can time out, and I have set the timeout value for my sessions to several hours to avoid surprise timeouts.

But there are at least two other cases I'm worried about.

(1) I understand that ASP.NET periodically recycles the app domain running a site/web app (not sure if I have all the terminology correct here). Do sessions live across these recycle events?

(2) At least on my development server, certain changes that I make to the site (e.g., adding a new page) seem to cause the active session to be lost when the site (or part of it) is recompiled. This does not seem to happen with every change, but with many it does. I'm particularly concerned about what this means for the possibility of changes while my site is live. I'd like to know the rules for what I can update without causing active sessions to be killed.

Thanks for any pointers.

+3 A:

This depends on your mode of session state. Here's a copy of something you can find on Microsoft Support:

ASP.NET supports three modes of session state:

InProc: In-Proc mode stores values in the memory of the ASP.NET worker process. Thus, this mode offers the fastest access to these values. However, when the ASP.NET worker process recycles, the state data is lost.

StateServer: Alternately, StateServer mode uses a stand-alone Microsoft Windows service to store session variables. Because this service is independent of Microsoft Internet Information Server (IIS), it can run on a separate server. You can use this mode for a load-balancing solution because multiple Web servers can share session variables. Although session variables are not lost if you restart IIS, performance is impacted when you cross process boundaries.

SqlServer: If you are greatly concerned about the persistence of session information, you can use SqlServer mode to leverage Microsoft SQL Server to ensure the highest level of reliability. SqlServer mode is similar to out-of-process mode, except that the session data is maintained in a SQL Server. SqlServer mode also enables you to utilize a state store that is located out of the IIS process and that can be located on the local computer or a remote server.

If you use StateServer or a database your session data will not be lost when IIS detects a change to the website.

Jochen 2009-12-28 08:07:40

@Jochen, it's irrelevant to add chit-chat like 'Hi', 'Hope it helps' etc. :-)

Jan Jongboom 2009-12-28 08:16:20

Thanks. Yes, I also found this: http://www.hanselman.com/blog/CommentView.aspx?guid=1fe4931a-ec50-4288-91e4-8d83a598a5beIt seems I was naively thinking that the InProc solution was reasonable, but it seems bascially useless since you never know when a session might die. I think I'll try the SqlServer option.

M Katz 2009-12-28 08:26:19

In my opinion the StateServer is the easiest to use and best performing one if InProc is not an option.

Jochen 2009-12-28 08:30:34

The problem with StateServer is that the session data still lives only in RAM, so if that process crashes or the machine reboots, you will still lose all current sessions. SQL Server is better, IMO.

RickNZ 2009-12-28 13:26:24

+1 A:

(1) If you use In process session mode on Recycling the application pool you'll lose the session information

(2) Depends if you are using web application or web site model for your asp.net application. Some files are cached on application start and require restart or recompilation if they are changed. The rule of thumb is that if you change Global.asax, config file of add, delete or edit file in \bin folder a restart of the application will be issued and In Process Session data will be lost.

ASP.NET Session has many flaws and many developers do not use it at all. I personally prefer to store data in custom tables in the SQL Server (if available).

If you want to provide more information like what version of IIS do you have, do you use web site or web application model, do you have database server available, do you use web farm or web garden server environment, and what information you want to store and for how long I can give you more concrete advice.

Branislav Abadjimarinov 2009-12-28 08:47:28

Thanks for the additional info. Are you saying that you don't use even the sql server version of ASP.NET sessions? What are the flaws with ASP.NET sql sessions?

M Katz 2009-12-28 21:27:21

In the default mode, the Session module causes two round-trips to the DB: one at the beginning of the page to read the data and to update the session expiration time, and another at the end of the page to update the session data. In addition, it issues an exclusive lock on the session data, so if you have to pages from the same user that could run in parallel (such as with frames or Ajax), they will be forced to run serially, due to the lock. You can mitigate some of the issues by marking pages that either don't need session state, or that only need it in read-only mode.

RickNZ 2009-12-28 21:56:23

I completely agree with RickNZ. Also Session programming model out of the box is not good at all because of the casts needed and there is no management of the objects in session. We have a saying that goes: ASP.NET Session is like a pig - it eats everithing you give it. If you want to use session I suggest to create a proxy class that exposes as properties all objects you want to put in it.

Branislav Abadjimarinov 2009-12-29 08:13:34

Proxy class, or proxy server? It sounds like it might not be so easy in a shared hosting environment, right?

M Katz 2010-01-01 01:22:23

My comment was about the programming model not the hosting environment. When you use a session you access the objects in it with indexers and you need to cast the result. If you want to access typed data you have to create a class that accesses the session and returns the data. Usually a proxy design pattern is used to implement that class. This way you'll control what kind and type of objects you have in session.

Branislav Abadjimarinov 2010-01-01 09:20:33

I see. Thanks for the suggestion. In my case I only have a tiny amount of session data (three strings), but I can see if you had a lot you'd want a class to provide access.

M Katz 2010-01-03 19:04:14

If you're using InProc mode, you will lose session data if the AppPool recycles, which can happen either once a day or so (according to the default schedule), or after about 20 minutes of inactivity on the server.

Regarding page updates: any time you change a file on the live site, there's a chance that the site will restart, as if you changed web.config. Certain files won't cause a full restart, but it's not easy to predict which ones, and it also depends on the compile mode that you're using (batch or not). If you're using the default per-folder batch compilation mode, you should be able to change individual pages in subfolders without forcing a restart. Changes to Master pages, code or controls, though, may cause a restart, as can changes to the top-level folder (depending on what else you have there).

I guess I should add that changing individual files on a live site generally isn't a good idea -- although I'm sure you have your reasons for doing so.

RickNZ 2009-12-28 13:32:13

Thanks for the additional info. I can see why it was mysterious that certain changes caused a session loss and others didn't.On the subject of upgrades, if I want to make small changes without bringing down the site or interrupting user sessions, what are the risks with making small changes on the fly (as long as I know they don't change session state variables, etc.)?

M Katz 2009-12-28 21:23:49

Keep in mind that in the default mode, when you change one file, all of the files in that folder will be recompiled. During that time, users trying to access any of those files will be forced to wait. If the folder is big enough or if you have enough users trying to access those files, your worker threads can all get consumed, and your whole site can pause until the recompile completes. In the worst case, on a busy site, the queue can get so full that users are turned away with "server too busy" errors.

RickNZ 2009-12-28 21:53:08

ansaurus

tags:

views:

answers:

does a change to an ASP.NET site kill active sessions?

related questions