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
31  6958 
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
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
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
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
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
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
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
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
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
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
>
>
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
>>
>>
>
>
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
> > >
> > >
> >
> >
>
>
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
> > >
> > >
> >
> >
>
>
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
>>
>>
>
>
> 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
> > >
> > >
> >
> >
>
>
"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/
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
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>
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
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>
--
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
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>
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.
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
> > >
> > >
> >
> >
>
>
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.
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.
> 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.
>
:) 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
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
> :) 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
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
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
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
>>
>>
>
>
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
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Lina Manjarres |
last post by:
Hello,
I have a session variable in a login page. Then I go to a form page where I
uses the ProfileID and the UserID. Then I go to a result page where I would
like to use the UserID as a filter,...
|
by: Phillip N Rounds |
last post by:
I'm writing a user control which has two states: Active & InActive. I
additionally am required that there to be only one active control per page,
and all logic has to be contained within the...
|
by: Erik |
last post by:
I have an application that uses sessions variables a lot but one I publish
the application on the prod server these variables are lost. The application
is written i c# 2.0 and I've set the...
|
by: Michaelk |
last post by:
Can somebody tell me how many Session variables would be considered
exessive, and when they start really affect the server speed.
For example on 20-30 asp pages I need to use about 200-300 session...
|
by: ChrisAtWokingham |
last post by:
I have been struggling with unexpected error messages on an ASP.NET system, using SQL and C#. The application draws organisation charts, based on data stored in the SQL database. Some of the chart...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
