Session Variables - Good or Bad

[Jesse Liberty]

I'm afraid I disagree, and I think your assertion comes from old
information.

First, server memory is one of the cheapest and most efficient alternatives
(what do you prefer when passing data among pages?) Second, session state
can now be off-loaded to a dedicated machine and/or a database. Third, I
don't understand your comment about memory leaks; and it is not my
experience that session state will bring a server to its knees.

--
Jesse Liberty
O'Reilly Author
http://www.LibertyAssociates.com

 

[Harry Simpson]

Thanks for the input. Like i said I've been using Session variables since
2001 when i first used .NET. NEVER ever used them in ASP though.

I've never experienced the kinda of load nor memory leak that Sahil
describes...i could've been a bit away but so far so good....

Harry

It is ok to use session variables. The hang up comes from classic ASP
problems. ASP.NET Session is re-architected to be better, faster and more
efficient than ASP. In fact, outside of superficial similarities, the two
are entirely different animals underneath.

Finally, session use is tied to server memory. Developers need to be
responsible in the use of this resource.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

Actually .. I respectfully disagree .. don't take it personally . .!!
)

- Sahil Malik
You can reach me thru my blog at
http://www.dotnetjunkies.com/weblog/sahilmalik

 

[Girish Bharadwaj]

I agree with Jesse. I think saying "Session variables is bad" is naive. It
serves a really good purpose and particularly with the changes in ASP.NET, I
dont see the problems that used to plague Session vars in classic ASP.
Of course, you can still screw up if you store COM objects (interop based)
within Sessions or by using it more like Cache for large Recordsets.

But, a blanket statements such as "Session variables is bad" in .NET world
does not jive.

 

[Sahil Malik]

Allright we disagree, now lets get along

- Sahil Malik
You can reach me thru my blog at
http://www.dotnetjunkies.com/weblog/sahilmalik

 

[Alvin Bruney [MVP]]

Of course, you can still screw up if you store COM objects (interop based)

within Sessions

that's no longer true either

 

[Girish bharadwaj]

The thread that never dies.
Strictly speaking, there is no problem stuffing a COM interop crap in
Session. But, the problem arises when you need Release that object. As is,
interop is a hack. Stuffing COM interop objects into Sessions probably will
cause memory hogs (not necessarily leaks).


--
Girish Bharadwaj
http://msmvps.com/gbvb

Of course, you can still screw up if you store COM objects (interop
based)
within Sessions

that's no longer true either

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

I agree with Jesse. I think saying "Session variables is bad" is naive. It

 

[Guest]

I think everybody has a point.
I would say if we were exposed to the same project and is confined to making
the same decision on the same environment with the same circumstances then
someone must be wrong. So with all the points expressed, the answer still
depends on what scenario do you need the session object for? if it is just
storing userid, even a celeron server can handle that (at least for a couple
of thousands users at the same time).

 

[Sahil Malik]

By the same argument, if you had memory leaks in your pure .NET objects,
would it be okay to put them in session objects? And oh seriously when did
you last see a complex project without a memory leak? I'd rather trust
standards and design versus the end programmer.

... and again .. if you had a perfect system, and then you stuffed objects in
session, and used a sql state server, you still would have to scale using
clustering versus network load balancing.

- Sahil Malik
You can reach me thru my blog at
http://www.dotnetjunkies.com/weblog/sahilmalik

The thread that never dies.
Strictly speaking, there is no problem stuffing a COM interop crap in
Session. But, the problem arises when you need Release that object. As is,
interop is a hack. Stuffing COM interop objects into Sessions probably will
cause memory hogs (not necessarily leaks).


--
Girish Bharadwaj
http://msmvps.com/gbvb

Of course, you can still screw up if you store COM objects (interop
based)
within Sessions

that's no longer true either

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

I agree with Jesse. I think saying "Session variables is bad" is naive.

It

 

[Sahil Malik]

The thread that never dies.

<-- Yup, this is worse than the presidential debates.

