I've come from the old ASP camp where session variables were not used. When
i started using ASP.NET in 2001, I started using them again because it was
ok from what I'd read.
I've been merrily using Session variables for three years now and i'm
entering a project with my new boss who has never quite come around that
session variables are ok.
What's the concensus here. How can i convince him that they are ok in
ASP.NET. OR
Are there those out there that still think they aren't good to use?
TIA
Harry Simpson
MCSD
Nov 18 '05
31  7002 
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.co m> wrote in message
news:%2******** ********@TK2MSF TNGP10.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
ISerializableAt tribute() 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 ISerializableAt tribute, but there is a
SerializableAtt ribute and an ISerializable interface.
SerializableAtt ribute 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.ISeri alizable 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******** ********@TK2MSF TNGP14.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 ISerializableAt tribute() 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.co m> wrote in message
news:O5******** ******@TK2MSFTN GP09.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*******@nosp amphgt.net> wrote in message
news:%2******** *******@tk2msft ngp13.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.co m> wrote in message
news:%2******** ********@TK2MSF TNGP14.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*******@nosp amphgt.net> wrote in message
news:eb******** ******@TK2MSFTN GP10.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.o rg> wrote in message
news:%2******** ********@TK2MSF TNGP15.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*******@nosp amphgt.net> wrote in message
> news:%2******** *******@tk2msft ngp13.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.co m> wrote in message
news:Oc******** ******@TK2MSFTN GP15.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.co m> wrote in message
news:%2******** ********@TK2MSF TNGP10.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
ISerializableAt tribute() 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 ISerializableAt tribute, but there is a
SerializableAtt ribute and an ISerializable interface.
SerializableAtt ribute 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.ISeri alizable 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******** ********@TK2MSF TNGP14.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 ISerializableAt tribute() 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.co m> wrote in message
> news:O5******** ******@TK2MSFTN GP09.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*******@nosp amphgt.net> wrote in message
> > news:%2******** *******@tk2msft ngp13.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.co m> wrote in message
news:Oc******** ******@TK2MSFTN GP15.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.co m> wrote in message
news:%2******** ********@TK2MSF TNGP10.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
ISerializableAt tribute() 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 ISerializableAt tribute, but there is a
SerializableAtt ribute and an ISerializable interface.
SerializableAtt ribute 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.ISeri alizable 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******** ********@TK2MSF TNGP14.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 ISerializableAt tribute() 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.co m> wrote in message
> news:O5******** ******@TK2MSFTN GP09.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*******@nosp amphgt.net> wrote in message
> > news:%2******** *******@tk2msft ngp13.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>Sah il Malik</personname> versus :1-<<binarycompres sedname>>.
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*******@nosp amphgt.net> wrote in message
news:uP******** ******@TK2MSFTN GP09.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.co m> wrote in message
news:%2******** ********@TK2MSF TNGP14.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*******@nosp amphgt.net> wrote in message
news:eb******** ******@TK2MSFTN GP10.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.o rg> wrote in message
news:%2******** ********@TK2MSF TNGP15.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*******@nosp amphgt.net> wrote in message
> news:%2******** *******@tk2msft ngp13.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******** ******@TK2MSFTN GP10.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.co m> wrote in message
news:Oc******** ******@TK2MSFTN GP15.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.co m> wrote in message
news:%2******** ********@TK2MSF TNGP10.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
ISerializableAt tribute() 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 ISerializableAt tribute, but there is a
SerializableAtt ribute and an ISerializable interface.
SerializableAtt ribute 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.ISeri alizable 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******** ********@TK2MSF TNGP14.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 ISerializableAt tribute() 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.co m> wrote in message
> news:O5******** ******@TK2MSFTN GP09.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*******@nosp amphgt.net> wrote in message
> > news:%2******** *******@tk2msft ngp13.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*******@nosp amphgt.net> wrote in
news:eU******** ******@TK2MSFTN GP14.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********@rog ers.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.co m> wrote in message
news:Ok******** ******@TK2MSFTN GP09.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******** ******@TK2MSFTN GP10.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.co m> wrote in message
news:Oc******** ******@TK2MSFTN GP15.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.co m> wrote in message
> news:%2******** ********@TK2MSF TNGP10.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
>> ISerializableAt tribute() 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 ISerializableAt tribute, but there is a
>> SerializableAtt ribute and an ISerializable interface.
> SerializableAtt ribute
>> 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.ISeri alizable 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******** ********@TK2MSF TNGP14.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 ISerializableAt tribute() 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.co m> wrote in message
>> > news:O5******** ******@TK2MSFTN GP09.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*******@nosp amphgt.net> wrote in message
>> > > news:%2******** *******@tk2msft ngp13.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******** ******@TK2MSFTN GP09.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.co m> wrote in message
news:Ok******** ******@TK2MSFTN GP09.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******** ******@TK2MSFTN GP10.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.co m> wrote in message
news:Oc******** ******@TK2MSFTN GP15.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.co m> wrote in message
> news:%2******** ********@TK2MSF TNGP10.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
>> ISerializableAt tribute() 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 ISerializableAt tribute, but there is a
>> SerializableAtt ribute and an ISerializable interface.
> SerializableAtt ribute
>> 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.ISeri alizable 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******** ********@TK2MSF TNGP14.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 ISerializableAt tribute() 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.co m> wrote in message
>> > news:O5******** ******@TK2MSFTN GP09.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*******@nosp amphgt.net> wrote in message
>> > > news:%2******** *******@tk2msft ngp13.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******** ******@TK2MSFTN GP09.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.co m> wrote in message
news:Ok******** ******@TK2MSFTN GP09.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******** ******@TK2MSFTN GP10.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.co m> wrote in message
news:Oc******** ******@TK2MSFTN GP15.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.co m> wrote in message
> news:%2******** ********@TK2MSF TNGP10.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
>> ISerializableAt tribute() 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 ISerializableAt tribute, but there is a
>> SerializableAtt ribute and an ISerializable interface.
> SerializableAtt ribute
>> 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.ISeri alizable 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******** ********@TK2MSF TNGP14.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 ISerializableAt tribute() 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.co m> wrote in message
>> > news:O5******** ******@TK2MSFTN GP09.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*******@nosp amphgt.net> wrote in message
>> > > news:%2******** *******@tk2msft ngp13.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
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>
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, but I can't get the value is stored in it.
How can I do that?
Thanks a lot!
|
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 control.
In its inactive state, only a single button appears. If the user clicks on
this button, the control becomes active( the rest of the control's
functionality becomes visible), and all other instances of this user control
on the page should...
|
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 statServer timeout to 20 min in the the
web.config file. Any ideas why the variables are lost?
|
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 variables
and 5 arrays by 1000 elements 50 characters long each.
Let say having 300 users using those pages at the same time.
Server is not the fastest one, just CPU 2.40GHz.
So question is as a user am I going to feel a difference in speed...
|
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 editing processes place a very heavy load on the server as the effects of the edit ripple through the organisation structure, requiring potentially large numbers of rows in one of the tables to be updated. (I have done it this way to make the more...
| | |
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
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 effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
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, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
| | |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
