This week's giveaway is in the EJB and other Java EE Technologies forum.
We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line!
See this thread for details.
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes Session management ambiguity Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "Session management ambiguity" Watch "Session management ambiguity" New topic
Author

Session management ambiguity

Raj Menon
Ranch Hand

Joined: Oct 18, 2005
Posts: 45
A request comes from the client for the first page and through that he goes to second page and a session is running with that particular client.
Now the same client opens a new browser(eg:First time -IE,Second time- Mozilla) and requests for the second page.

I got the doubt that whether these both requests are in the same session or in different sessions.
By HFSJ(Pg no:199), i got that they share the same session.

Now my question is :
How they are able to share the same session?
For the session to hold good either cookies should be enabled in the browser or we've to encode the url with session id.

Suppose if i disable the cookies in IE before i send a request for the first time and after that when i send the request for the second page through Mozilla,
Whether both the requests share the same session or not?
If so please explain.

Even if cookies are enabled also - How different browsers share the cookie info that comes as part of request and response headers?
Mirko Bonasorte
Ranch Hand

Joined: May 14, 2007
Posts: 244
The 'client' word refers to HTTP client: in your case, two browsers mean two different clients.


SCJP<br />SCWCD 1.4 Upgrade (Remember: me stupid)<br />SCWCD 1.4<br /><a href="http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html" target="_blank" rel="nofollow">SCBCD 5.0</a><br /><a href="http://www.enthuware.com" target="_blank" rel="nofollow">SCBCD 5.0 mock exam</a> <br /> <br />SCEA 5 Part1: Preparing...
Raj Menon
Ranch Hand

Joined: Oct 18, 2005
Posts: 45
I agree with you that they both are different clients.

But in HFSJ(Pgno:199) (Plese refer to it,if you have the book)
The following conversation is there.

Second person : But master,I have meditated and still i do not know how one client could have more than one request..

First Person : You must think outside the container.......

Second Person : Very Wise advice,master!I have it!The client could open a new browser window!So the container can still use the same session for a client,even though it's coming from a differenet instance of the browser?
First Person : Yes!The container can see the request from the second window as coming from the same session

By the above conversation they are saying that those 2 are same clients
Rahul Bhattacharjee
Ranch Hand

Joined: Nov 29, 2005
Posts: 2308
The container identifies session with jsessionid which the client in session sends to server for all its requests.Suppose you open a session with an application and then right click on a link and click open in another window.In that case two instances of IE would send server the same jsessionid , so though the clients are physically two , but the server would not know that.It just gets is a HTTP request with jsession in cookie.


Rahul Bhattacharjee
LinkedIn - Blog
Atul Sawant
Ranch Hand

Joined: Jul 06, 2006
Posts: 304
The container never remembers the client this is when session is builed to make a stateful conversation.

Every request is thought to be from different client by the container. When a container gives the client a session id and when the next time a request is recieved by the container it checks if the request has the session id, if it has then it reconizes the client. If you are a client and you have got a session id from the container, you open two different browsers but both the browser while sending request would send a same session id which the container had sent earlier this is why the container reconizes that the two requests are from the same client no matter how many browsers you had used to send requests.

cookies are stored in some temporary folder and each browser uses the encrypted information in the cookie while interacting with the server/container. In your case, be it a mozilla or IE it will use the same cookie which has that particular session id.

Please let me know if this is still unclear.

Regards


Mission SCWCD. Mission SCJP Complete: SCJP 1.4 - 91%
Raj Menon
Ranch Hand

Joined: Oct 18, 2005
Posts: 45
Thanks Atul,
But still i got some amount of confusion.

First one :

You said
cookies are stored in some temporary folder and each browser uses the encrypted information in the cookie while interacting with the server/container


I think that the cookies that are stored in the temporary location are not these cookies that carry the info in request and response headers.Those are the Cookie objects that we add to the response object.

For Eg :
Cookie ck= new Cookie("name","Rajesh");
response.addCookie(ck);

I feel that this ck will be stored in temporary location not the one that is carrying session info in the headers



Second one :

Suppose let us assume that these cookies are also saved in temporary location and that info will be shared by different browsers but
if we disable cookies then the container is able to maintain the session only through URL rewriting.
So in the scenario that i explained how two different browsers share the same session
with that URL rewriting
Atul Sawant
Ranch Hand

Joined: Jul 06, 2006
Posts: 304
Rajesh...

your first doubt...

