Cookie and Session are distinct things. Cookie only works in the bounds of session.
If you set cookie's timelife on -1, that cookie will live till browser shuts down.
If you set session's timelife on -1, that session will live forever.
Moreover you can set in your browser that cookie will be alive forever.

Lukas Smith wrote: If you set session's timelife on -1, that session will live forever.
.

i know it's correct as per the book,spec,and other tutorials. but from yesterday i am trying to figure about the problem due to which the session is being destroyed in my small app "count" despite session timeout -1.

i am attaching the complete app zipped .
may be i am missing something.
the app is running prefect except the session is being destroyed after closing the browser.

In same chapter it is stated about cookies that:
"By default cookie lives only as long session. Once client quits the browser, cookie disappears."

Does that mean a session is destroyed when client quits the browser?

I believe not. See HFSJ CH6#3. The session exists serverside. The server has no way of knowing the client quit the browser ("there is no explicit termination signal in the HTTP protocol"). The session will live until the container times it out (or otherwise invalidates it). As Lukas notes, the session and cookie are different things.

"By default cookie lives only as long session. Once client quits the browser, cookie disappears."

The author does not mean here it is a HttpSession object. The HttpSession object remains on the server even if you close the browser since http is a stateless protocol.Its not possible for the server to know that browser is closed.

The session here looks like browser session.when you start a browser its session starts and it will get closed when you close the browser.Please correct me if i am wrong.

Avi, how do you know that the session is destroyed when the browser is closed?? Did you create a SessionListener to see if the session is actually destroyed?? Also your code seems a little weird to me. Why are you actually creating the reference a1?? You're not using it, maybe you want it as an attribute in the session scope...

Hey Chandan,
As you can see that the session is not getting destroyed, still the application is not able to get session from of request object. As we know session tracking happens through cookies. If cookies are disabled you would not be able to use session unless you use url encoding. URL encoding would resolve your problem.

I am attaching a section of hfsj. I believe, this would help you to resolve your problem
If cookies don’t work, the Container falls back to URL rewriting, but only if you’ve done the extra work of encoding all the URLs you send in the response. If you want the Container to always default to using cookies first, with URL rewriting only as a last resort, you can relax. That’s exactly how it works (except for the first time, but we’ll get to that in a moment). But if you don’t explicitly encode your URLs, and the client won’t accept cookies, you don’t get to use sessions. If you do encode your URLs, the Container will first attempt to use cookies for session management, and fall back to URL rewriting only if the cookie approach fails.

avi sinha wrote:if the session is null here then i can say that session was destroyed. am i right ???

No, you cannot say that, create a session listener to confirm that.

Edit
I did an experiment, I changed the inactive interval of the session to 400 seconds, but the max age of the JSESSIONID cookie was still -1 i.e. it will exist only till the browser window is open. The spec doesn't say that changing the inactive interval of the session changes the cookies age. That's why when you close and reopen the browser window, you get a new session. But again that doesn't mean that the session is gone. The session will be gone after the timeout period i.e. 400 seconds in my case or never in case of -1 value...

if the session is null here then i can say that session was destroyed. am i right ???

Nope, you can not say that the session was destroyed just by verifying request.getSession(false) is returning null.
The trick is behind, what container does to return the correct and required session at a call of request.getSession(false). Container tracks this using the value of jsessionid cookie. If the cookie is disabled in the browser and url rewriting has not be used, the container would not find any way to identify the correct session.

Due to this reason the container would think that this is the first request of which session is yet to be created and would return null at a call of request.getSession(false).

You write that after browser closing - cookie are deleted.
But I think it is browser dependent. We can set that cookies will not be deleted. What would happen when we set cookie lifetime to -1 and we manage browser no to delete cookie after closing?
What do you think?

can anybody please post the code for setting the cookie lifetime required to get the session working even after closing the browser ( i.e. after restarting the browser ) ... cookie settings in my browser is set to KEEP UNTIL THEY EXPIRE

the reason for asking this is that i have read in the book that we should never use the work JSESSIONID in our servlet or something is going wrong ...

i agree with the point that session object is not being destroyed. we are unable to reference that after restarting the browser. so i just want to get a solution for this problem..

First request form browser. There is no header Cookie in the request so the container creates a new session and sets header Set-Cookie in the response. Now everything is OK. Browser and container knows each other .

Then we close the browser. We can assume that session and cookie are alive. We request the same URL. But there is no header Cookie in the request. Browser did not put cookie and URL together.

