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.
Read: Dear Microsoft... please abolish in-memory session state.. Thank you.
Previous Topic
