>for every user, so it's real easy to get really large session stores and lots of objects in memory (In Proc) or tons of network traffic marshalling (SessionServer or SQL Sessions).
>
>So tell me Rick, how is storing your Session objects in SQL Server any different, network-traffic-wise, then re-running your queries? Seems like six of one, half dozen of the other, if you ask me. <g> In which case, I think storing your DataSets (or objects) in Session objects is cleaner. Just my 2 cents. =)

You can't rely on your session being stored in SQL Server. If you have InProc sessions you incur the memory overhead. If you have state server sessions you incur the memory hit on the state server (which is most likely going to be local). If you're using SQL Server or StateServer for storage the data is also serialized and deserialized so the storage isn't free - in fact if the data is sizable this can be very extensive and in many cases the processing hit is likely to be bigger than re-running a query.

This is just not done in high end Web applications - it doesn't scale. It might work OK on internal applicatinos that don't have a lot of users, but even with few users the storage requirements (memory or disk) can get horrendous very quickly because things you store in Session don't go away unless you explicitly clear them out. That means there's a lot of stuff floating around usually (unless your super diligent about cleaning up) for the duration of the session timeout. A single user may have 10 datasets going all stored in Session... now multiply that time 100 or a 1000 and you can see where this is going.

Session storage is meant to be a storage place for small reference items. You're still working on a database application - so use the database to its fullest extent.