How to detect browser closing to invalidate a jsp session

[kumar_ps78]

Hi all,
In my application which is using jsp and struts 2.0 ,when the user closes the browser window , I have to communicate this to some action class in struts framework , then I have to invalidate this session.
How to do this?
Please help me.

Regards
Senthil

[Steve11235]

I theory, you can't do that. The browser does not maintain a connection to the server, so the server has no idea what the browser is doing between posts.

I can suggest a possible hack. Add Javascript to the page to detect browser closing. Post a special form whose action field indicates that the browser is closing.

This will only work if the browser will allow one last post before it closes, and I have some doubts about that.

Another approach would be to try AJAX to do the same thing. Again, it all depends on the browser.

Also, closing a tab could signal end of session, when the user has the application open in another tab.

Tabs and multiple browser windows make Web applications very messy.

[masijade]

session timeout

It will be automatically invlidated after a specific amount of time of inactivity.

[Jasonre]

however if there is multiple browsers open, i believe session timeout doesn't quite work perfectly. However there are some ways you could handle this. store the last time an action has been access, session should work for this, and then when the next action is access, check against the timestamp saved and if it's been too long or something along that line, that might work.

i've had the same issue with my app, and i know that we did use session timeout past 5 mins i believe.

[masijade]

however if there is multiple browsers open, i believe session timeout doesn't quite work perfectly.

Inactivity is inactivity. Regardless of how many browsers are open. If they don't interact with the service, they don't interact with the service, and the timeout will take effect.

If multiple browsers are open to the application, then, of course, as long as one of them does something with the service, then, of course, the timeout will not, and should not take effect. Otherwise ....

[Steve11235]

Using session inactivity is problematic, and the tabs issue makes it worse, as only one session can exist even if multiple tabs point to the Web app. That happens on Intranet apps where users really use the apps.

Also, relying on session inactivity can cause the user to lose their work if it is set too short, and it can hold up resources if it is set too long. Again, on an Intranet, users can go away to meetings and then realize they were in the middle of something.

I ended up using my own persistence mechanism apart from the session. I then set the session timeout relatively short. However, if the session timed out, the user could still sign back in (through the Web app server, without the application being aware), and their screen session was still persisted. This also handles the multiple tabs issue.

I haven't used Hibernate, but it should allow you to solve this problem, as well as issues occurring in server clusters.

[masijade]

Whatever. If you don't want to rely on Cookies (which could, possibly, be a problem, although it should not be and never has been for me), then use URL rewriting (which has other possible problems). But this situation here, is one of the things that sessions (and timeouts) were designed for. If you wish to reinvent the wheel (or simply wish to go further and provide long term persistence), then be my guest and go ahead. Most of it is completely unnecessary though.

The OPs original question had nothing to do with persistence, however.

As far as mulitple tabs pointing to the same app, as long as they are using the same user, they should use the same session, and there is nothing wrong with that. And if someone is logging into the same app, on different tabs with different users, I say he deserves the problems that may arise. But there is also the app itself, to detect that they simply need to check that if they are on a login page, but a valid session already exists, that either the user should simply be told that he is already logged in, or the other session should be immediately invalidated. Neither of which is hard to check and do, and will eliminate those problems mentioned.

Doing that (or when the site doesn't even have a login) then it shouldn't matter, in the least, how many browsers or tabs are directed at the site. A session is to track a user on the site, regardless of how many "windows" he has open to that site, they all belong to the same session, and that is as it should be.

[Steve11235]

The original post asked how to reclaim resources at the server when a the browser window is closed. My post told him of a possible method and warned him of possible side effects of killing a session prematurely. Bottom line, Web applications that attempt to use the session as the sole means of maintaining state can run into a lot of problems. I found this out the hard way.

Back to the orignal question... What I did in my Web apps is to provide an "X" icon as part of the application. Clicking it sent a post to the server, saying that the user wanted to end the application. This allowed me to release resources without killing the session, since the user could be signed on in other tabs/browser windows. I also intercepted window closing events in Javascript and popped up a message box, telling the user not to do that and to use the "X" instead.

--

The reason cookie-based sessions (which is how all Web app servers I worked with, it's been a while, worked) are problematic is that a browser maintains cookies by the server's address. So, if more than one tab or browser window points to the same server, the server sees a session cookie already exists and uses that session.

The advantage is that the user only has to sign in once. The disadvantage is each tab or browser window is sharing the session, so each application must be very careful about removing information from the session, much less killing it.

[masijade]

The original post asked how to reclaim resources at the server when a the browser window is closed.

And a simple session listener will be able to take care of that.

Edit: And I am not saying your suggestions are bad, just, for most situations unnecessary, and can be complicated and would usually be difficult to get right, leading to other, and probably more critical, problems. Especially when the standard tools, once again for most situations, are more than capable.

Edit Again: And, with the proper use of Filters, the Servlets/JSP's themselves, never need to worry about the Session, except to store/retreive items from it.

[fishtoprecords]

And a simple session listener will be able to take care of that.

No, a simple session listener timeout detects a lack of interaction. Which may be caused by the user closing the window, or the user going for a cup of tea. You don't know. You can't know.

The HTTP RFCs are stateless. You simply can't tell from a simple application. With AJAX or other hacks, you have have the browser periodically ping the server, and use that to verify that the window is open. But then the AJAX call defeats using an inactivity timeout.

This is unsolvable as written by the OP. But until he comes back, there is no reason for us to argue about subtle solutions.

[Steve11235]

I think everyone's contributions are valuable here, as they represent different perspectives on this issue.

Masijade is right in saying that a simple Web app need not concern itself with all the issues of whether the browser window is still open and how the Web app server keeps track of sessions. Since the OP never responded again, they may have decided just to keep things simple and ignore the browser close issue.

And I agree with FishTopRecords that more advanced developers have to understand the complexities (created by its simplicity?) of Web technology.

Overall, I think this is a good conversation.

[masijade]

No, a simple session listener timeout detects a lack of interaction. Which may be caused by the user closing the window, or the user going for a cup of tea. You don't know. You can't know.

That statement, was, of course, taken in the context of the entire conversation which had turned to session timeouts. And a session listener could easily close the resources that need to be closed once a timeout hits. If you read the previous posts, you will see that that is what I have been saying all along.

[neeraj.singh]

try to put an AJAX call on the body unload event.
hope this will help you.

[mumra]

Thank you neeraj. I had to read through this entire thing to get an actual answer.