|
Introduction to the Defibrillator
Sometimes you want to keep a session alive only as long as the user is on the site, or until they close their browser. You don't have security requirements in this situation that would make this a bad idea. You just want to keep the session timeout down, but let it persist as long as people are on your site (not just posting back to the server). I'm not kidding you when I tell you that I have figured out a way to do this with two lines of code.
Coming from a biomedical engineering background, I simply had to call this construct The Defibrillator :-) You'll soon see why.
Nuts and Bolts
The most elegant engineering solutions are the simplest ones. You break down a problem into its finest components, and then focus on applying your vast knowledge to each component in order to produce a unified solution.
There are only four concepts to this solution:
- Knowledge of the Response.
- Knowledge of the
Refresh HTTP header attribute.
- Session property access.
- Plain old IFrame.
You will create a dummy WebForm called Defibrillator.aspx. You do nothing with this page other than add one line on the Page_Load in the code behind file: private void Page_Load(object sender, System.EventArgs e)
{
Response.AddHeader("Refresh", Convert.ToString((Session.Timeout*60)-10));
}
You just added the Refresh HTTP Header Attribute to the WebForm and gave it a value of your session timeout minus ten seconds. What does that mean? It means that ten seconds before the user's session is going to timeout, as long as they have a browser open, and they are on your page, this defibrillator page will deliver massive amounts of electrical current to your server, jolting the user's session back from the brink of death...which can also be described as automatically posting back to keep the session alive :-).
Great, you say...I don't want my site to post back visibly just to keep the session alive. You don't have to. This is where the second line of code comes in.
Go into your user control that is site persistent, such as the header, or footer user control. Now add this line of code into the front end WebForm markup language: <IFRAME id=Defib src="/Defibrillator.aspx"
frameBorder=no width=0 height=0 runat="server"></IFRAME>
Now this invisible Defibrillator WebForm will just sit in the IFrame and post itself back to the server 10 seconds before the session times out, only if they are still on your site or a browser is open. Check out a View Source, you won't even see the Refresh attribute because it's hanging out in the invisible IFrame.
Please use this clever little trick with discretion and an understanding of your blade resources, or else I will have an army of network administrators ready to storm my fort :-)
Caveats
- Browser Compatibility
It will work in any browser that interprets the Refresh HTTP header. In Netscape it has the effect of hitting 'Reload' at the specified time. I have read online that this refresh will exclude your page from search engine crawling... which is fine since you put this functional tag on a dummy page in an IFrame, that you don't want anyone browsing to anyway.
- Out of our control: precision of ASP.NET timeout on server.
I've found that the session timeout itself in ASP.NET is not entirely accurate, especially when you are in a debug process. While I haven't had the Defibrillator fail for Session.Timeout - 10 seconds, I tested for 2 days with Session.Timeout - 5 seconds and it failed at around 36.5 hours of inactivity, because the ASP.NET session timed out before it was supposed to on the server. You may want to keep this in mind and perform your own little test. You could even fire up different browsers and let them rip, logging a time of failure and the browser type from the Request in your DB. So far so good on my app, no problems with the way I presented the solution here on Netscape or IE 6. (RE: Joe).
Extension
Write a combination of code in the defibrillator that works on a JavaScript timer, prompting the user to refresh session, and replace the Refresh HTTP header attribute with this construct. Since it is site persistent, put as much JavaScript into your .js files as possible. (RE: Fredrik)
| You must Sign In to use this message board. |
|
| | Msgs 1 to 25 of 64 (Total in Forum: 64) (Refresh) | FirstPrevNext |
|
 |
|
|
 |