Think about it...when a request comes from a client to a container it generates a session id for that client and sends it to the client wrapped in the headers as set-cookie: JSESSIONID:... (uppercase, incase of tomcat). Next time the client sends a request it sends along the session id to the container. Now, where does the client seeks session id from which was send by the container? of course when the container had send the session id inside a cookie the client after recieving it must have stored somewhere so that next time he wants to send the request he seeks the information being stored.

There are no different "types" of cookies. They are just plain text files which have encrypted information.

second one...

ok...lets us say cookies have been disabled by all the browsers you have got. Example, IE and mozilla.

URL rewriting is done using two methods of HttpServletResponse interface.

1) public String encodeURL(String)
2) public String encodeRedirectURL(String)

You put a code like this in your servlet...

....
out.print("<br>click here for going 2nd page:" + response.encodeURL("2ndpage.do"));
...

Does not matter which browser you use i.e. Mozilla or IE the link being clicked will provide you the sessionid to the client through jsessionid:...(lowercase, in case of tomcat).

Next time your browser, mozilla or IE sends an request it uses the jsessionid in querystring...

http://localhost:8080/Beerv1/3rdpage.do?jsessionid:1234556

When container recieves it, it simply strips off the jessionid to detect which client it is and which HttpSession object/id it belongs to...

If you want to know how in URL rewriting where the information is stored when container sends the sessionid to the client or where does the client stores the sessionid information recieved from the container. I would be also interested to know. :-)
swarna dasa
Ranch Hand

Joined: Mar 15, 2007
Posts: 108
Pretty interesting....

Couldn't resist, so tried the following :-

Servlet code


JSP code (partial code)

<H2>Session is <%=request.getSession().getId()%></H2>

Browser - Mozilla Firefox v2.0.0.3
Web Container - Tomcat 5.0

Here is the Servlet Output
Case 1:- Enable cookies

a) First request sent:-

Output
Cookies are
New session 4C588E2FA3F77AC307459A557C6477D4 expires after 1800

b) Second request sent (new browser - Firefox new window)

Output
Cookies are
JSESSIONID 4C588E2FA3F77AC307459A557C6477D4
Old session 4C588E2FA3F77AC307459A557C6477D4 expires after 1800

Case 2:- Disable cookies (To be safe, block cookies from localhost )

a) First request sent:-

Output
Cookies are
New session 31747F37B0977622039AE913EF0A3D8B expires after 1800

b) Second Request sent:-

Output
Cookies are
New session A1F1556085377304BE8EB9D555EE0555 expires after 1800

When the servlet redirects to Result.jsp, i see the sessionid appended to the URL, but now when we open a new window and say
"http://localhost/beer/Result.jsp" a new session is created. (since jsessionid is NOT appended), but would the user ever append the session id? Dont think so.

So how does URL rewriting work?
[ May 19, 2007: Message edited by: swarna dasa ]
Atul Sawant
Ranch Hand

Joined: Jul 06, 2006
Posts: 304
it worked in my case......

i had disabled the cookies....

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

public class SessionTest extends HttpServlet
{
public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException
{
res.setContentType("text/html");
PrintWriter out = res.getWriter();
HttpSession session = req.getSession(); //this will not create session because cookies are disabled...
out.println("<html><body>");
out.println("<a href=\"" + res.encodeURL("session.jsp") + "\">click here</a>");
out.println("</html></body>");

}
}


in the jsp.....

<% if(session.isNew()) { %> This is a new session. The session id is <%= session.getId() %> <% } else {%> This is an old session <% } %>


Note: session is an implicit object of jsp...

i got the result as, this is an old session.....

this means the first servlet created the session using encode URL...before passing to jsp page!

about your code...

i did not understand why you used "Kookies"?
Everything else looks ok to me.

What did you exactly not understand about URL rewriting?
swarna dasa
Ranch Hand

Joined: Mar 15, 2007
Posts: 108
Thanks for the reply.

I think i misunderstood URL rewriting.
I thought that even if i open a new window and say "http://localhost:8080/webapp/Result.jsp" i would get the old session.
It is just that when i try to open the url, pointed by "click here", in a new window, would i get the same session (since it would have the jsessionid appended).

So if i am shopping on amazon.com and have my shopping cart with 3 items, and i open a new window and type www.amazon.com, i will not see these items at all (if cookies are disabled and url rewriting is used). However, if i try to open a new window by clicking a link in the previous window, the items (session) would be remembered.


PS:- I used getKookies(), because i wasn't allowed to post with "C", ranch filters thought the post had "malicious" code .
[ May 20, 2007: Message edited by: swarna dasa ]
Raj Menon
Ranch Hand

Joined: Oct 18, 2005
Posts: 45
Thanks Swarna for your post.I got the clarification with your post.

