 |
|
|
 |
|
 |
Hey,
I've looked at your "mspiercing" Body jewelry website. Couldn't find there gay jewels, I've looked online and found Rainbow Jewelry at "Love And Pride".
I like your pink "eyebrow rings" but they ain't gay enough
|
|
|
|
 |
|
 |
how can I do the same with classic asp?
thanks.
|
|
|
|
 |
|
 |
These comments crack me up. Most of us would be happy to have 200 concurrent users on our website. Let's say that each one used up 100KB of session memory (a generous amount). That's still only 20MB of memory! Visual Studio regularly exceeds 200MB on my machine.
Also, remember that many session variables are references to existing objects in Application or Cache scope, so those are simple pointers, taking up just a few bytes.
There is a reason that MS used to discourage the use of Session in classic ASP, and why now they encourage it. It works! For most websites, we should be more concerned about performance than we are about scalability, simply because most websites that we create won't need to scale all that much. And if they do, that's a great problem to have! We can solve it when we need to.
I'm so concerned about performance that I've even started storing ViewState in Session. Just put the following into the page that has a heavy ViewState load:
///
/// Override to persist view state in Session.
///
protected override PageStatePersister PageStatePersister
{
get { return new SessionPageStatePersister(this); }
}
This little piece of code has really made my AJAX pages pop. Now why would MS give us this choice if they didn't think Session was a great thing?
I like this solution. It lets me keep my "configurator window" open and the user can browse the rest of the website and add products. When the configurator window is closed, voila! the session goes away after a period of time.
--Bruce
|
|
|
|
 |
|
 |
Hi,
I was following the trend and using a random number in the JavaScript callback, then I thought that why not using a DATE rather than a random number? There is no probability that the DATE maybe repeated (unless some one invents the time machine and then you can update the article if we are still alive or if any one know what is .NET).
Regards,
Adam Tibi
Make it simple, as simple as possible, but not simpler.
|
|
|
|
 |
|
 |
i think a permanent session may cause some security issues. the better way is to set a larger number of timeout for session for preventing user from frequently login.
|
|
|
|
 |
|
 |
Dear Effun,
I might agree with you if the logged user had his credentials submitted, while in other cases, you need to keep the sessions for anonymous users and in this case there is no security issue.
Regards,
Adam Tibi
Make it simple, as simple as possible, but not simpler.
|
|
|
|
 |
|
 |
Hi Adam,
Yes, you are right.
But I think, a good asp.net developer should not make their program depend on session states. Sometimes we need to store data in session, but we must prepare for losing session, and write code for representing data in session, just like in Cache.
What I do in my code, is just store some most recently accessed objects in session for improving performance. So I need not worry about when the session will be lost.
|
|
|
|
 |
|
 |
Before keeping a user's session from being maintained "forever", you might add a few checks to make sure they're still on the page. In other words, watch mouse and key events before deciding to keep the session alive. It generally is a good idea to let "user-abandonded" sessions expire so that the server can reclaim the resources more quickly, but, of course, you don't want to allow a users session to expire if they're doing something client-side (like typing).
Obviously, it just depends on your needs.
|
|
|
|
 |
|
 |
Obviously you have not read an article or completely misunderstood it.
Suggested way allows to keep session alive only for those users who have your site open in their browsers.
As soon as user navigated away session will expire as it normally would.
Simply because browser is keeping session alive by pinging server every 10 minutes or so. And no need to check mouse or key events.
|
|
|
|
 |
|
 |
...or you didn't understand my comment.
My suggestion was that you could time-out sessions that had left their browser window open and were not doing anything. This is what I meant when I said "user-abandoned". If someone leaves their browser window open on your website, it would be better for performance if: a.) you aren't pinging users that aren't doing anything, and, b.) you aren't keeping sessions alive for users that aren't doing anything.
My suggestion was not that you could run javascript on a closed window or that your article did not do what you said it did.
Believe me when I say that I read and understand your article. I even read the bit where you say that most users don't just leave their browser windows open. I've implemented similar approaches (both with HTTP handlers and much earlier using refresh).
|
|
|
|
 |
|
 |
Well, I thought the whole point is to keep session alive for those people who kept their browsers open on your website. they simply went to coffee shop and met pretty girl he spent a night with....
I do not want him to loose his shopping cart just because of that.
Amount of such users are miniscule. Most of them do turn off their PCs when they done. So there is no stress for the server.
|
|
|
|
 |
|
 |
What if you used AJAX or maybe an IFRAME (anoying clicks) to send a much smaller request to a separate aspx file that will not return more than a small valid xml like <ANSWER/>? //On the client, call this funtion from your BODY.onLoad event function notify() { //Call the page using your AJAX implementation YourAjaxImplementation("keep_alive.aspx"); //Use the session's time value minus 1 minute to recall window.setTimeout(notify,<%=m_iSessionTimeOut%> - 60000); } On the server, make sure to declare the m_iSessionTimeOut variable and set it to Session.TimeOut or anything you like. /Xavier
|
|
|
|
 |