|
|
instead of placing the iframe in user control how about if you have the same code in a class library and have ref in your web project? make sense and possible ?
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
i am so tempted to implement this solution to keep the user session alive...they do NOT like walking away and losing their data..... but...is this advisable for a web app that will be used INTENSIVELY for a period of ~ a month and simultaneously by thousands of staff members? (september is crunch time for submissions) esentially all users wait last minute and they will be using the app during the same time window... does my concern it make sense? thanks!
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Hi Ladypins, your concerns are valid. I'm sure by now there are more clever ways to make this happen, but before you implement this, I'd consider design first. Long ago, when I did this, my users truly could not store any data in cookies, and I had a State Server running so session state was fairly fast. These choices were satisfactory for my needs of the project at that time.
Consider what data you need to persist, and how it can be done, remember, you have: Application, Session State, View State, Control State, URLs, Cookies, Hidden Fields, RDBMS, Service Layer, etc. Search for MSDN State Persistence for more guidance. A good design will take you farther than thousands of hours of tinkering, trust me. In the case that you do actually need stress testing, check out Microsoft Visual Studio for Software Testers. It will give you an integrated suite of testing tools whereby you may simulate your anticipated operational load for your organization. Good luck, good thinking, and best wishes to you on your project! Please let me know what you decide to do to satisfy your state persistence requirements if you have the time.
Achieve by taking great pride in everything you're charged with, be successful by having the initiative to charge yourself, and realize that talent is comprised of aptitude, hard work, and spirit. Hone in on your aptitudes and dedicate your spirit to reach your full potential.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
thanks T. for logging in to the CP site and replying to my post. i was starting to wonder if anyone read it... esentially my users enter a bunch of text into various texboxes and textareas.... i wish they would just click on the Save button before walking away....is that too much to ask of them?!! jeeezzz... LOL
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
i am so tempted to implement this solution to keep the user session alive...they do NOT like walking away and losing their data..... but...is this advisable for a web app that will be used INTENSIVELY for a period of ~ a month and simultaneously by thousands of staff members? (september is crunch time for submissions) esentially all users wait last minute and they will be using the app during the same time window... does my concern it make sense? thanks!
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
It's my pleasure Eins!
Achieve by taking great pride in everything you're charged with, be successful by having the initiative to charge yourself, and realize that talent is comprised of aptitude, hard work, and spirit. Hone in on your aptitudes and dedicate your spirit to reach your full potential.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
Thanks, I really needed this solution. I have to keep hundreds of mobile devices from dropping a session and this is the simplest solution I've seen.
Note, this method, keeps an extra session alive. The main page session ID remains the same, however, the iFrame will have it's own session ID that times out and renews.
Very good.
Buddy S
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
It's my pleasure friend, glad it could help you out! Let me know if you discover any other interesting implementations
Achieve by taking great pride in everything you're charged with, be successful by having the initiative to charge yourself, and realize that talent is comprised of aptitude, hard work, and spirit. Hone in on your aptitudes and dedicate your spirit to reach your full potential.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
Hi,
I check the followig condition in my Master Page.
If Session("UserId") = "" Then response.redirect("Login.aspx") End If
I've set the session time out to 240 minutes in global.asa file and also web.confic and it works fine in development.
When the application is deployed in IIs 6.0, the application times out after 20 minutes and the is redirected to Login.aspx...
Please suggest me what to do..
Naveen
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
Hi,
This seems to be just the sort of thing I'm after but I don't think it's working properly for me. I've only got a few months ASP.NET under my belt so many of these concepts are new to me coming as I do from a VB6 background.
I don't have a persistent user control but all the pages in my site use a single master page. My application stores the userid in session state and it is used in most database updates
I tried putting the Iframe in the body of the master page and left the app running until after the session would have timed out. When I clicked on the button I was returned to my login page and having entered the userid and pwd the update failed as it didn't have the user id anymore.
Can you suggest where I went wrong?
Thanks
Neil
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Hey Neil,
Glad to help out. Check your HTML output by right clicking on the page and doing 'view source'. You might have to give your iframe page some visual elements so you can right click on it in the browser to view source. Inspect the header and see what made it in there. That will tell you if the response was formed as you intended.
Make sure your iframe page is running on the same web as the master page. Make sure your clients have cookies enabled. Still at a dead end? review your authentication code to see what is going on there may be something in your code that is disposing the session variable you expect to be there and redirecting to authenticate again.
Next, go to amazon.com and buy the MCPD: Web Developer set of 3 books from Microsoft Press for the MCPD certification. If you're new to .NET, those are the most efficient resources to learn all the fundamentals for the cheapest price. I did the same thing back in 2001 coming to .NET from Perl, C, and fortran, but it wasn't until I got the MCSD training books for .NET 1.1 that I felt in complete control of the framework.
For ASP.NET focus on the internals - how it works, what happens when you get an HttpRequest, through to the HttpResponse. What is Global.asax? What does it do? How can you manipulate the pipeline with HttpModules? These are great things for a winform developer to master first, which will save a lot of frustration about the differences between win/web apps in .NET.
Cheers, Tommy
Achieve by taking great pride in everything you're charged with, be successful by having the initiative to charge yourself, and realize that talent is comprised of aptitude, hard work, and spirit. Hone in on your aptitudes and dedicate your spirit to reach your full potential.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Hi Thomas,
Thanks for the reply, I'd forgotten that I still had an issue with this so here goes.
I did a view source on the page (that uses a master page) and the source for the iframe was:
<iframe id="ctl00_Defib" src="/Defibrillator.aspx" frameborder="0" width="0" height="0"> </iframe>
I'm not sure what you meant by "Inspect the header and see what made it in there" as the iframe had to be placed in the body not the head.
All my pages, once the user has logged in use the same master page. All pages are running on the same web as I'm still developing on a single machine at present.
What should I look at in respect of authentication code? The user has to log in and from there on the menu uses the user's roles to identify what should be displayed so I'm assuming that the authentication is OK, is that a false assumption?
I'll certainly look into buying the books you recommend when I have some spare cash.
Thanks
Neil
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Hello,
If I implemented this in my master page footer and the page which is inheriting this master page on which I am doing some long database process. In this case what will happen? Does my process will get affected in any way? or something else?
Please guide me on this issue.
Thanks & regards,
Mahesh
RishabhMahesh
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Nothing should happen to the database access because you are firing the refresh from an IFRAME and not your main page. Bear in mind that the IFRAME will have it's own page associated with it.
Deja View - the feeling that you've seen this post before.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Thank you Thomas, That was an interesting article, and I want to try your suggestion in parts of our code.
I was wondering if you have a solution for another problem we run into: that the server empties its buffer after a time of inactivity.
Our situation is that we are running serveral domains on a server, and if someone calls the domain (www.domain1.com) after a periode of inactivity, the IIS has to load the whole code again before it answer the request.
I have seen it suggested that one could add a "keep alive" code that calls each domain, but was wondering if you had a better solution?
Thanks Bjørn
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Thanks for your interest Bjorn. I am curious if you are looking for the GAC. You can load your web assembly into the Global Assembly Cache and see if it helps your performance issue.
I wonder if there are other underlying issues. Are you seeking to improve upon scalability in general? I have used a number of techniques to do this in my architecture.
You can view one of my implementations at www.bridgestreet.com. Note how fast it is browsing through that site and searching it. Did you know that there is not a single letter that is static text in that site? Relational multilingual data is stored in a custom CMS.
It is multilingual for multiple domains, but those domains are on the same web in IIS.
It knows what your language preference is. You can go to www.bridgestreet.fr or www.bridgestreet.co.uk and you will actually be accessing the same code base, on the same web farm.
I made an interface ICacheable so that all classes that implement it can work with the Web Cache to reduce trips to the database exponentially. Also, all UI text that is not relational is not even in the DB, it is in the Satellite Assemblies (resx) and localized.
Tracing on a staging environment may also help you isolate the performance sink-holes. You may also seek out code sources of unscalability. I would refer you to Code Complete 2nd Edition by Steve McConnell, the chapter on Code Tuning.
Good luck with your solution and please let me know if I can help further!
Cheers, Thomas
Achieve by taking great pride in everything you're charged with, be successful by having the initiative to charge yourself, and realize that talent is comprised of aptitude, hard work, and spirit. Hone in on your aptitudes and dedicate your spirit to reach your full potential.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
It is my pleasure Mr. Ramesh, I am glad that you could make use of it! Thank you for letting me know. Regards, Thomas
Achieve by taking great pride in everything you're charged with, be successful by having the initiative to charge yourself, and realize that talent is comprised of aptitude, hard work, and spirit. Hone in on your aptitudes and dedicate your spirit to reach your full potential.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
If I used Ashaman solution, which is using the html page to refresh itself, other than the aspx, will the session refresh?
Because I think that an aspx page should be refreshed, to refresh the session, i did not try it, but this question has just popped into my mind!!
Nasser
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
General News Question Answer Joke Rant Admin
|