>Makes sense.

Yeah, I use StateServer all the time - it's simply the best choice. InProc is just not an option for ASP.Net IMHO.


>I guess the one main point behind using tables as opposed to using the session really comes down to this: needing the data to live beyond a session's lifetime in some sort of "raw" (and easily queried) form. Otherwise, the Session and/or Cache a better (performance) bet.

Yes this makes sense, if you need the data. In most of my apps the user specific data is also stored in tables, but I usually update this data as needed (which usually happens only when the data changes anyway during some sort of editing). Counts are also nice (like in WC) which tells you how many times a session was accessed etc. as well as a path through site (which tracks each link eht user goes to). This is good to know for statistics, but again those kinds of things require an additional data hit.

There's always a trade off between gathering information and performance. For examlpe, in my Web Store app I track requests (optionally) to a log file. I find this information quite useful for being able to see usage patterns at a glance and for debugging. In some apps I have actually taken to having one last requrest batch to the Sql backend that performs all 'housekeeping' operations in one swoop. Logging, Session type data write out etc. This way at least you minimize the round trips that happen on the server.