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.
Printable View
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.
session variables are held on the client not the server
Session variables are stored on the server. Your thinking of cookies.
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
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
...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
ses2.asp:Code:<%@ Language=VBScript%>
<html>
<body>
<%
Session("username") = "Mark Sreeves"
%>
<a href="ses2.asp">ses2</a>
</BODY>
</HTML>
[code]
<%@ Language=VBScript %>
<html>
<body>
<%
response.write(Session("username"))
%>
</BODY>
</HTML>
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.
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.
To all that replay :
Its help me to understand
Thank you all :)
efrat (ea)
I surrender!!!
Maybe I misread it somewhere...
from 4guysfromrolla.com
here's the page:Quote:
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!
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
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.
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%> ">)
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:)
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!
Thank Tom .and thanks to all of you
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.