You can extract the JSESSIONID cookie from the request object (i.e. get the array of cookies and find the one with the name JSESSIONID) and then set its max age to a large value. This way it will persist even after browser restart. Generally you'll not need to use JSESSIONID cookie as there's generally no need to persist a session for infinite time. For sites that have a feature like "Keep me logged in for 2 weeks" etc, they set a different cookie on the client machine (which persists for 2 weeks) to identify the user. The session gets invalidated after some time but when a new request is sent to the site, the client is identified using the custom cookie and a new session is created for the client...

Ankit Garg wrote:You can extract the JSESSIONID cookie from the request object (i.e. get the array of cookies and find the one with the name JSESSIONID) and then set its max age to a large value. This way it will persist even after browser restart. Generally you'll not need to use JSESSIONID cookie as there's generally no need to persist a session for infinite time. For sites that have a feature like "Keep me logged in for 2 weeks" etc, they set a different cookie on the client machine (which persists for 2 weeks) to identify the user. The session gets invalidated after some time but when a new request is sent to the site, the client is identified using the custom cookie and a new session is created for the client...

thanks ankit
well i had tried this way but it was giving me a bad feeling (book:should not use JSESS.... ).

For sites that have a feature like "Keep me logged in for 2 weeks" etc, they set a different cookie on the client machine (which persists for 2 weeks) to identify the user. The session gets invalidated after some time but when a new request is sent to the site, the client is identified using the custom cookie and a new session is created for the client...

I believe, the client related information is stored in session not in cookie. Could you please explain how can an application identify a client just by cookie when the session is invalidated.

For sites that have a feature like "Keep me logged in for 2 weeks" etc, they set a different cookie on the client machine (which persists for 2 weeks) to identify the user. The session gets invalidated after some time but when a new request is sent to the site, the client is identified using the custom cookie and a new session is created for the client...

I believe, the client related information is stored in session not in cookie. Could you please explain how can an application identify a client just by cookie when the session is invalidated.

one possible solution can be storing the unique userid in the cookie . ( i think ... not very much sure about it )

OK. I have checked it.
But I set:
c[0].setMaxAge(20*60); //c[0] is JSESSIONID cookie
And I saw in Firefox that JSESSIONID cookie is valid till the end of the session. I do not understand that.
Moreover I set the max inactive interval of the session: 20*60 and I set that Firefox will not delete any cookies.
After I close the browser - despite that facts - cookie is deleted and new session is created. Confusion

OK, have a good night sleep to keep clear mind .
Any other cookies (from different hosts) work well. They exist after browser closing.
Maybe it's some kind of incompatibility between Tomcat 5.5 and the new version of Firefox?

As I said earlier, if you set the maximum interval of the session to a value, that doesn't change the age of the cookie. The JSESSIONID cookie has the default age of -1 that is till the browser is open. You'll have to manually set the age of the JSESSIONID cookie to make it persist a browser restart...

Salil Vverma wrote:I think, that is how they set the max age of cookie and session, in those application, which gives user a functionality to keep logged in for user specific time like 2 weeks.

It can be done like that, but if I were to do this, I wont maintain a user's session object for 2 weeks, that will put a lot of load on my server, its better to timeout the session after half an hour or so and identify the user from a custom cookie and give them a new session on the next visit. This is what is implemented here at javaranch too, if you have seen, the checkbox at login page says something like "Log me automatically in on each visit"...

Ankit Garg wrote:As I said earlier, if you set the maximum interval of the session to a value, that doesn't change the age of the cookie. The JSESSIONID cookie has the default age of -1 that is till the browser is open. You'll have to manually set the age of the JSESSIONID cookie to make it persist a browser restart...

Ankit, please read carefully.
I have written above:

Lukas Smith wrote: I set:
c[0].setMaxAge(20*60); //c[0] is JSESSIONID cookie
And I saw in Firefox that JSESSIONID cookie is valid till the end of the session. I do not understand that.
Moreover I set the max inactive interval of the session: 20*60 and I set that Firefox will not delete any cookies.
After I close the browser - despite that facts - cookie is deleted and new session is created.

Interesting, I tried and Tomcat 6 doesn't change the age of the JSESSIONID cookie even when I manually set its age. The age of the JSESSIONID cookie is always -1 even if I set its age to 400 sec. I didn't find anything related to this behavior in the specs so I suppose this is container specific...