Session Variables - Good or Bad

[Harry Simpson]

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

 

[Sahil Malik]

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

 

[Pipo]

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....

 

[Janaka]

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.

 

[Karl Seguin]

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

 

[Harry Simpson]

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

 

[Sahil Malik]

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

 

[Girish Bharadwaj]

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.

 

[Harry Simpson]

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

 

[Sahil Malik]

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

 

[Sahil Malik]

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

 

[Harry Simpson]

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

 

[Harry Simpson]

I'm for knowledge here...no agendas...just want to understand and then
decide.

Harry

 

[Alvin Bruney [MVP]]

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.

 

[Sahil Malik]

XML is bloated because of all the tags. Imagine the comparison between
<personname>Sahil Malik</personname> versus :1-<<binarycompressedname>>.

Given the nature of datasets, we're talking a LOT of bloat (each row in each
table will have this).

It's fairly simple, serialize a dataset using BinaryFormatter, persist it to
the disk, and open it in notepad. You'll immediately see what I mean .

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

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

 

[Sahil Malik]

Finally, session use is tied to server memory. Developers need to be

responsible in the use of this resource.

<--- That's the basic point of it all. Avoid it if you can, but don't put
yourself in the hospital trying to avoid it.

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

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

are
by web.config
and This
is which
are because
it ok
in

 

[Lucas Tam]

How would one pass a dataset from one screen to the next if not with
Session State? Are you using global variables?

You can cache the dataset to disk (datasets can output to XML) or to a
database.

However, I would probably use Session State if the variable is small.

 

[Alvin Bruney [MVP]]

Session state should not be avoided. This recommendation is not correct.
There is nothing inherently wrong with using session variables. The
recommendation is to use it wisely NOT to avoid its use.

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

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

<--- That's the basic point of it all. Avoid it if you can, but don't put
yourself in the hospital trying to avoid it.

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

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

Allright, I disagree .. Let me explain why ---

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).

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).

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.

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.

Finally, ASP.Net 2.0's provider model will provide even more
choice.
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 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/


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


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

 

[Sahil Malik]

Alvin ...

It should be avoided. Use it wisely - but in real projects people almost
never do; and whole websites come down; and then people criticize microsoft
technology.

Also, read my post 3 messages up - even if you use session station IN
ASP.NET, it still isn't the ideal cheap scalable solution in many cases -
EVEN in ASP.NET.

The worst thing you can do is stick objects in session variables, because
unless superman wrote your objects, you'd have memory leaks, and you will
find yourself rebooting your webservers twice a day under heavy load. A lot
of it is judgement - you might be able to get away with it because you might
not have enough load on your servers.

So I stick by what I said - avoid it if you can, but don't put yourself in
the hospital trying to avoid it.

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

Session state should not be avoided. This recommendation is not correct.
There is nothing inherently wrong with using session variables. The
recommendation is to use it wisely NOT to avoid its use.

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

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

<--- That's the basic point of it all. Avoid it if you can, but don't put
yourself in the hospital trying to avoid it.

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

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

Allright, I disagree .. Let me explain why ---

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).

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).

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.

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.

Finally, ASP.Net 2.0's provider model will provide even more
choice.
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 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/


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


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

 

[Girish bharadwaj]

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

Session state should not be avoided. This recommendation is not correct.
There is nothing inherently wrong with using session variables. The
recommendation is to use it wisely NOT to avoid its use.

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

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

<--- That's the basic point of it all. Avoid it if you can, but don't put
yourself in the hospital trying to avoid it.

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

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

Allright, I disagree .. Let me explain why ---

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).

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).

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.

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.

Finally, ASP.Net 2.0's provider model will provide even more
choice.
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 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/


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


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