Session Variables - Good or Bad

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
MCSDSession variables - bad.
All the session state schemes rely on a centralized model - that can never
be good for scaleability.
But if it means you will have to write tonnes of code for a website that has
5 concurrent users, then go ahead use 'em. (never overarchitect).
- Sahil Malik
You can reach me thru my blog at
http://www.dotnetjunkies.com/weblog/sahilmalik
"Harry Simpson" <hssimpson@.nospamphgt.net> wrote in message
news:%23pITF8GsEHA.760@.tk2msftngp13.phx.gbl...
> 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
>
We use it only if there is no other (easy) way.
Basicly its not done or you have to have a very good reason.
And if you dont clean them up when you're done with them...you'll get
punished ...;-)
Most variables can be covered by the viewstate and querystring to pass them
to an other screen.
But thats just our policy I guess...
"Harry Simpson" <hssimpson@.nospamphgt.net> schreef in bericht
news:%23pITF8GsEHA.760@.tk2msftngp13.phx.gbl...
> 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
>
I disagree with the two answers given so far, sessions in ASP were evil 'cuz
they were stored in the same memory space as the worker process. This is
true in ASP.Net as well when you have it set for InProc. It isn't true for
either StateServer or SQLServer. As far as scalability, SqlServer mode
scales very well and doesn't rely on a centralized model (no more so than
any other SQL Server database). What's even better is how easy it is to
switch modes - so long as you were careful to design all objects which are
to be stored in sessions as serializable (normally achieved simply by
specifying the ISerializableAttribute() to the class) you simply change your
web.config and off you go.
Finally, ASP.Net 2.0's provider model will provide even more choice.
Karl
MY ASP.Net tutorials
http://www.openmymind.net/
"Sahil Malik" <contactmethrumyblog@.nospam.com> wrote in message
news:O53hT$GsEHA.3728@.TK2MSFTNGP09.phx.gbl...
> Session variables - bad.
> All the session state schemes rely on a centralized model - that can never
> be good for scaleability.
> But if it means you will have to write tonnes of code for a website that
has
> 5 concurrent users, then go ahead use 'em. (never overarchitect).
> - Sahil Malik
> You can reach me thru my blog at
> http://www.dotnetjunkies.com/weblog/sahilmalik
>
> "Harry Simpson" <hssimpson@.nospamphgt.net> wrote in message
> news:%23pITF8GsEHA.760@.tk2msftngp13.phx.gbl...
> When
was
>
My view is that session variables can be good when you need to store object
information or large amounts of data per session without having to make
repeat database calls every time.
This still shouldn't be an excuse for good design. You should also ensure
you dispose of your session variables properly so they aren't hanging around
taking up memory.
In most cases though I opt for using querystring parameters, cookies, hidden
fields or ViewState to manage session information.
"Harry Simpson" <hssimpson@.nospamphgt.net> wrote in message
news:%23pITF8GsEHA.760@.tk2msftngp13.phx.gbl...
> 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
>
Allright, I disagree .. Let me explain why --

on a centralized model (no more so than any other SQL Server database).
SqlServer scalability is acheived using failover and clustering. Not using
Network Load Balancing and Web Farms (redundancy). Web farm machines are by
far much cheaper than Sql server clustering architecture. What's more, by
using Session variables and not specifying state server, you loose any
prayer of ever being able to use a webfarm well enough. Not to mention, you
have one point of failure, and hardware limitations on that one poor box
acting as the state machine. By using a state server you donot lock yourself
up into an app that will never scale - but you make it pretty damn expensive
to scale in future - which is the whole point, you want to acheive
scalability cheaply by adding/removing machines at runtime without bringing
the entire site down. (therefore www24.microsoft.com).
were careful to design all objects which are to be stored in sessions as
serializable (normally achieved simply by specifying the
ISerializableAttribute() to the class) you simply change your web.config and
off you go.
Objects in session are even worse. If you have a memory leak, you just
fixated that memory leak in a process that won't die (IIS). Not to mention
there is nothing like ISerializableAttribute, but there is a
SerializableAttribute and an ISerializable interface. SerializableAttribute
works .. well most of the times; but first of all it's behavior is limited,
(it's not that smart), and it has troubles with protected members and
delegates.ISerializable on the other hand depends on the programmer's
efficacy - which I try and not rely on in a website that is highload -
typically multi megabyte source code - you cannot practically enforce good
programming all over.
Makes no difference to the above facts.
The rule is - Try very hard to avoid session - but don't put yourself in a
hospital trying to avoid it.
- Sahil Malik
You can reach me thru my blog at
http://www.dotnetjunkies.com/weblog/sahilmalik
"Karl Seguin" <karl REMOVE @. REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:%23N3ZFFHsEHA.3848@.TK2MSFTNGP14.phx.gbl...
> I disagree with the two answers given so far, sessions in ASP were evil
'cuz
> they were stored in the same memory space as the worker process. This is
> true in ASP.Net as well when you have it set for InProc. It isn't true
for
> either StateServer or SQLServer. As far as scalability, SqlServer mode
> scales very well and doesn't rely on a centralized model (no more so than
> any other SQL Server database). What's even better is how easy it is to
> switch modes - so long as you were careful to design all objects which are
> to be stored in sessions as serializable (normally achieved simply by
> specifying the ISerializableAttribute() to the class) you simply change
your
> web.config and off you go.
> Finally, ASP.Net 2.0's provider model will provide even more choice.
> Karl
> --
> MY ASP.Net tutorials
> http://www.openmymind.net/
>
> "Sahil Malik" <contactmethrumyblog@.nospam.com> wrote in message
> news:O53hT$GsEHA.3728@.TK2MSFTNGP09.phx.gbl...
never
> has
> was
that
>
In programs past, I've never had more than about 50 concurrent users and
sessionstate has never been a problem (InProc et all).
How would one pass a dataset from one screen to the next if not with Session
State? Are you using global variables?
TIA
Harry
"Janaka" <janakaf@.hotmail.com> wrote in message
news:OinBhHHsEHA.1988@.TK2MSFTNGP09.phx.gbl...
> My view is that session variables can be good when you need to store
> object information or large amounts of data per session without having to
> make repeat database calls every time.
> This still shouldn't be an excuse for good design. You should also
> ensure you dispose of your session variables properly so they aren't
> hanging around taking up memory.
> In most cases though I opt for using querystring parameters, cookies,
> hidden fields or ViewState to manage session information.
>
> "Harry Simpson" <hssimpson@.nospamphgt.net> wrote in message
> news:%23pITF8GsEHA.760@.tk2msftngp13.phx.gbl...
>
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
"Harry Simpson" <hssimpson@.nospamphgt.net> wrote in message
news:%23pITF8GsEHA.760@.tk2msftngp13.phx.gbl...
> 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
>
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
"Girish Bharadwaj" <girishb@.mvps.org> wrote in message
news:%23mTyVQIsEHA.3324@.TK2MSFTNGP15.phx.gbl...
> 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
> "Harry Simpson" <hssimpson@.nospamphgt.net> wrote in message
> news:%23pITF8GsEHA.760@.tk2msftngp13.phx.gbl...
> When
>
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
"Harry Simpson" <hssimpson@.nospamphgt.net> wrote in message
news:ebElWiIsEHA.2264@.TK2MSFTNGP10.phx.gbl...
> 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
> "Girish Bharadwaj" <girishb@.mvps.org> wrote in message
> news:%23mTyVQIsEHA.3324@.TK2MSFTNGP15.phx.gbl...
that
to
Sessions.
that
>