- Sahil Malik
You can reach me thru my blog at
http://www.dotnetjunkies.com/weblog/sahilmalik

The thread that never dies.
Strictly speaking, there is no problem stuffing a COM interop crap in
Session. But, the problem arises when you need Release that object. As is,
interop is a hack. Stuffing COM interop objects into Sessions probably will
cause memory hogs (not necessarily leaks).


--
Girish Bharadwaj
http://msmvps.com/gbvb

Of course, you can still screw up if you store COM objects (interop
based)
within Sessions

that's no longer true either

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

I agree with Jesse. I think saying "Session variables is bad" is naive.

It

 

[Kevin Spencer]

Session State is a tool. Would you debate over whether a hammer is good or
bad? You can certainly injure or even kill yourself with one if you misuse
it. Does that make it a bad tool? Try hammering a nail with a screwdriver
and get back to me.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

 

[Guest]

XML bloats a dataset by 6-10 times on the average, because the structure is
made explicit and embedded into the doc. Plus, there are all those
housekeeping tags, closing tags, etc etc.

Sahil,

XML is ultra bloated? I thought that it was as slim as you could go....why
do you say this (if you have a second to explain)...?

Thanks!
Harry

Harry,

Datasets are serializable, but their serialization format is XML (cannot
override; atleast not easily) which is ultra bloated.
Not all objects that come with .NET are serializable by default.

Your best bet is to implement simplistic structures to represent the data
you need to store in session - but again, try and avoid using session
variables.

- Sahil Malik
You can reach me thru my blog at
http://www.dotnetjunkies.com/weblog/sahilmalik

Thanks Sahil and Girish,

The web apps are just that apps used by a limited number of concurrent
users. It's not an E-bay or Amazon deal.

dataset and other builtin datatypes are serializable from the getgo
right.
I just need to declare homegrown objects as such?

Appreciate your time and effort responding to this thread. Bottom line
is
use minimally.

One other item, I've never cleaned up after my sessions because by
definition, the variables are destroyed when the session ends
anyhoo....is
this not correct...? I haven't been bit yet by not cleaning up...

Harry

You can only get a "Contracter's answer" for this. "It Depends".
If you are coming from the classic ASP background, you tend to shy away
from
Session objects since they were wrought with issues in COM
threading/server
affinity et al. With ASP.NET, most of these issues have a solution.

You can use Session for almost anything. Just be careful to make sure that
any objects you mght stuff in there are [serializable] if you ever want to
use StateSErver or SqlServer.

With 2.0, you get more choices for session management.

All in all, I dont see any reason to go out of your way to avoid Sessions.

--
Girish Bharadwaj
http://msmvps.com/gbvb
I've come from the old ASP camp where session variables were not used.
When
i started using ASP.NET in 2001, I started using them again because it
was
ok from what I'd read.

I've been merrily using Session variables for three years now and i'm
entering a project with my new boss who has never quite come around that
session variables are ok.

What's the concensus here. How can i convince him that they are ok in
ASP.NET. OR

Are there those out there that still think they aren't good to use?

TIA

Harry Simpson
MCSD

 

[Guest]

I've not seen anyone say what has been my general rule, and the rule shared
by most I develop with.

Use Session for things that do not change during the session. Things like
your user name, your full name for display, etc. Same with Application level
variables (although use these VERY SPARINGLY, if at all). Just take it back
to declaring variables at the proper scope.

Beyond that if you need to get a single variable from A to B, like choosing
an item from a list to edit, just use the query string or a form post
depending on your UI.

Also, EVERY time you use a Session or Application variable be sure you
explicitly clean-up after yourself. Those I work with and I don't flog
people for using Session, but we do flog for not cleaning up after yourself.
And that goes for every level of variables not just session. So, write good
code, use intelligent practices, be consistent, and enjoy the wonders of OOP.
And remember not to take any of this too seriously, it's a job, a hobby, an
interest, and unless you are writing software that could kill a person, relax
dudez, it just isn't that big of a deal.