Confusion about session destruction

[Amru Jahagirdar]

In Head First Servlets & JSP, it is stated that there are only 3 ways a session can die.
1.Timeout
2.Invalidae()
3.Application shut down.

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?

[Lucas Smith]

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.

Correct me if I am wrong.

[avi sinha]

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.

  web.xml

<web-app>

	<servlet>
		<servlet-name>counter</servlet-name>
		<servlet-class>com.web.countServ</servlet-class>
	</servlet>
	
	<servlet-mapping>
		<servlet-name>counter</servlet-name>
		<url-pattern>/showCount</url-pattern>
	</servlet-mapping>
	
	<session-config>
		<session-timeout>-1</session-timeout>
	</session-config>
	
</web-app> 
 

  my servlet
 package com.web;
import com.model.*;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class countServ extends HttpServlet{
	
	public void doGet(HttpServletRequest request,HttpServletResponse response)throws IOException,ServletException{
	
	HttpSession  session= request.getSession(false);
	
	
	if(session==null){
		Count a1=new Count();
		a1.setCount();
		session=request.getSession();
	
}
	
	RequestDispatcher view = request.getRequestDispatcher("/count.jsp");
	view.forward(request,response);
	}
	} 

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.

avi sinha

[Amru Jahagirdar]

Lukas, thanks for the reply.
my confusion was by the statement:
"By default cookie lives only as long session. Once client quits the browser, cookie disappears."

It implies that cookies live until session lives & when browser quites, cookies disappear.
It means session dies when browser closes. Is that correct?

[Mike Mitchell]

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.

[raj malhotra]

"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.

[Lucas Smith]

avi please try to set session's timelife using method invocation from session's object.

[avi sinha]

Lukas Smith wrote:avi please try to set session's timelife using method invocation from session's object.

if you are talking about setMaximumInactiveInterval() , i have tried that too but problem is still the same.

[Ankit Garg]

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...

[chandan kumar mitwaa]

Ankit Garg wrote:....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?? . ....

I wrote a Listener implementing HttpSeeionListener as:

  import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;

public class Listener implements HttpSessionListener
{

	public void sessionCreated(HttpSessionEvent arg0)
	{
		System.out.println(arg0.getSession() + " is being created");
	}

	public void sessionDestroyed(HttpSessionEvent arg0)
	{
		System.out.println(arg0.getSession() + " is being destroyed");
	}

}  

I tried a little different than Avi:

I send a request to CounterServ once, and the output is:


org.apache.catalina.session.StandardSessionFacade@c7d924 has been created


I resend the request by retyping in the addess bar in the same browser window...

The problem is that it prints the following output:

org.apache.catalina.session.StandardSessionFacade@f29837 has been created


which is quite unexpected.

Session should not have been created the second time.




Ankit, would you please explain me thee above phenomena.....

[priya rishi]

hello chandan, check your browser cookies - enabled.

[Salil Vverma]

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.


A sample code stating the url encoding example is as mentioned below

public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException {
response.setContentType(“text/html”);
PrintWriter out = response.getWriter();
HttpSession session = request.getSession();
out.println(“<html><body>”);
out.println(“<a href=\”” + response.encodeURL(“/BeerTest.do”) + “\”>click me</a>”);
out.println(“</body></html>”);
}

[avi sinha]

Ankit Garg wrote: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??

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

Why are you actually creating the reference a1?? You're not using it

actually the code which i have posted is not complete . please download the attachment .

avi sinha

[Ankit Garg]

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...

[Salil Vverma]

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).

[chandan kumar mitwaa]

priya rishi wrote:hello chandan, check your browser cookies - enabled.

Sorry, you caught me. I enabled the cookies and now it is wokin fine.

[Lucas Smith]

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?

[avi sinha]

thanks everyone for replying

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..

avi sinha

[Lucas Smith]

Let's analyze this.

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.

Correct me if I am wrong.

[Ankit Garg]

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...

[avi sinha]

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.... ).

anyways thanks again . i got the point.

avi sinha

[Salil Vverma]

Hey Ankit,

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.

[avi sinha]

Salil Vverma wrote:Hey Ankit,

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 )

avi sinha

[Lucas Smith]

We close the browser. We can assume that session and cookie are alive. We request the same URL. So is there any binding between URL and cookie?

[avi sinha]

Lukas Smith wrote:We close the browser. We can assume that session and cookie are alive. We request the same URL. So is there any binding between URL and cookie?

well i think yes. you can have a look inside the browser cookies . it shows for a particular cookie
the server
cookie name
cookie value

i think whenever we request a particular resource from a server, any cookie residing in our system associated with that server address , is attached with our request . again not sure though.

avi sinha

[Lucas Smith]

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

[avi sinha]

the same thing is being happened in my web app which i have uploaded above... still confused

well i am not worried about the exam but ....
i will check it once again tomorrow... now feeling sleepy

avi sinha

[Lucas Smith]

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?

[Ankit Garg]

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]

Hey Ankit,

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.

Kindly correct me if I am wrong.

[Ankit Garg]

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"...

[Lucas Smith]

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.

[Ankit Garg]

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...

[Lucas Smith]

Do you think it is a kind of Tomcat's bug?

[Lucas Smith]

OK, I have solved the problem

    
//import statements
public class CookieTest extends HttpServlet {
	
	public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException{
		
		HttpSession session = request.getSession();
		session.setMaxInactiveInterval(20*60);
		
		if(! session.isNew()){
			Cookie[] c = request.getCookies();
			c[0].setMaxAge(20*60);
			response.addCookie(c[0]); //this is the key
		}
	}
}

After that there are two cookies in my browser. After reopening - there is the only one .
What do you think?

[avi sinha]

Lukas Smith wrote:OK, I have solved the problem

After that there are two cookies in my browser. After reopening - there is the only one .
What do you think?

well i think the container will look for the original one.have you checked this one???
and isn't it strange ??? two cookies with the same name . looks like two variables with the same name


avi sinha

[Lucas Smith]

After closing my browser the container uses the second cookie and everything works OK

[avi sinha]

Lukas Smith wrote:After closing my browser the container uses the second cookie and everything works OK

that's great Lukas

please upload your web-app if you can

avi sinha

[Seetharaman Venkatasamy]

Ankit Garg wrote: I suppose this is container specific...

True

[Lucas Smith]

This works fine:

 public class CookieTest extends HttpServlet {  
       
     public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException{  
           
         HttpSession session = request.getSession();  
         session.setMaxInactiveInterval(20*60);  
           
         if(! session.isNew()){  
             Cookie[] c = request.getCookies();  
             c[0].setMaxAge(20*60);  
             response.addCookie(c[0]); //this is the key  
         }  
     }  
 }