By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,046 Members | 2,105 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,046 IT Pros & Developers. It's quick & easy.

Session Variables - Good or Bad

P: n/a
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
Nov 18 '05 #1
Share this Question
Share on Google+
31 Replies


P: n/a
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" <hs*******@nospamphgt.net> wrote in message
news:%2***************@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

Nov 18 '05 #2

P: n/a
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" <hs*******@nospamphgt.net> schreef in bericht
news:%2***************@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

Nov 18 '05 #3

P: n/a
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" <co*****************@nospam.com> wrote in message
news:O5**************@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" <hs*******@nospamphgt.net> wrote in message
news:%2***************@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


Nov 18 '05 #4

P: n/a
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" <hs*******@nospamphgt.net> wrote in message
news:%2***************@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

Nov 18 '05 #5

P: n/a
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 news:%2****************@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" <co*****************@nospam.com> wrote in message
news:O5**************@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" <hs*******@nospamphgt.net> wrote in message
news:%2***************@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



Nov 18 '05 #6

P: n/a
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" <ja*****@hotmail.com> wrote in message
news:Oi**************@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" <hs*******@nospamphgt.net> wrote in message
news:%2***************@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


Nov 18 '05 #7

P: n/a
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" <hs*******@nospamphgt.net> wrote in message
news:%2***************@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

Nov 18 '05 #8

P: n/a
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" <gi*****@mvps.org> wrote in message
news:%2****************@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" <hs*******@nospamphgt.net> wrote in message
news:%2***************@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


Nov 18 '05 #9

P: n/a
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" <hs*******@nospamphgt.net> wrote in message
news:eb**************@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" <gi*****@mvps.org> wrote in message
news:%2****************@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" <hs*******@nospamphgt.net> wrote in message
news:%2***************@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



Nov 18 '05 #10

P: n/a
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

"Sahil Malik" <co*****************@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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 news:%2****************@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" <co*****************@nospam.com> wrote in message
news:O5**************@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" <hs*******@nospamphgt.net> wrote in message
news:%2***************@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
>
>



Nov 18 '05 #11

P: n/a
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

"Sahil Malik" <co*****************@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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" <hs*******@nospamphgt.net> wrote in message
news:eb**************@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" <gi*****@mvps.org> wrote in message
news:%2****************@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" <hs*******@nospamphgt.net> wrote in message
> news:%2***************@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
>>
>>
>
>



Nov 18 '05 #12

P: n/a
I'm for knowledge here...no agendas...just want to understand and then
decide.

Harry

"Sahil Malik" <co*****************@nospam.com> wrote in message
news:Oc**************@TK2MSFTNGP15.phx.gbl...
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

"Sahil Malik" <co*****************@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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 news:%2****************@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" <co*****************@nospam.com> wrote in message
> news:O5**************@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" <hs*******@nospamphgt.net> wrote in message
> > news:%2***************@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
> > >
> > >
> >
> >
>
>



Nov 18 '05 #13

P: n/a
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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:Oc**************@TK2MSFTNGP15.phx.gbl...
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

"Sahil Malik" <co*****************@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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 news:%2****************@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" <co*****************@nospam.com> wrote in message
> news:O5**************@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" <hs*******@nospamphgt.net> wrote in message
> > news:%2***************@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
> > >
> > >
> >
> >
>
>



Nov 18 '05 #14

P: n/a
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
"Harry Simpson" <hs*******@nospamphgt.net> wrote in message
news:uP**************@TK2MSFTNGP09.phx.gbl...
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

"Sahil Malik" <co*****************@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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" <hs*******@nospamphgt.net> wrote in message
news:eb**************@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" <gi*****@mvps.org> wrote in message
news:%2****************@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" <hs*******@nospamphgt.net> wrote in message
> news:%2***************@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
>>
>>
>
>



Nov 18 '05 #15

P: n/a
> 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
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:OW**************@TK2MSFTNGP10.phx.gbl... 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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:Oc**************@TK2MSFTNGP15.phx.gbl...
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

"Sahil Malik" <co*****************@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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 news:%2****************@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" <co*****************@nospam.com> wrote in message
> news:O5**************@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" <hs*******@nospamphgt.net> wrote in message
> > news:%2***************@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
> > >
> > >
> >
> >
>
>



Nov 18 '05 #16

P: n/a
"Harry Simpson" <hs*******@nospamphgt.net> wrote in
news:eU**************@TK2MSFTNGP14.phx.gbl:
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.

--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
Nov 18 '05 #17

P: n/a
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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:Ok**************@TK2MSFTNGP09.phx.gbl...
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
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:OW**************@TK2MSFTNGP10.phx.gbl...
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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:Oc**************@TK2MSFTNGP15.phx.gbl...
> 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
>
> "Sahil Malik" <co*****************@nospam.com> wrote in message
> news:%2****************@TK2MSFTNGP10.phx.gbl...
>> 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 news:%2****************@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" <co*****************@nospam.com> wrote in message
>> > news:O5**************@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" <hs*******@nospamphgt.net> wrote in message
>> > > news:%2***************@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
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>



Nov 18 '05 #18

P: n/a
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


"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:uA**************@TK2MSFTNGP09.phx.gbl...
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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:Ok**************@TK2MSFTNGP09.phx.gbl...
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
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:OW**************@TK2MSFTNGP10.phx.gbl...
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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:Oc**************@TK2MSFTNGP15.phx.gbl...
> 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
>
> "Sahil Malik" <co*****************@nospam.com> wrote in message
> news:%2****************@TK2MSFTNGP10.phx.gbl...
>> 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 news:%2****************@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" <co*****************@nospam.com> wrote in message
>> > news:O5**************@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" <hs*******@nospamphgt.net> wrote in message
>> > > news:%2***************@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
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>



