aspose file tools*
The moose likes Servlets and the fly likes confusion on session and request scope Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "confusion on session and request scope" Watch "confusion on session and request scope" New topic
Author

confusion on session and request scope

Yan Zhou
Ranch Hand

Joined: Sep 02, 2003
Posts: 137
Hi there,

I have some confusion on session and request scope, which was not completely answered by existing threads.

When is a better time to store info. in request scope than in session scope? I could not think of any example. It seems that if my web app. wants to be context aware, I always have to use session (besides cookie, URL rewriting).

When does a session expire? Some said that it expires if the client terminates or cookie expires. Is that correct? If I do not use cookie to store session, when will my session expire? Is that defined by a timeout value configurable in the container?

Info. stored in request scope is said to expire whenever responses comes back, if a JSP A calls another JSP B, any info. stored in request scope by A would still be visible in B, right? However, the next request to A will not be aware of the info. from previous visit, right?

If I do store info. in HttpSession, would that be a problem in a cluster environment where subsequent requests may not be directed to the same server as the intiating server? I thought that the container should automatically handles duplicating session in this case, i.e., I do not have to worry about anything. But I wish to confirm this.

Thanks a lot.

Yan
Ken Robinson
Ranch Hand

Joined: Dec 23, 2003
Posts: 101
Request scope is started when the server first gets the request and ended when the response is commited. You are correct that if Servlet A forwards to JSP B which may forward to JSP C the same request is shared between then.

The Session timeout is usually set at the server level in some type of config file. Usually a cookie or URL rewriting is used, but the container manages the 'who is this' of determining which Session to expose in a HttpServletRequest.getSession() call. You can always check Session.isNew() to see if this has just been created and thus will not have any previous info.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61766
    
  67

ended when the response is commited.


Not quite. The response can become commited via a flush before the request goes out of scope.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Ken Robinson
Ranch Hand

Joined: Dec 23, 2003
Posts: 101
Originally posted by Bear Bibeault:


Not quite. The response can become commited via a flush before the request goes out of scope.


True, but if the response has been commited then the request really serves no more purpose. I thought it best practice to never explicitly close or flush the out stream.
Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884

When does a session expire? Some said that it expires if the client terminates or cookie expires. Is that correct? If I do not use cookie to store session, when will my session expire? Is that defined by a timeout value configurable in the container?


On top to what had been mentioned, whenever I closes the browser window(s), my current session ends. Also, I could define the session timeout limit in the deployment descriptor (web.xml) or I could do it programmatically.



If I do store info. in HttpSession, would that be a problem in a cluster environment where subsequent requests may not be directed to the same server as the intiating server? I thought that the container should automatically handles duplicating session in this case, i.e., I do not have to worry about anything. But I wish to confirm this.


I don't think the container will automatically perform session smearing for you. You may have to configure the application server to do it for you. However, you'd be tied to the particular vendor since this is a vendor specific feature.


SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61766
    
  67

True, but if the response has been commited then the request really serves no more purpose.


Huh? After the response has been comitted, either by an explicit flush or because the buffer has filled and sent some data to the browser, the request is still viable and useful until the end of processing.

I thought it best practice to never explicitly close or flush the out stream.


Closing the stream is, of course, non-sensical, but I know of no proscriptions against flushing.
Richard Bradford
Ranch Hand

Joined: Apr 20, 2004
Posts: 48
Originally posted by Bear Bibeault:


Closing the stream is, of course, non-sensical, but I know of no proscriptions against flushing.


Can you explain why closing the stream is non-sensical. I always assumed it was best practice to close streams. Does the response handle this automatically?
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61766
    
  67

If you didn't open it, you don't close it.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: confusion on session and request scope