I got the same doubt as you said in your previous post

I thought that even if i open a new window and say "http://localhost:8080/webapp/Result.jsp" i would get the old session.


I got the below understanding based on all previous posts..

When cookies are disabled,if we open the second page directly(not through 'href' in the first page) in a new browser by typing it's url in the address bar, the previous session won't be there
(URL rewriting doesn't have a scope to work here)

But if cookies are enabled,the session management will work even if we open the second page url directly in a new browser by typing it's url in the address bar.


Any Expert Plese affirm this if the above is correct or else let me know if still i'm treading the wrong path.

Atul, Thanks for your posts but you keep on explaining the URL rewriting w.r.to 'href' link in the first page bur my doubt is same as the one what Swarna said(see the quoted content).
Thanks again for helping me to understand the cookie concepts.And a small doubt regarding these cookies.You said that even the Session cookies are saved in some physical location on the client machine.What is the lifetime of those session cookies because we won't(and i suppose we can't) specify max age for them,right?.How long they will be there on the client machine?
I feel that they will be there until the session expires.Like until we call session.invalidate() or until the session elapses the time specified for Max interval or session-timeour in DD,Right?
[ May 21, 2007: Message edited by: Rajesh Kodali ]
Rancy Chadha
Ranch Hand

Joined: Jul 12, 2006
Posts: 135
Hi Rajesh,
I am not an expert but I can tell you that, statements you wrote in bold are absolutely correct.
If you don't mind I would like to summarize why this happens
When cookies are disabled, if we open the second page directly(not through 'href' in the first page) in a new browser by typing it's url in the address bar, the previous session won't be there(URL rewriting doesn't have a scope to work here)

Now here when we open the link given through '<a href>' tag, the page you open is in the old session because res.encodeURL("any.jsp") will append the session id to the url. If you open the same page directly without using this tag obviously that link will have no session id appended to it and hence it won't be a participant of the old session.
Secondly,
But if cookies are enabled,the session management will work even if we open the second page url directly in a new browser by typing it's url in the address bar

With cookies enabled same thing works fine because the 'JSESSIONID' cookie has its maximum age set to -1 which means it will live only till the browser is open, once you close the browser JSESSIONID cookie will expire. In your case when you open second page url in new browser, the original browser which initiated a session is still open due to which the second page is also a part of same session. Why dont you go ahead and try opening second page directly in a new browser after closing the previous browser and then see if you get an old session or new session (With cookies enabled). You should get a new session.


Thanks,<br />-Rancy
Raj Menon
Ranch Hand

Joined: Oct 18, 2005
Posts: 45
Thanks Rancy for your affirmation..

I agree with you that the session cookie will expire as soon as we close the browser.

But i read somewhere that even if we close the browser, the session won't expire until the time it elapses the time that we set either using -maninactivetime which we set programmatically or session-timeout that we set in DD.


In HFSJ - 2nd option of 3 Question of the Coffe Cram in Session Management chapter emphasize the same.. which is...

A session will become invalid as soon as the user closes all browser windows-In HFSJ it is termed as FALSE


Please someone have a look at it and answer the below question

Is it Correct?
If it is so How the session will maintain?,
if the statement - "Session Cookie will expire as soon as we close the browser" - is TRUE
Atul Sawant
Ranch Hand

Joined: Jul 06, 2006
Posts: 304
Extremely busy days, completely swamped....Could not get time to sneak in here. I will definitely look into this and get back.
Promod kumar
Ranch Hand

Joined: Jun 26, 2006
Posts: 90
"But i read somewhere that even if we close the browser, the session won't expire until the time it elapses the time that we set either using -maninactivetime which we set programmatically or session-timeout that we set in DD."

Let me take a shot at this. The above statement is true. When you close the browser it does not automatically do anything to the session in the container. In fact The container has no idea that the browser closed etc. The only thing that happens is that the cookie on the browser machine is deleted/expired etc. So the user opens up a new browser and keys in the same url since the cookie is now gone the browser just sends a request to the container without the cookie information. The container looks at the request, does not find a session id in the cookie and so starts a new session. Meanwhile the old session still exists until the it times out or invalidated programmatically.
Sorry for the long explanation. Thanks for starting this post, I learned a lot reading this post than reading the books. Also I am new to the servlet technology so don't assume what I am saying is right.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Session management ambiguity
 
Similar Threads
HFSJ Final mock Q
Chapter 6(Session Management) notes (HFSJ) for revision
Preventing Two Instances of Same Web App
How to hide the jsessionid id in my address bar in servlet programming
Is session object thread safe.