|
 |
Why not use the ProfileProvider system?
It uses the membership provider for authentication, and expires when then the cookie expires.
Only requirement is that it is serializable.
And it is typesafe - session issent any good for storeing information.
Session(var) are offent misused, possible just because we used to do things this way.
Beauty is in the eye of the beerholder :P
|
|
|
|
 |
|
 |
ProfileProvider framework is good only to keep user's settings.
It was not designed to be a replacement for Session object.
Session is used to keep application's workflow data.
|
|
|
|
 |
|
 |
Combine it with the AnonymousModule (standard part of ASP.NET 2.0) and it is possible to store user settings for anonymous users. A GUID is created when a visitors visits the site, and this is stored inside a cookie. Together with the membership module, the data is stored inside the database. Next time the visitor requests a page, the cookie is retrieved and the data (profile data) is retrieved from the profile tables.
Yes, profile and session are different things, but it is nice to now it is possible to store anonymous userdata.
|
|
|
|
 |
|
 |
Great little solution without requiring an IFRAME, however it has a major drawback if the page uses absolute positioned controls - the gif takes up space on the page and everything is shifted downwards. It can be overcome by modifying the <img> tag in the host page -
<img src="/renewSes.aspx" style="display:none" name=renewSession id=renewSession>
slightly more overhead but the image will be hidden and still cause the 'ping'
|
|
|
|
 |
|
 |
Watch out with the "display:none" -- some browsers won't make the call to download the image, so it might not execute on the server!
|
|
|
|
 |
|
 |
Create a css class in your site's theme: .hidden {position:absolute; left:0px; top:-500px; width:1px; height:1px; overflow:hidden;} then in the code: <span class="hidden"> <img src="./renewSes.aspx" name="renewSession" id="renewSession"/> </span> This will position the image off the page so will not affect layout however will not be ignored by the browser. Cheers Jonno
|
|
|
|
 |
|
 |
Very helpful, Amazing Work !!
na na na na na na na na na
|
|
|
|
 |
|
 |
A very similar thing has been done before on this site: http://www.codeproject.com/aspnet/Session_Defibrillator.asp[^]
I think their approach is better since:
* The timeout isn't hardcoded
* They dont rely on the random number to override browser caching. What if you got the same random number twice!
I think it's a shame that so many people are saying bad things about your article - it's obvious that they dont really understand the situation (browser being closed vs user walking away for coffee). Maybe they need to re-read your article. I think this is a great idea. Unfortunately it's been a great idea longer than you realised
|
|
|
|
 |
|
 |
Yea, thanks.
Did not see that article.
|
|
|
|
 |
|
 |
Robert,
Relying on random number is an issue, but you could have fixed that with 1/2 a line of code by creating a number that keeps incrementing one by one.
That article relies on IFrame which is no longer an XHTML element, check XHTML 1.0 Strict and XHTML 1.1, so it is going out of the market soon! So this is the big issue! Also, that approach is not cross browser compatible, for instance, it doesn't work on FF, while this one does!
So, I disagree on that being a better approach.
Cheers,
Adam Tibi
Make it simple, as simple as possible, but not simpler.
|
|
|
|
 |
|
 |
Yes, the random number is not an issue, it actually works without it with that line Response.Cache.SetCacheability(HttpCacheability.NoCache);
I added that only for goofy browsers and proxy servers. All AOL users using AOL's proxy servers and META REFRESH would fail with them to work as intended.
Plus setting limit to 9 minutes you have a chance to hit the sessionrenew page 2 times in 20 minutes interval. Thus pretty much eliminating problem.
--------------------------------------------------------
Somehow I do not think that IFRAME is going away anytime soon (most likely never ). The whole Google's AdSence is built on using IFRAME. Plus I am positive that Yahoo and MSN using same approach. So you got serious money there and most likely standard would be changed to have IFRAME.
So safe bet that we will have IFRAM for long time.
---------------------------------------------------------
But I agree, it's a huge issue that IFRAME approach does not work on FireFox.
According to my statistic around 10% using FireFox and it's a lot in Ecommerce world.
|
|
|
|
 |
|
 |
An excellent point Adam. I wasnt aware that this didn't work in firefox, can you tell me exactly what goes wrong?
Ok I'm convinced that an image refreshed with javascript is better than an iframe with refresh headers (since IFrames are deprecated (although I think they will be supported for a long long time)). But I would improve this solution by replacing the 60000 milliseconds in the javascript timeout with actual session timeout taken from the web app (minus one minute).
And I'd use a generic hhtp handler (.ashx) instead of an aspx page.
You'd have to keep the incremented number in a cookie since the browser cache lasts a lot longer than the javascript variables. I would personally use the "milliseconds since the epoch" as a cache-defeating parameter.
Cheers - Rob
-- modified at 17:54 Tuesday 1st August, 2006
|
|
|
|
 |