This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
This is my first post. I was not sure where to put up my query.Since, this thread talks about session that never expire, I am posting my query under this thread!
[Edit: please ask your own questions in your own new topics. I have split this into a new topic for you.]
I am learning servlets and came across the a point in HF-S&J: 'A session whose timeout period has been set to -1 will never expire'. While searching for details I found this description :
'Setting the inactive period as negative(-1), makes the container stop tracking session, i.e, session never expires'
On a high level, my understanding is that if container stops tracking sessions, then is there no point of creating session object at all! i.e. if the container does not track sessions at all, then all HTTP requests would be like a new request from a new client. It becomes the same old stateless protocol, having no clue of any previous request of the client whatsoever. Although, I understand that timeout may be set to negative value for particular sessions objects only (using setMaxInactiveInterval()), but even then, those un-tracked sessions should be as good as being destroyed (a better option in memory utilization perspective).
Please let me know if my understanding is correct. In addition, an example citing a scenario where setting timeout to -1 can be recommended, would be very helpful.
Is there an alternative in J2EE where cookie persists until it has been deleted by client and tracks the sessions as well (unlike setting timeout to negative)?
If you set max interval to -1, the server will track sessions. The sessions will never expire
Not a good way to implement a "Remember me" option though, because you don't want to keep state in memory forever. The way most applications do it is passivate the state into persistent storage when the HTTP Session expires. Next time when the user visits the website with a cookie for a session that has been passivated, the state gets activated into a new HTTPSession. Technically, the user gets a new session, but the new session has the same state as old session, so s/he doesn;t know the differrence.
Arindam Basu - Arii
Joined: Apr 16, 2012
Just to clarify my understanding: the container passivates the session object at the time of expiry (which may happen when the client closes the browser, or the max interval value has been exceeded), and puts the passivated object into persistent storage, a 'passive session pool', maintained by the container, and when a new request comes in that do not belong to any of the active sessions, the container looks into that 'passive session pool' for a match. If there is a match, the object is taken out of pool, activated and loaded into memory (new session objects created with the same attributes as the passivated session objects) and the session commences as if the client's previous session has been continued. This is almost a session migration (within-same-VM in non distributed environment, may or may not be between different VMs for distributed environment) using persistence storage intermediately!
Is this understanding correct?
Does the container maintain a look-up for the passivated sessions in persistent storage? Or some kind of session-id-sorted data structure is maintained for fast searching?
Your understanding is essentially correct, but unfortunately a servlet container will not do all that. According to Java specs, all a servlet container is responsible for is creating and maintain the session in memory and calling the SessionListener when the session expires. According to the specs, the Servlet Container is not responsible for activating/passivating the session from persistent storage.
IIRC, JBoss does support session passivation behind the scenes. If you are using JBoss, you can just set session-timeout to -1, and let JBoss handle it. Remember that everything in your session need to be serializable for JBoss to passivate it
If you want to build something that is platform independent, you will need to do passivation/activation yourself.