Nov 18 '05 #19

P: n/a

--
Girish Bharadwaj
http://msmvps.com/gbvb
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:uA**************@TK2MSFTNGP09.phx.gbl...
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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:Ok**************@TK2MSFTNGP09.phx.gbl...
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
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:OW**************@TK2MSFTNGP10.phx.gbl...
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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:Oc**************@TK2MSFTNGP15.phx.gbl...
> 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
>
> "Sahil Malik" <co*****************@nospam.com> wrote in message
> news:%2****************@TK2MSFTNGP10.phx.gbl...
>> 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 news:%2****************@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" <co*****************@nospam.com> wrote in message
>> > news:O5**************@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" <hs*******@nospamphgt.net> wrote in message
>> > > news:%2***************@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
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>



Nov 18 '05 #20

P: n/a
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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:us*************@TK2MSFTNGP11.phx.gbl...
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. The worst thing you can do is stick objects in session variables, because
unless superman wrote your objects, you'd have memory leaks......So I
stick by what I said - avoid it if you can, but don't put yourself in the
hospital trying to avoid it.

Nov 18 '05 #21

P: n/a
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

"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:OW**************@TK2MSFTNGP10.phx.gbl...
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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:Oc**************@TK2MSFTNGP15.phx.gbl...
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

"Sahil Malik" <co*****************@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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 news:%2****************@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" <co*****************@nospam.com> wrote in message
> news:O5**************@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" <hs*******@nospamphgt.net> wrote in message
> > news:%2***************@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
> > >
> > >
> >
> >
>
>



Nov 18 '05 #22

P: n/a
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.

--
Girish Bharadwaj
http://msmvps.com/gbvb
"Jesse Liberty" <jl******@libertyassociates.com> wrote in message
news:-q********************@speakeasy.net...
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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:us*************@TK2MSFTNGP11.phx.gbl...
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.

The worst thing you can do is stick objects in session variables, because unless superman wrote your objects, you'd have memory leaks......So I
stick by what I said - avoid it if you can, but don't put yourself in the hospital trying to avoid it.


Nov 18 '05 #23

P: n/a
Allright we disagree, now lets get along :)

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

"Girish Bharadwaj" <gi*****@mvps.org> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...
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.

--
Girish Bharadwaj
http://msmvps.com/gbvb
"Jesse Liberty" <jl******@libertyassociates.com> wrote in message
news:-q********************@speakeasy.net...
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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:us*************@TK2MSFTNGP11.phx.gbl...
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.

The worst thing you can do is stick objects in session variables,

because unless superman wrote your objects, you'd have memory leaks......So I
stick by what I said - avoid it if you can, but don't put yourself in the hospital trying to avoid it.



Nov 18 '05 #24

P: n/a
> 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
"Girish Bharadwaj" <gi*****@mvps.org> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...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.

--
Girish Bharadwaj
http://msmvps.com/gbvb
"Jesse Liberty" <jl******@libertyassociates.com> wrote in message
news:-q********************@speakeasy.net...
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
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:us*************@TK2MSFTNGP11.phx.gbl...
> 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.

> The worst thing you can do is stick objects in session variables, because > unless superman wrote your objects, you'd have memory leaks......So I
> stick by what I said - avoid it if you can, but don't put yourself in the > hospital trying to avoid it.
>



Nov 18 '05 #25

P: n/a
:) 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
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:O0**************@TK2MSFTNGP15.phx.gbl...
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
"Girish Bharadwaj" <gi*****@mvps.org> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...
I agree with Jesse. I think saying "Session variables is bad" is naive. It

Nov 18 '05 #26

P: n/a
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).
"Janaka" wrote:
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" <hs*******@nospamphgt.net> wrote in message
news:%2***************@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


Nov 18 '05 #27

P: n/a
> :) 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

"Girish bharadwaj" <gi*****@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
:) 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
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:O0**************@TK2MSFTNGP15.phx.gbl...
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
"Girish Bharadwaj" <gi*****@mvps.org> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...
I agree with Jesse. I think saying "Session variables is bad" is naive.

It

Nov 18 '05 #28

P: n/a
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

"Girish bharadwaj" <gi*****@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
:) 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
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:O0**************@TK2MSFTNGP15.phx.gbl...
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
"Girish Bharadwaj" <gi*****@mvps.org> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...
I agree with Jesse. I think saying "Session variables is bad" is naive.

It

Nov 18 '05 #29

P: n/a
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

"Allan" <Al***@discussions.microsoft.com> wrote in message
news:6C**********************************@microsof t.com...
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).
"Janaka" wrote:
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" <hs*******@nospamphgt.net> wrote in message
news:%2***************@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


Nov 18 '05 #30

P: n/a
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.

"Harry Simpson" wrote:
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

"Sahil Malik" <co*****************@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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" <hs*******@nospamphgt.net> wrote in message
news:eb**************@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" <gi*****@mvps.org> wrote in message
news:%2****************@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" <hs*******@nospamphgt.net> wrote in message
> news:%2***************@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
>>
>>
>
>



Nov 18 '05 #31

P: n/a
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.

"Harry Simpson" wrote:
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

Nov 18 '05 #32

This discussion thread is closed

Replies have been disabled for this discussion.