We Keep Coding

Manually reset session timeout (keep alive) in a spring web application

Is it possible to manually reset the timeout interval of a specific session for a user that is currently logged in my web app?
I would like the ability to do something similar to this :
public void keepAliveForUser(long userID) {
Session session = this.userSessionManager.getUserSessionById(userID);
session.resetTimeOut();
}
P.S - keep in mind this function is not being called in a follow up to a user request. (i.e. It's called from a cron job, a scheduled task, etc...)
Thanks!

You can use HttpSession#setMaxInactiveInterval to change the session expiry time on the fly
Java Doc
Specifies the time, in seconds, between client requests before the
servlet container will invalidate this session. A negative time
indicates the session should never timeout.
Usage
//session will expire after 2 hours of inactivity
session.setMaxInactiveInterval(2 * 60 * 60);

Session timeout hierarchy:
$tomcat_home/conf/web.xml
$your_webapp/WEB-INF/web.xml
manual invocation of HttpSession.setMaxInactiveInterval(int)

Different sessions for different tabs of the same browser

I am using timestamp till nano second as a user session, say tab A has session1 and user opens tab B say this session is session2 and now session1 gets only inactivated after some file upload activity is done at this point of time I want the session2 be still active.
How do I do this without using cookies?

have you looked into html5 sessionStorage/localStorage ?
these apis sport a client-side storage facility pretty similar to cookies which you can employ to manage sessions. the lifetime of the database is either the lifetime of the respective tab/window (ssessionStorage) or the interval between two consecutive deletions the pertaining browser data; the latter may depend on the browser preferences (eg. automatically after closing the tab/window in privacy mode or upon express user request).
for a start, mdn has something to say about it. there also is a full-fledged tutorial on html5rocks.
the gritty in-depth w3c standard details all about the programmatic (javascript) interface.
the api do not provide facilities to exchange information between client and server. one option to handle this part would be encoding the information into urls (client -> server) or http headers (server -> client) being called/received through ajax.
a final word of warning: for security reasons, do not store authenticating data this way.

say tab A has session1 and user opens tab B say this session is session2
This is already impossible. Both tabs will be in the same session. If tab B created a new session due to a login for example, tab A will now be in the new session.
and now session1 gets only inactivated after some file upload activity
It won't happen.
is done at this point of time I want the session2 be still active.
It still is. Session 1 will have been destroyed if it's different from session 2.

Play framework how do sessions and cookies work?

How does play validate a cookie?
I noticed that after I restarted the server I was still logged in even though I
don't presist any session data in the database.
I also noticed
that I could set the date on the server to be larger that the exipry
date of the cookie and still I was logged in.
I logged out
(saved the cookie to a text file) and the browser lost the cookie. Then I
recreated the cookie from the text file and I was logged in again.
The cookie looks like this:
PLAY_SESSION=e6443c88da7xxxxxxxxxxxxxxxxxxxxxxxxxxxxx-userid%3A1
// My logout code
def logout() = Action {
Ok("").withNewSession
}
From the documentation
Discarding the whole session
There is special operation that discards the whole session:
Ok("Bye").withNewSession

You didn't specify how do you authenticate users, so I just guess, that you;re using simple sample which is... simple.
It uses user's id to identify the user, and check if signed session cookie wasn't manipulated, therefore if you'll recreate the cookie with proper signature it will be valid still.
You should create some area for session's keys on the server side ie. in DB or in memory cache (Which will be faster than DB). Its key should be randomly generated (and preferebly quite long) for each successful login action, and should also contain data for identifying user, expiration date etc. Next you should put this random sess_key to the Play's session instead email address of logged user or id of his row in DB, and after logout and/or expiration date it should be removed. In such case even if you'll loose the cookie after logout it will be impossible to login properly with non-esixting sess_key.
AFAIR standard memory cache will be purged at every restart of the application, to make sure that all sess_keys from DB will be removed as well you can use Global object and truncate the table in onStart(...) method.

I found the answer reading the documentation more carefully and combining different parts.
There is no technical timeout for the Session. It expires when the
user closes the web browser. If you need a functional timeout for a
specific application, just store a timestamp into the user Session and
use it however your application needs (e.g. for a maximum session
duration, maximum inactivity duration, etc.).
It’s important to understand that Session and Flash data are not
stored by the server but are added to each subsequent HTTP request,
using the cookie mechanism. This means that the data size is very
limited (up to 4 KB) and that you can only store string values.
So that was what i feared that if the cookie get lost anyone can log in to the server for all future.
What I have to do to secure this is to add a self-made timestamp authorization (save a timestamp in the cookie and validate sever side)

WebSphere Commerce - How does ReLogonFormView / Session Expiration Work?

Sorry for the broad topic. Basically, WSC is supposed to have out-of-the-box session timeout handling by forwarding the user to the ReLogonFormView, which the user can presumably configure (through Struts) to any jsp that they choose. We use a custom logoff command, and it seems to be affecting that view showing up.
I'm not looking for a specific solution to this problem, I'm just looking for general knowledge about how WSC (v6) handles session timeouts (how it determines that the session has timed out) and what command(s) it runs by default when / if / to determine the session has expired.

This is my current knowledge on this subject...
The session timeout is a global value for all web modules and can be found in the wc-server.xml and is set to 30 minutes OOTB.
When a timout occurs, the OOTB LogoffCmd would normally be called, which will set up the necessary URLs to navigate to the ReLogonFormView URL while keeping hold of the URL where the session timeout occurred.
If the ReLogonFormView contains userid/password fields to allow the user to logon again, the user will then be redirected back to the page they were originally on.
More info can be found in IBM InfoCenter under "LoginTimeout".
If you extend the OOTB LogonCmdImpl, you should not try and set the forwarding URL, or that will interfere with the OOTB navigation.
I think you should perform your custom logoff functionality and then call super.performExecute() to allow the OOTB navigation logic to take over.
Note: You can retrieve the URL you were originally on via a call to getReferrerURL() and the ReLogonFormView should be returned from getURL().

Invalidate a session

I have a jsp servlet based application, with session time out of 30 mins, I want to invalidate the session as soon as a person closes the browser window intentionally or accidentally (OS shutdown/close from tast manager/powerdown)
Can I put a check for that and invalidate the session?

It is not possible to handle this scenario .
There are some browsers which provide this setting as their preference , but you can't handle this programitically.
At max:
You can make a poll from page(may be header) same as gtalk in gmail as soon as connection closes wipe that session out.

Why do you want to do that, you have already configured that in server that ,session should stay idle for 30 mins,after that it will expire in server.
if you want to do that use the following javascript or jquery(better for cross browser) , when the browse close event happens send an ajax request to invalidate session by running following code in jsp
(request.getSession(false).setMaxInactiveInteral(0);)
From javascript
<body onbeforeunload="doAjaxCall();">
(or)
jQuery(window).bind("beforeunload", function(){
// Do ajax request and dont wait for the response.
});
You can implement the server push ajax polling , for example think that session is going to expire in another 2 seconds , send a server side request to client to invalidate the cookie and also in the server you can invalidate the session.
if ( (getcurrentTime() - session.getCreationTime()) > 2000 ) {
}
While the page is rendered , get the maxinactiveinterval and then set the value to the JavaScript variable , then use setInterval function , pass the inactiveinterval value to function , once the timeout happens you can set the cookie to expire.

No I don't believe you can do that as there are no hooks available in the browser to get it to send a disconnect notification (of some sort) when it closes and I don't think there is a server-side mechanism to interrogate recent sessions to test their connection status.

If you are using tomcat 5.0/5.5/6.0 container, the cookie generated by tomcat session manager to track the session (JSESSIONID) is a per-session cookie (browser memory only cookie) instead of a persistent cookie (write to disk). That's because the session manager does (hardcoded) setMaxAge(-1), so that the generated HTTP-response contains:
Set-Cookie: JSESSIONID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; Path=/ and no Expire=date.
So when the browser is closed (all browser windows, or just the window containing the cookie, depending on the variuos browser implementations), the cookie - and the session - are lost. [*]
This has nothing to do with <session-timeout>, which is a setting that tells the tomcat server-side session manager to expire sessions when idle for more time than specified.
[*] they will still be persisted on disk on the server-side, till session-timeout expires, but there wont be a request with a cookie activating them.