Patrice said:
> What issue are you referring to ? It's bit hard to give a "yes" response
> without any context. For example being able to store a connection
> doesn't mean you should (and it has not changed in ASP.NET)...
>
It seems like a generic question, like "is it true that 'int' in C# is
bigger than 'int' in C++?" It's a fact that in ASP we were told that
it's a bad idea to store objects in Session variables because of
threading problems--unless the objects were "both-threaded". I'm asking
whether this issue exists in ASP.NET.
I'm aware of other considerations, such as the fact that Session state
takes up memory and thus poses scalability constraints. As for database
connections, I would expect that storing those is bad because it amounts
to the hoarding of a shared resource. But I'm talking about something
simple, like retrieving a bunch of information applicable to a user's
session when he first logs in, and then retaining it for ready access as
needed throughout the session without having to requery it all from the
database. In ASP I stored all these pieces of data as separate Session
variables. It would be more concise to store them in an object
instantiated from a custom SessionInfo class and then stored in a single
Session variable.
