>Now you have me worried about Session state :\ I'm storing some fairly critical (for this app) stuff in there, such as the logged-in user's DB primary key in the Users table, booleans that control which pages that user can access at any given time, etc. Session state seems perfect for this. Are you saying that in the general case you can't rely on these values being there when you need them? If that's the case, what are the alternatives/workarounds?

No it sounds that's exactly what Session state is for - a few things that are truly relevant for the current user's session.

Session state should be kept relatively light weight because each user gets his own data, so if a site is busy and there are a lot of simultaneous users you can have some significant resource usage. Storing things like tables or even moderately large objects can quickly become a problem under load.

The real issue is that Session state - depending on which mechanism you use - is not persistent. If you use InProc session state, Sessions will clear with an application restart. With Session Server a machine recyle might kill the session state or if the state server gets shut down for whatever reason. The only permanent (built-in) session store is SQL Server.

Obviously this may not happen frequently, but even an occasional hic-up with InProc session state can be enough to really piss off people. <g>