|
 |
asp_discuss thread: Session variables
Message #1 by "Ian Richardson" <ian@i...> on Sat, 7 Apr 2001 11:28:11 +0100
|
|
Hi All,
I have recentley been following a small discussion on the pro's and con's of
Session variables and the use of said variables.
The down-side of using these objects is the drain on server resources, the
up-side is the ease of maintaining state.
My own opinion is that if you are using ASP technology then you should use
Session variables as they are a part of that
technology, the argument that they impact on server performance should
surely be overcome by specifying a system
that can cope with the expected load to be imposed upon it.
Having said that, can anyone tell me how I would specify such a system?
Particularly; how big is a single Session variable, let's say it contains
only a small string, my name, "ianmetaxa"?
If I set a Session variable to Session("ianmetaxa") how much resource would
that Session variable take, and is it the same every time, i.e. if there are
20 different Sessions open each with the variable set to 'ianmetaxa' is it
20 * whatever the value is?
My apologies if this seems a dumb question/s but I intend to use Session
varaiables but I don't want website performance
to suffer so I will put in a high spec server if required.
Cheers all
ianmetaxa
Ian
Message #2 by Imar Spaanjaars <Imar@S...> on Sat, 07 Apr 2001 18:50:59 +0200
|
|
Ian,
I think the main issue with sessions is their lack of scalability. If you
have one single server with a limited number of users, they are generally
not a problem, and will give more advantages than disadvantages. As far as
I know, a session variable will only consume as much memory as it holds:
that is, a 1k string will take up 1k. There might be some overhead for the
session mechanism, but I am not sure how much that will be (guess not too
much though).
However, with using sessions, you are tied to one machine: sessions are
stored in the memory of one, local, computer. So in a webfarm, where, based
on RRDNS, or more advanced load-balancing mechanisms, the server load is
spread out over multiple machines, you can't use sessions. This is because
you can't tell for sure which server will handle the request. (And if you
could, load-balancing wouldn't make much sense anymore, would it? ;-)).
Also, another problem is of course the session-time out. Suppose 1000 users
log in, each occupying 10k of session memory. This will be 10MB of memory
for the duration of the session. Even if the users are gone, the session is
still maintained, and thus occupying memory. This will seriously limit the
number of users you can serve in a certain amount of time. On a stateless
server, if you have a 1000 users in one minute, you can serve another 1000
the next minute. On a session-based system, this is jot true: the 1000
users from the first minute will occupy precious server memory during the
session-timeout period.
So, IMO, in a large, high-traffic website, sessions should be avoided. I
usually design the use of session variables in small intranet-based
applications or in admin-sections of websites, and work around them in
other situations. If you have once build another mechanism for storing
state (like in a database) it'll get much easier to avoid using sessions
altogether the next time. If you have a ready-built solution, implementing
that is about as easy as using sessions, without all the shortcomings of them.
You may want to check out the following URL (there are tons of other
articles available at the MSDN about session state though). It'll give you
some more insight in sessions.
http://msdn.microsoft.com/library/periodic/period99/webapp.htm
Imar
At 11:28 AM 4/7/2001 +0100, you wrote:
>Hi All,
>I have recentley been following a small discussion on the pro's and con's of
>Session variables and the use of said variables.
>
>The down-side of using these objects is the drain on server resources, the
>up-side is the ease of maintaining state.
>My own opinion is that if you are using ASP technology then you should use
>Session variables as they are a part of that
>technology, the argument that they impact on server performance should
>surely be overcome by specifying a system
>that can cope with the expected load to be imposed upon it.
>
>Having said that, can anyone tell me how I would specify such a system?
>Particularly; how big is a single Session variable, let's say it contains
>only a small string, my name, "ianmetaxa"?
>
>If I set a Session variable to Session("ianmetaxa") how much resource would
>that Session variable take, and is it the same every time, i.e. if there are
>20 different Sessions open each with the variable set to 'ianmetaxa' is it
>20 * whatever the value is?
>
>My apologies if this seems a dumb question/s but I intend to use Session
>varaiables but I don't want website performance
>to suffer so I will put in a high spec server if required.
>Cheers all
>ianmetaxa
>Ian
Message #3 by Hal Levy <hal.levy@s...> on Mon, 9 Apr 2001 09:00:35 -0400
|
|
Ian,
I would like to point out that at Wrox WebDev '99 (in Washington DC) almost
every session I attended started with "DO NOT USE THE SESSION OBJECT." That
includes those given by MS Evangelists and Technology Leads. It is clear
that MS no longer reccomends the use of sessions. That is until .NET which
might remove a number of the problems with sessions.
I should also say that, while lower key, it was also a recurring discussion
at WebDev 2K.
Just because it is part of the technology, dosen't mean we should use it.
1. Server resources are strained with the session object.
2. Many objects (Dictionary, ADO, etc.) that people are tempted to use at
the session level are not threadsafe and you will have data corruption.
3. Sessions sit around, by default, for 20 minutes- eating up those
resources for extended periods of time.
I want to also say you should be careful about what you put on the
APPLICATION level- Everyone shares the same object and people get serialized
into it- killing performance on things like Data Connections.
If the Session object was so good- why did MS completely change it for .NET?
With that said, if you only are using it to store basic values- and your
only going to have on machine - then the impact will be negilgable. Just
don't get tempted to start instatiating objects on the session level!
Hal
-----Original Message-----
From: Ian Richardson [mailto:ian@i...]
Sent: Saturday, April 07, 2001 6:28 AM
To: asp_discuss
Subject: [asp_discuss] Session variables
The down-side of using these objects is the drain on server resources, the
up-side is the ease of maintaining state.
My own opinion is that if you are using ASP technology then you should use
Session variables as they are a part of that
technology, the argument that they impact on server performance should
surely be overcome by specifying a system
that can cope with the expected load to be imposed upon it.
Message #4 by "Ian Richardson" <ian@i...> on Mon, 9 Apr 2001 21:02:44 +0100
|
|
Thanks for your reply Hal,
The strong consensus does indeed appear to be against the use of the Session
and I am re-thinking my strategies accordingly. I am now going to have only
one session, a UID and I will write my data to a database using the
Session("UID") to maintain state. Having said that, if I am opening and
closing recordsets on each page, will this not have a similar impact upon
performance, or is this where connection pooling comes in?
Cheers
-----Original Message-----
From: Hal Levy [mailto:hal.levy@s...]
Sent: 09 April 2001 14:25
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Ian,
I would like to point out that at Wrox WebDev '99 (in Washington DC) almost
every session I attended started with "DO NOT USE THE SESSION OBJECT." That
includes those given by MS Evangelists and Technology Leads. It is clear
that MS no longer reccomends the use of sessions. That is until .NET which
might remove a number of the problems with sessions.
I should also say that, while lower key, it was also a recurring discussion
at WebDev 2K.
Just because it is part of the technology, dosen't mean we should use it.
1. Server resources are strained with the session object.
2. Many objects (Dictionary, ADO, etc.) that people are tempted to use at
the session level are not threadsafe and you will have data corruption.
3. Sessions sit around, by default, for 20 minutes- eating up those
resources for extended periods of time.
I want to also say you should be careful about what you put on the
APPLICATION level- Everyone shares the same object and people get serialized
into it- killing performance on things like Data Connections.
If the Session object was so good- why did MS completely change it for .NET?
With that said, if you only are using it to store basic values- and your
only going to have on machine - then the impact will be negilgable. Just
don't get tempted to start instatiating objects on the session level!
Hal
-----Original Message-----
From: Ian Richardson [mailto:ian@i...]
Sent: Saturday, April 07, 2001 6:28 AM
To: asp_discuss
Subject: [asp_discuss] Session variables
The down-side of using these objects is the drain on server resources, the
up-side is the ease of maintaining state.
My own opinion is that if you are using ASP technology then you should use
Session variables as they are a part of that
technology, the argument that they impact on server performance should
surely be overcome by specifying a system
that can cope with the expected load to be imposed upon it.
Message #5 by Hal Levy <hal.levy@s...> on Tue, 10 Apr 2001 09:56:26 -0400
|
|
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C0C1C6.09444B90
Content-Type: text/plain;
charset="iso-8859-1"
Ian,
That's great to hear!
One more thing I would suggest- use cookies directly- not the session. Take
your UID and put it in a cookie (request.cookie, response.cookie) - then
sessions are gone all together! If you want, create a GUID and use that in
the cookie and have that point to the UID.
As for page-level data connections - that is exactly the case. Connection
pooling comes in and the performance is not harmed anywhere near as badly as
a application level or session level connection. Let the pools do their job!
Hal
-----Original Message-----
From: Ian Richardson [mailto:ian@i...]
Sent: Monday, April 09, 2001 4:03 PM
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Thanks for your reply Hal,
The strong consensus does indeed appear to be against the use of the Session
and I am re-thinking my strategies accordingly. I am now going to have only
one session, a UID and I will write my data to a database using the
Session("UID") to maintain state. Having said that, if I am opening and
closing recordsets on each page, will this not have a similar impact upon
performance, or is this where connection pooling comes in?
Cheers
-----Original Message-----
From: Hal Levy [mailto:hal.levy@s...]
Sent: 09 April 2001 14:25
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Ian,
I would like to point out that at Wrox WebDev '99 (in Washington DC) almost
every session I attended started with "DO NOT USE THE SESSION OBJECT." That
includes those given by MS Evangelists and Technology Leads. It is clear
that MS no longer reccomends the use of sessions. That is until .NET which
might remove a number of the problems with sessions.
I should also say that, while lower key, it was also a recurring discussion
at WebDev 2K.
Just because it is part of the technology, dosen't mean we should use it.
1. Server resources are strained with the session object.
2. Many objects (Dictionary, ADO, etc.) that people are tempted to use at
the session level are not threadsafe and you will have data corruption.
3. Sessions sit around, by default, for 20 minutes- eating up those
resources for extended periods of time.
I want to also say you should be careful about what you put on the
APPLICATION level- Everyone shares the same object and people get serialized
into it- killing performance on things like Data Connections.
If the Session object was so good- why did MS completely change it for .NET?
With that said, if you only are using it to store basic values- and your
only going to have on machine - then the impact will be negilgable. Just
don't get tempted to start instatiating objects on the session level!
Hal
-----Original Message-----
From: Ian Richardson [mailto:ian@i...]
Sent: Saturday, April 07, 2001 6:28 AM
To: asp_discuss
Subject: [asp_discuss] Session variables
The down-side of using these objects is the drain on server resources, the
up-side is the ease of maintaining state.
My own opinion is that if you are using ASP technology then you should use
Session variables as they are a part of that
technology, the argument that they impact on server performance should
surely be overcome by specifying a system
that can cope with the expected load to be imposed upon it.
Message #6 by Stephen Martin <SMartin@n...> on Tue, 10 Apr 2001 12:31:39 -0400
|
|
I'd concur with Hal's recommendation. Why bother with even one session
variable if you're going to use it simply as a key to the database? Use a
regular ol' cookie with a UID. This gives you a few benefits. First,
you're not ties to ASP Sessions at all. Second, you could, if you so
desired, persist the cookie longer than a single user session (by setting an
expiration data some time in the future for the cookie. If you did this,
the server would "remember" users and restore them to their past state when
they return. Third, you've now opened the door to scalability. If you ever
move to a Web farm arrangement, the UID would not be tied to a single
session on a single server in the farm.
-Stephen
-----Original Message-----
From: Hal Levy [mailto:hal.levy@s...]
Sent: Tuesday, April 10, 2001 9:56 AM
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Ian,
That's great to hear!
One more thing I would suggest- use cookies directly- not the session. Take
your UID and put it in a cookie (request.cookie, response.cookie) - then
sessions are gone all together! If you want, create a GUID and use that in
the cookie and have that point to the UID.
As for page-level data connections - that is exactly the case. Connection
pooling comes in and the performance is not harmed anywhere near as badly as
a application level or session level connection. Let the pools do their job!
Hal
-----Original Message-----
From: Ian Richardson [ mailto:ian@i...
<mailto:ian@i...> ]
Sent: Monday, April 09, 2001 4:03 PM
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Thanks for your reply Hal,
The strong consensus does indeed appear to be against the use of the Session
and I am re-thinking my strategies accordingly. I am now going to have only
one session, a UID and I will write my data to a database using the
Session("UID") to maintain state. Having said that, if I am opening and
closing recordsets on each page, will this not have a similar impact upon
performance, or is this where connection pooling comes in?
Cheers
-----Original Message-----
From: Hal Levy [ mailto:hal.levy@s...
<mailto:hal.levy@s...> ]
Sent: 09 April 2001 14:25
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Ian,
I would like to point out that at Wrox WebDev '99 (in Washington DC) almost
every session I attended started with "DO NOT USE THE SESSION OBJECT." That
includes those given by MS Evangelists and Technology Leads. It is clear
that MS no longer reccomends the use of sessions. That is until .NET which
might remove a number of the problems with sessions.
I should also say that, while lower key, it was also a recurring discussion
at WebDev 2K.
Just because it is part of the technology, dosen't mean we should use it.
1. Server resources are strained with the session object.
2. Many objects (Dictionary, ADO, etc.) that people are tempted to use at
the session level are not threadsafe and you will have data corruption.
3. Sessions sit around, by default, for 20 minutes- eating up those
resources for extended periods of time.
I want to also say you should be careful about what you put on the
APPLICATION level- Everyone shares the same object and people get serialized
into it- killing performance on things like Data Connections.
If the Session object was so good- why did MS completely change it for .NET?
With that said, if you only are using it to store basic values- and your
only going to have on machine - then the impact will be negilgable. Just
don't get tempted to start instatiating objects on the session level!
Hal
-----Original Message-----
From: Ian Richardson [ mailto:ian@i...
<mailto:ian@i...> ]
Sent: Saturday, April 07, 2001 6:28 AM
To: asp_discuss
Subject: [asp_discuss] Session variables
The down-side of using these objects is the drain on server resources, the
up-side is the ease of maintaining state.
My own opinion is that if you are using ASP technology then you should use
Session variables as they are a part of that
technology, the argument that they impact on server performance should
surely be overcome by specifying a system
that can cope with the expected load to be imposed upon it.
Message #7 by Imar Spaanjaars <Imar@S...> on Tue, 10 Apr 2001 19:03:32 +0200
|
|
Well, I agree with the opinions below. One more thing though, if you are
not using a GUID, but a regular ID from the database, encrypt it a little.
Depending on what kind of user state you are storing, you may not want
somebody to steal someone else's session. A cookie called UserID with a
value 168 would be too easy to hijack. Simply substitute the number and you
might be able to steal someone else's data (especially the case when you
implement persistent cookies as Stephen suggested.
Robert has a few links to encryption (jncluding source) from one of his
articles at http://www.aspalliance.com/nothingmn/view.asp?aid=10
Imar
At 12:31 PM 4/10/2001 -0400, you wrote:
>I'd concur with Hal's recommendation. Why bother with even one session
>variable if you're going to use it simply as a key to the database? Use a
>regular ol' cookie with a UID. This gives you a few benefits. First,
>you're not ties to ASP Sessions at all. Second, you could, if you so
>desired, persist the cookie longer than a single user session (by setting an
>expiration data some time in the future for the cookie. If you did this,
>the server would "remember" users and restore them to their past state when
>they return. Third, you've now opened the door to scalability. If you ever
>move to a Web farm arrangement, the UID would not be tied to a single
>session on a single server in the farm.
>
>-Stephen
>
>-----Original Message-----
>From: Hal Levy [mailto:hal.levy@s...]
>Sent: Tuesday, April 10, 2001 9:56 AM
>To: asp_discuss
>Subject: [asp_discuss] RE: Session variables
>
>
>
>Ian,
>
>That's great to hear!
>
>One more thing I would suggest- use cookies directly- not the session. Take
>your UID and put it in a cookie (request.cookie, response.cookie) - then
>sessions are gone all together! If you want, create a GUID and use that in
>the cookie and have that point to the UID.
>
>As for page-level data connections - that is exactly the case. Connection
>pooling comes in and the performance is not harmed anywhere near as badly as
>a application level or session level connection. Let the pools do their job!
>
>Hal
>
>
>-----Original Message-----
>From: Ian Richardson [ mailto:ian@i...
><mailto:ian@i...> ]
>Sent: Monday, April 09, 2001 4:03 PM
>To: asp_discuss
>Subject: [asp_discuss] RE: Session variables
>
>
>Thanks for your reply Hal,
>
>The strong consensus does indeed appear to be against the use of the Session
>
>and I am re-thinking my strategies accordingly. I am now going to have only
>one session, a UID and I will write my data to a database using the
>Session("UID") to maintain state. Having said that, if I am opening and
>closing recordsets on each page, will this not have a similar impact upon
>performance, or is this where connection pooling comes in?
>
>Cheers
>
>-----Original Message-----
>From: Hal Levy [ mailto:hal.levy@s...
><mailto:hal.levy@s...> ]
>Sent: 09 April 2001 14:25
>To: asp_discuss
>Subject: [asp_discuss] RE: Session variables
>
>
>Ian,
>
>I would like to point out that at Wrox WebDev '99 (in Washington DC) almost
>every session I attended started with "DO NOT USE THE SESSION OBJECT." That
>includes those given by MS Evangelists and Technology Leads. It is clear
>that MS no longer reccomends the use of sessions. That is until .NET which
>might remove a number of the problems with sessions.
>
>I should also say that, while lower key, it was also a recurring discussion
>at WebDev 2K.
>
>Just because it is part of the technology, dosen't mean we should use it.
>
>1. Server resources are strained with the session object.
>2. Many objects (Dictionary, ADO, etc.) that people are tempted to use at
>the session level are not threadsafe and you will have data corruption.
>3. Sessions sit around, by default, for 20 minutes- eating up those
>resources for extended periods of time.
>
>I want to also say you should be careful about what you put on the
>APPLICATION level- Everyone shares the same object and people get serialized
>
>into it- killing performance on things like Data Connections.
>
>If the Session object was so good- why did MS completely change it for .NET?
>
>
>With that said, if you only are using it to store basic values- and your
>only going to have on machine - then the impact will be negilgable. Just
>don't get tempted to start instatiating objects on the session level!
>
>Hal
Message #8 by "Ian Richardson" <ian@i...> on Tue, 10 Apr 2001 20:18:46 +0100
|
|
RE: [asp_discuss] RE: Session variablesHal
Thank you for the pointers Hal really very useful, I have
taken your advice and stored the UID as a cookie. I have had
problems coming up with a suitable solution for producing a
GUID tho'. I have just used SessionID + Now() to give me a
'unique' number but if you could suggest a better way I
would be grateful.
Cheers
-----Original Message-----
From: Hal Levy [mailto:hal.levy@s...]
Sent: 10 April 2001 14:56
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Ian,
That's great to hear!
One more thing I would suggest- use cookies directly- not
the session. Take your UID and put it in a cookie
(request.cookie, response.cookie) - then sessions are gone
all together! If you want, create a GUID and use that in the
cookie and have that point to the UID.
As for page-level data connections - that is exactly the
case. Connection pooling comes in and the performance is not
harmed anywhere near as badly as a application level or
session level connection. Let the pools do their job!
Hal
-----Original Message-----
From: Ian Richardson [mailto:ian@i...]
Sent: Monday, April 09, 2001 4:03 PM
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Thanks for your reply Hal,
The strong consensus does indeed appear to be against the
use of the Session
and I am re-thinking my strategies accordingly. I am now
going to have only
one session, a UID and I will write my data to a database
using the
Session("UID") to maintain state. Having said that, if I
am opening and
closing recordsets on each page, will this not have a
similar impact upon
performance, or is this where connection pooling comes in?
Cheers
-----Original Message-----
From: Hal Levy [mailto:hal.levy@s...]
Sent: 09 April 2001 14:25
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Ian,
I would like to point out that at Wrox WebDev '99 (in
Washington DC) almost
every session I attended started with "DO NOT USE THE
SESSION OBJECT." That
includes those given by MS Evangelists and Technology
Leads. It is clear
that MS no longer reccomends the use of sessions. That is
until .NET which
might remove a number of the problems with sessions.
I should also say that, while lower key, it was also a
recurring discussion
at WebDev 2K.
Just because it is part of the technology, dosen't mean we
should use it.
1. Server resources are strained with the session object.
2. Many objects (Dictionary, ADO, etc.) that people are
tempted to use at
the session level are not threadsafe and you will have
data corruption.
3. Sessions sit around, by default, for 20 minutes- eating
up those
resources for extended periods of time.
I want to also say you should be careful about what you
put on the
APPLICATION level- Everyone shares the same object and
people get serialized
into it- killing performance on things like Data
Connections.
If the Session object was so good- why did MS completely
change it for .NET?
With that said, if you only are using it to store basic
values- and your
only going to have on machine - then the impact will be
negilgable. Just
don't get tempted to start instatiating objects on the
session level!
Hal
Message #9 by "Ian Richardson" <ian@i...> on Tue, 10 Apr 2001 20:22:10 +0100
|
|
Hi Imar, Stephen,
I have moved rapidly away from sessions but as my app needs to store data
about the session without requireing people to log in or anything, I needed
a way to produce a Unique ID and I have been using the Session ID to help
generate that. Not the best solution I realise but I am a bit stuck when it
omes to GUIDs.
Cheers guys
-----Original Message-----
From: Stephen Martin [mailto:SMartin@n...]
Sent: 10 April 2001 17:32
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
I'd concur with Hal's recommendation. Why bother with even one session
variable if you're going to use it simply as a key to the database? Use a
regular ol' cookie with a UID. This gives you a few benefits. First,
you're not ties to ASP Sessions at all. Second, you could, if you so
desired, persist the cookie longer than a single user session (by setting an
expiration data some time in the future for the cookie. If you did this,
the server would "remember" users and restore them to their past state when
they return. Third, you've now opened the door to scalability. If you ever
move to a Web farm arrangement, the UID would not be tied to a single
session on a single server in the farm.
-Stephen
-----Original Message-----
From: Hal Levy [mailto:hal.levy@s...]
Sent: Tuesday, April 10, 2001 9:56 AM
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Ian,
That's great to hear!
One more thing I would suggest- use cookies directly- not the session. Take
your UID and put it in a cookie (request.cookie, response.cookie) - then
sessions are gone all together! If you want, create a GUID and use that in
the cookie and have that point to the UID.
As for page-level data connections - that is exactly the case. Connection
pooling comes in and the performance is not harmed anywhere near as badly as
a application level or session level connection. Let the pools do their job!
Hal
-----Original Message-----
From: Ian Richardson [ mailto:ian@i...
<mailto:ian@i...> ]
Sent: Monday, April 09, 2001 4:03 PM
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Thanks for your reply Hal,
The strong consensus does indeed appear to be against the use of the Session
and I am re-thinking my strategies accordingly. I am now going to have only
one session, a UID and I will write my data to a database using the
Session("UID") to maintain state. Having said that, if I am opening and
closing recordsets on each page, will this not have a similar impact upon
performance, or is this where connection pooling comes in?
Cheers
-----Original Message-----
From: Hal Levy [ mailto:hal.levy@s...
<mailto:hal.levy@s...> ]
Sent: 09 April 2001 14:25
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Ian,
I would like to point out that at Wrox WebDev '99 (in Washington DC) almost
every session I attended started with "DO NOT USE THE SESSION OBJECT." That
includes those given by MS Evangelists and Technology Leads. It is clear
that MS no longer reccomends the use of sessions. That is until .NET which
might remove a number of the problems with sessions.
I should also say that, while lower key, it was also a recurring discussion
at WebDev 2K.
Just because it is part of the technology, dosen't mean we should use it.
1. Server resources are strained with the session object.
2. Many objects (Dictionary, ADO, etc.) that people are tempted to use at
the session level are not threadsafe and you will have data corruption.
3. Sessions sit around, by default, for 20 minutes- eating up those
resources for extended periods of time.
I want to also say you should be careful about what you put on the
APPLICATION level- Everyone shares the same object and people get serialized
into it- killing performance on things like Data Connections.
If the Session object was so good- why did MS completely change it for .NET?
With that said, if you only are using it to store basic values- and your
only going to have on machine - then the impact will be negilgable. Just
don't get tempted to start instatiating objects on the session level!
Hal
-----Original Message-----
From: Ian Richardson [ mailto:ian@i...
<mailto:ian@i...> ]
Sent: Saturday, April 07, 2001 6:28 AM
To: asp_discuss
Subject: [asp_discuss] Session variables
The down-side of using these objects is the drain on server resources, the
up-side is the ease of maintaining state.
My own opinion is that if you are using ASP technology then you should use
Session variables as they are a part of that
technology, the argument that they impact on server performance should
surely be overcome by specifying a system
that can cope with the expected load to be imposed upon it.
Message #10 by Imar Spaanjaars <Imar@S...> on Tue, 10 Apr 2001 22:24:30 +0200
|
|
If you are using SQL Server, it has the "uniqueidentifier" type column. If
you assign that a default value of NewID(), a new GUID will be generated
whenever you insert a new record. Or get a new value with newID and assign
that as well on an insert.
Another option is to execute some plain ol' SQL to get a GUID:
select newid()
will give you a new GUID (duh). Execute this statement through a connection
to SQL server and you'll get the GUID.
AFAIK, there are also COM components that can do this for you. Don't know
about any good ones myself, but a search on www.aspin.com might work.
If you can't use SQL, you can use Access and use the Autonumber feature
combined with some text, or other code (random, for example). and encrypt
that a little to obscure the meaning of the ID.
Last but not least, if you can't use any database, write the ID to an
application variable or file, and autoincrement that for each new user (not
very recommended, though)
HtH
Imar
At 08:22 PM 4/10/2001 +0100, you wrote:
>Hi Imar, Stephen,
>
>I have moved rapidly away from sessions but as my app needs to store data
>about the session without requireing people to log in or anything, I needed
>a way to produce a Unique ID and I have been using the Session ID to help
>generate that. Not the best solution I realise but I am a bit stuck when it
>omes to GUIDs.
>
>Cheers guys
\
Message #11 by Hal Levy <hal.levy@s...> on Tue, 10 Apr 2001 16:53:55 -0400
|
|
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C0C200.5B9D7C10
Content-Type: text/plain;
charset="iso-8859-1"
Of course, seconds after sending you the last message- I found it on MSDN...
http://support.microsoft.com/support/kb/articles/Q176/7/90.ASP
Hal Levy
StarMedia Network, Inc.
Intranet Development Manager
xxx-xxx-xxxx (p)
xxx-xxx-xxxx (f)
7-701-8375 (StarDial)
hal.levy@s...
Message #12 by Hal Levy <hal.levy@s...> on Tue, 10 Apr 2001 16:52:20 -0400
|
|
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C0C200.22BAF440
Content-Type: text/plain;
charset="iso-8859-1"
Imar,
I know that on the MSDN CD - a year or so ago- I found a code sample that I
just copied on how to create a GUID. It might have been in the ASP
documentation or the VB documentation.
Hal Levy
StarMedia Network, Inc.
Intranet Development Manager
xxx-xxx-xxxx (p)
xxx-xxx-xxxx (f)
7-701-8375 (StarDial)
hal.levy@s...
-----Original Message-----
From: Imar Spaanjaars [mailto:Imar@S...]
Sent: Tuesday, April 10, 2001 4:25 PM
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
If you are using SQL Server, it has the "uniqueidentifier" type column. If
you assign that a default value of NewID(), a new GUID will be generated
whenever you insert a new record. Or get a new value with newID and assign
that as well on an insert.
Another option is to execute some plain ol' SQL to get a GUID:
select newid()
will give you a new GUID (duh). Execute this statement through a connection
to SQL server and you'll get the GUID.
AFAIK, there are also COM components that can do this for you. Don't know
about any good ones myself, but a search on www.aspin.com might work.
If you can't use SQL, you can use Access and use the Autonumber feature
combined with some text, or other code (random, for example). and encrypt
that a little to obscure the meaning of the ID.
Last but not least, if you can't use any database, write the ID to an
application variable or file, and autoincrement that for each new user (not
very recommended, though)
HtH
Imar
At 08:22 PM 4/10/2001 +0100, you wrote:
>Hi Imar, Stephen,
>
>I have moved rapidly away from sessions but as my app needs to store data
>about the session without requireing people to log in or anything, I needed
>a way to produce a Unique ID and I have been using the Session ID to help
>generate that. Not the best solution I realise but I am a bit stuck when it
>omes to GUIDs.
>
>Cheers guys
\
Message #13 by Imar Spaanjaars <Imar@S...> on Wed, 11 Apr 2001 20:02:52 +0200
|
|
Hal,
Thank you for the pointer. I knew it had to be somewhere, just didn't know
where.
We usually use SQL server, but having your "own" mechanism might come in
handy some day.
Imar
At 04:53 PM 4/10/2001 -0400, you wrote:
>Of course, seconds after sending you the last message- I found it on MSDN...
>
>http://support.microsoft.com/support/kb/articles/Q176/7/90.ASP
>
>
>Hal Levy
>StarMedia Network, Inc.
>Intranet Development Manager
>xxx-xxx-xxxx (p)
>xxx-xxx-xxxx (f)
>7-701-8375 (StarDial)
>hal.levy@s...
>---
Message #14 by Hal Levy <hal.levy@s...> on Thu, 12 Apr 2001 12:13:35 -0400
|
|
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C0C36B.86B2B6B0
Content-Type: text/plain;
charset="iso-8859-1"
If your making the connection anyway- then sure, use SQL to get the GUID-
but if you are not talking to SQL at the time- no open connections.. why go
through the expense of setting one up? just use a custom COM object with the
MS provided code.
Hal Levy
StarMedia Network, Inc.
Intranet Development Manager
Phone: (xxx) xxx-xxxx Cell: (xxx) xxx-xxxx
Fax: (xxx) xxx-xxxx StarDial: 7-701-8375
hal.levy@s...
-----Original Message-----
From: Imar Spaanjaars [mailto:Imar@S...]
Sent: Wednesday, April 11, 2001 2:03 PM
To: asp_discuss
Subject: [asp_discuss] RE: Session variables
Hal,
Thank you for the pointer. I knew it had to be somewhere, just didn't know
where.
We usually use SQL server, but having your "own" mechanism might come in
handy some day.
Imar
At 04:53 PM 4/10/2001 -0400, you wrote:
>Of course, seconds after sending you the last message- I found it on
MSDN...
>
>http://support.microsoft.com/support/kb/articles/Q176/7/90.ASP
>
>
>Hal Levy
>StarMedia Network, Inc.
>Intranet Development Manager
>xxx-xxx-xxxx (p)
>xxx-xxx-xxxx (f)
>7-701-8375 (StarDial)
>hal.levy@s...
>---
|
|
|
View Cart
