|
-
Feb 26th, 2001, 09:51 AM
#1
Session variables are to store site wide global data for a particular user. They really dont use that much resources. Just do not use a huge amount of the if you dont need to, and never store a component reference into a Session variable.
-
Feb 26th, 2001, 11:14 AM
#2
Frenzied Member
session variables are held on the client not the server
-
Feb 26th, 2001, 11:27 AM
#3
Addicted Member
Session variables are stored on the server. Your thinking of cookies.
-
Feb 26th, 2001, 11:30 AM
#4
Frenzied Member
No I am NOT thinking of cookies!
They might not be written to the hard-drive like cookies but they ARE stored on the client
-
Feb 26th, 2001, 11:39 AM
#5
Addicted Member
This session information is stored in memory on the server.
This is from MSDN on sessions. Only the session id is stored on the client all information is stored on the server. Go check it out its under asp and web session management. This is the whole point in using session variables
-
Feb 26th, 2001, 11:41 AM
#6
Frenzied Member
...but if the user has cookies disabled you're f****ed!
disable all cookies on your browser and try this
load ses1.asp and click the link to ses2.asp
then enable cookies and try again.....
ses.asp
Code:
<%@ Language=VBScript%>
<html>
<body>
<%
Session("username") = "Mark Sreeves"
%>
<a href="ses2.asp">ses2</a>
</BODY>
</HTML>
ses2.asp:
[code]
<%@ Language=VBScript %>
<html>
<body>
<%
response.write(Session("username"))
%>
</BODY>
</HTML>
-
Feb 26th, 2001, 11:48 AM
#7
MArk , I dont know where you are gettnig your info from, but you are very worng. Session variables are stored on the server, not the client.
-
Feb 26th, 2001, 11:58 AM
#8
Addicted Member
guess it depends on what version browser you use cause mine i turned of cookies and it worked fine. I had to turn off session for it not to work. I use ie 5.5 . Besides what the hell does that have to do with where the information is stored. The point was that the information is stored on the server and there for consumes some, almost insugnifigant resources.
-
Feb 27th, 2001, 01:49 AM
#9
Addicted Member
Thank You all
To all that replay :
Its help me to understand
Thank you all 
efrat (ea)
-
Feb 27th, 2001, 03:22 AM
#10
Frenzied Member
I surrender!!!
Maybe I misread it somewhere...
from 4guysfromrolla.com
Session variables and cookies are synonymous. So if a user has set his browser not to accept any cookies, your Session variables won't work for that particular web surfer!
here's the page:
http://www.4guysfromrolla.com/webtech/092098-2.shtml
also read this:
http://www.4guysfromrolla.com/webtec...ced/faq4.shtml
jdavison's explanatiuon agrees with this.
I tried the the bit of code I posted on IE5.0
-
Feb 27th, 2001, 10:19 AM
#11
Addicted Member
Yes if you turn cookies of the session wont work. That is because the session ID is stored in a cookie. The actual information stored in the session is stored in memory on the server. That is where cookies and sessions are different. Wasnt attempting to start any feuds just wanted to make sure efrat understood the difference.
-
Feb 27th, 2001, 11:53 AM
#12
Back to the original question,
There is another way to not have to use session variables, but it takes a little more care in how you link to each script on your site.
You can pass variables through the links.
If the user has entered information such as their favorite football (not american, the reall thing) team, and you want to pass this to a page to display that info, you can send it like this:
<A Href="DisplayClubInfo.asp?TeamName=ManU">
DisplayClubInfo should have a variable declared called TeamName. Now if you want to pass this variable to another page, the ref will be different since it is now a variable:
<A Href="DisplayClubSchedule.asp?TeamToDisplay="<%=TeamName%> ">
Like I said, this is a little more intensive in the programming. I myself prefer session variables. The only time you really need to worry about session variable is if the user has an older browser and has cookies disabled, or if you are website is on a cluster, and your links are the full URL, and not just local paths.
If the links are the full URL, and you are on a webfarm, the user could be redirected to another server and the session would be different, resulting in a loss of the session variables. But if your redirections are local paths (like the example above, rather than <A Href="HTTP:\\http://www.footballfans.com\DisplayC...TeamToDisplay="<%=TeamName%> ">)
-
Feb 27th, 2001, 11:59 AM
#13
Addicted Member
Yeah you could but thats a pain and sometime there is information you dont want passes around on the page that way. There are other more interesting ways of doing it too. Sinply pass an index around and keep the rest of the info stored in the db, all referenced by that index. now you just have a meaningless number passes with no way to access it except through that asp code. there is alot more too it but its effective, bit slower but effective plus its more secure than passing everything around the pages. But lets not confuse him too much now
-
Feb 28th, 2001, 10:37 AM
#14
Guru
My take on this:
Mark: Cookies must be enabled because that is where the client saves the GUID. When the client navigates around your site, the GUID is sent to the server, which the server uses to look up its locally stored information about that GUID. (the session data). As of IIS 5, you no longer need cookies enabled in order to use session variables, as MS has figured out a way to stick the GUID into the HTML headers or similar......
Jdavidson:
Session variables DO consume a decent chunk of memory: from what I recall, 16K for each user plus 4K of memory for each item you store in the session plus the size of the item you are storing (I could be wrong, but its something like that). This can add up really quickly.
Anything I've ever read about creating scalable ASP sites says to not use session variables. They are ok for smaller sites but will hurt your scalability big time on large sites. Plus session vars don't work across server farms (until .NET anyways).
I haven't used session variables in quite a while because I design everything to be as fast and efficient as possible. Cookies and querystrings are the way to go, at least in my opinion.
Hope this helps!
-
Feb 28th, 2001, 10:46 AM
#15
Addicted Member
Thank Tom .and thanks to all of you
-
Feb 28th, 2001, 10:51 AM
#16
Addicted Member
In todays world thats a pretty small amout Sounds about right though. Dont use them very oftem myself and almost never use cookies since it seems like every client i know insists on no cookies. That why i usually use that db idea above. It makes it easier then completely passing the info through all the pages and sql server handles it pretty decently so the pages are still usually pretty quick. I may be wrong since i never timed it but cookies always seemed slower than sessions to me.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|