confusion on session and request scope

[Yan Zhou]

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]

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]

ended when the response is commited.

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

[Ken Robinson]

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]

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.

[Bear Bibeault]

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]

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]

If you didn't open it, you don't close it.