Storing objects in Session variables

  • Thread starter Thread starter Harlan Messinger
  • Start date Start date
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)...
 
Harlan Messinger said:
At http://www.eggheadcafe.com/articles/20021016.asp I read that:

"If you are using InProc mode, objects stored in session state are
actually live objects, and so you can store whatever object you have
created."

This wasn't true in classic ASP; is it true in ASP.NET?
Click to expand...

The simple answer to the question is yes. But filling session with tons of
objects is still not a desirable state. It is not a proper cache, per se, so
there are better ways to cache objects, if that is your goal. As Patrice
mentions, it is still not wise to create a SQL connection object and store
in session, but since there is a pool, holding a connection is not a good
idea no matter where you might want to store it.

I have to agree with Patrice: what problem are you trying to solve?

--
Peace and Grace,
Greg

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

************************************************
| Think outside the box! |
************************************************
 
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)...
Click to expand...
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.
 
Harlan Messinger said:
At http://www.eggheadcafe.com/articles/20021016.asp I read that:

"If you are using InProc mode, objects stored in session state are
actually live objects, and so you can store whatever object you have
created."

This wasn't true in classic ASP; is it true in ASP.NET?
Click to expand...

To answer your question simply, without preaching to you about how you might
choose to use the feature: yes - you can store objects in the Session when
you are using InProc mode, and operate on them freely. For any other type of
session store, the objects need to be serializable, either through .Net
framework serialization functionality or through any other serialization
process that you yourself may create.

Tom Dacon
Dacon Software Consulting
 
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.
Click to expand...

This is the other way round.

ASP.NET uses MTA. You can force STA using the ASPCompat attribute :
http://msdn.microsoft.com/en-us/library/zwk9h2kb.aspx

IMO, it's unlikely you'll ever have to use COM components and much less
storing them in session variables...
 
Back
Top