Steve Hebert's Development Blog

Steve's Blog - From .Net to dotMath and everything in between.

Dear Microsoft... please abolish in-memory session state.. Thank you.

I'm generally not a fan of cork-on-a-fork approaches to protecting programmers, but here's one case where I think everyone could benefit...

I've heard of too many ASP.NET web projects that rely on in-memory session state when they make the transition from beta to 1.0 and they are killed by open connections. Here's some background if you aren't aware of the situation. If the project has session state saved to a database or state server, the ASPNET worker process can be recycled according to a host of criteria and session state is maintained without the users being aware of any problems. When session state is saved in-process on the ASPNET worker process, recycling the hung process terminates all session and the users are suddenly returned to their login screen (presuming your logic handles terminated sessions correctly). Open connections can be caused by database objects that have not been properly .Dispose()d in light of the latency introduced by garbage collection. Too many open connections brings the database server and, consequently, the web server to its knees.

In-memory session state is great for throwing together a demo and working on your laptop, but any real web project should never be using in-memory session state. Starting any web project coding, this would be on my top 5 list of things to do. That said, you can run a project with in-memory state activated and it works fine if the code is fully tested (includes memory profiling and execution of test suites) - but the risks you take impact the managability of the running product.

Bottom line... given that Microsoft is shipping products like MSDE and eventually SQL Server 2k5 express for free, make it the default and throw away in-memory session state altogether.

Published Apr 07 2005, 07:29 AM by shebert

Filed under: Development

Comments

Robin Curry said:

I'd have to agree that this can cause quite a problem, but unfortunately things don't get a whole lot better when you switch to SQLServer Session State due to all the idiosyncracies with serialization. All of your developers have to remember to think about and mark all of their objects (that may ever be stored or be part of something that is stored in session) as Serializable. Too many things (Microsoft things) can't be serialized, or at least not easily. You can lose the benefit of storing a large object graph in session because of the serialization hit, etc. I'm working with a large legacy project right now that just converted from in memory to sql server session state, and I'd have to say that it was quite painful.

# April 7, 2005 8:56 AM

shebert said:

There definitely are issues with serializing with respect to SQL Server, but the long-term cost of in-process state outweighs it.

Things that are large - i.e. graphs - I either write directly to the file system or store in a blob on the database and avoid the session state altogether. This way I can manage storage better without consuming memory on the server. And with the database I can manage placement of the files to minimize fragmentation due ot the nature of BLOBs.

# April 7, 2005 9:37 AM

darrell said:

Are you including "in-memory in-process" AND "in-memory external process" in your in-memory request? Using an in-memory external process for session state would avoid the logout problem but would be generally faster than database session state.

# April 7, 2005 10:23 AM

shebert said:

No, in-memory external process is fine and with the right system config can work nicer than a database-d system. The problem comes when you hold session state within the same process as your application.

# April 7, 2005 12:03 PM

Pedrito said:

I have to disagree. Using SQL server state management is not only problematic for the serialization issues already mentioned, but it doesn't scale well for large user base applications where the hit on the database is already high, thus adding that "extra" hit every single request simply for state management.

# April 7, 2005 1:24 PM

shebert said:

Yes, but if you're looking for scalability from the webserver, you won't use default in-memory session state for the purpose of using a farm of web servers. I don't like the fact that the default choice imposes such a number of potential managability issues over a products life cycle.

# April 7, 2005 1:50 PM

shebert said:

This brings up another thought... I wonder how you can isolate and profile session state. I haven't tried this with DevPartner Studio - that would be interesting to quantify the effects that each user has on server memory and the speed that any serialization is having on the server.

# April 7, 2005 2:46 PM

Paul Wilson said:

In-Memory Session can be great for small sites, not to mention quick prototypes, so getting rid of it is in my opinion a STUPID idea. Should you use it in most situations -- probably not, but that doesn't mean it doesn't have a valid use. And I find your argument for why it can be terrible to be spurious -- developers should not be leaving database connections open, nor putting anything that depends on them in session. Using that argument we could just as well expect MS to remove all capabilities of working with underlying database connections and force us to only use disconnected objects.

# April 7, 2005 5:01 PM

shebert said:

Paul, is there something you're not saying... I wouldn't want you to hold anything back. ;)

Even if MS rolled out the in-memory, out of process state server as default we'd be better off. The inprocess state server is great for prototypes, but if the effort was placed into installing the out-of-process state server the pain could be nearly non-existant.

The database connection issues caused by improper handling of the IDispose interface are not the fault of in-process state - but rather poor programming. However they illustrate one of many problems that in-process state can have on a project. In-process state should be considered like riding a moped - a lot of fun to ride but you don't want your friends to see you on one.

# April 8, 2005 7:00 AM

Harry Fuecks said:

Think the term that's arisen around what you're describing is "shared nothing architecture", effectively popularized by Rasmus Lehrdorf of PHP fame (see "Advice for Architects" in http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html).

# April 14, 2005 1:29 AM