request.setAttribute(...) versus session.setAttribute(...)

[Matt]

I want to confirm the differences between request.setAttribute(key,
value) versus session.setAttribute(key, value).

My understanding is that request.setAttribute only make the key
available in the following jsp page. But session.setAttribute will
make the key available in many pages, as long as in the same session,
and browser not close.

For example, the flow like page1->page2->page3->page4.
session.setAttribute will make the key available in all pages. But if
we use request.setAttribute in page2, then only page3 can get the key
value set in page2.

Please advise if i miss something.
thanks!!

 

[Sudsy]

Matt wrote:

For example, the flow like page1->page2->page3->page4.
session.setAttribute will make the key available in all pages. But if
we use request.setAttribute in page2, then only page3 can get the key
value set in page2.

Please advise if i miss something.
thanks!!

Almost...
But if page2 provides the capability (e.g. a "back" button), and the
controller is configured appropriately, then page1 can access the
attribute set in request scope if it is the forward target.
That's why you have to be so very careful when setting up application
flow. I've written an article about how the "back" button can actually
propogate upwards unintentionally, especially when you forward to
another Struts Action: you end up on the first page of a flow if you
don't guard your session/request attributes.

 

[John C. Bollinger]

I want to confirm the differences between request.setAttribute(key,
value) versus session.setAttribute(key, value).

My understanding is that request.setAttribute only make the key
available in the following jsp page. But session.setAttribute will
make the key available in many pages, as long as in the same session,
and browser not close.

A request attribute will be accessible via the specified key to all JSP
pages (and other servlets) processing the same HTTP request. There may
be more than one such page / servlet if (and only if) one of them
forwards to or includes another; an HTTP redirect, in contrast, causes
the client to issue a new request. A human user explicitly asks for a
new request to be issued by clicking the "reload" button in his browser.

A session attribute will be accessible via the specified key to all JSP
pages (and other servlets) processing a request in the same session.
Period. Closing all browser windows will typically prevent any more
requests from being issued in any previously existing sessions tied to
that browser; I don't know of any exceptions to that behavior, but it is
outside the scope of the servlet spec.

For example, the flow like page1->page2->page3->page4.
session.setAttribute will make the key available in all pages. But if

There are some caveats, but basically yes.

we use request.setAttribute in page2, then only page3 can get the key
value set in page2.

I'm guessing that you mean the user clicks on a link or posts a form on
page1 to get to page2; and likewise to get from page2 to page3 and from
page3 to page4. Each page is then served up in response to a separate
request, and in that case NO, a request attribute set by page2 is NOT
accessible in page3, it is only accessible in page2. Furthermore, such
a request attribute must be set anew during processing of *each visit*
to page2 if it is to be used by the page implementation -- it is not
inherited from any previous visit to that page.

As Sudsy was pointing out, you also need to watch out for caching
behavior. User agents (generally browsers), proxies, and web servers
all may cache responses under certain circumstances. All may cause
trouble, but the most likely to do so are user agents. For instance,
when a human user clicks the "Back" button on his browser's toolbar, he
will generally get a cached version of the previously visited page
instead of causing a new request to be issued for that page. This may
be different from what he would get by reissuing the same request by
which the cached page was originally fetched.


John Bollinger
(e-mail address removed)

 

[pet0etie]

<quote>I've written an article about how the "back" button can actually
propogate upwards unintentionally, especially when you forward to another
Struts Action: you end up on the first page of a flow if you don't guard
your session/request attributes.</quote>

where can i find that article ?

greetings,
pet0etie

 

[Andrew Thompson]

<quote>I've written an article about how the "back" button can actually
propogate upwards unintentionally, especially when you forward to another
Struts Action: you end up on the first page of a flow if you don't guard
your session/request attributes.</quote>

where can i find that article ?

I am not sure, but Sudsy mentions both Struts and the 'back' button
in this article.. <http://www.sudsy.net/technology/struts-arch.html>

 

[Anton Spaans]

I want to confirm the differences between request.setAttribute(key,
value) versus session.setAttribute(key, value).

My understanding is that request.setAttribute only make the key
available in the following jsp page. But session.setAttribute will
make the key available in many pages, as long as in the same session,
and browser not close.

For example, the flow like page1->page2->page3->page4.
session.setAttribute will make the key available in all pages. But if
we use request.setAttribute in page2, then only page3 can get the key
value set in page2.

Please advise if i miss something.
thanks!!

In short:

The attribute set by request.setAttribute(...) is available as long as the
request is executing:

From the request.setAttribute(...) call until the final response
of the request is written back to the browser. After that, the
attribute can no longer be retrieved.

(E.g. This means that the attribute set by request.setAttribute(...) can be
retrieved in other JSPs that are executed by 'forwards' (not by 'refers'!)
from the originating JSP/Servlet/etc.)

The attribute set by session.setAttribute(...) is available during the
entire user-session. The attribute and its value is written to a separate
storage (e.g. a browser-cookie, but there are many other ways to do that).
This storage is available during a series of requests, as long as the
session is valid (Session validation is another topic all together. Mostly,
the session becomes invalid (disappears) when you close the browser-window).

 

[johnangxun]

to: john C. Bollinger&q;

As Sudsy was pointing out, you also need to watch out
for caching behavior. User agents (generally browsers), > proxies, and

web servers all may cache responses under

certain circumstances. All may cause trouble, but the
most likely to do so are user agents. For instance,
when a human user clicks the *"Back"* button on his
browser's toolbar, he will generally get a cached
version of the previously visited page instead of
causing a new request to be issued for that page. This > may be

different from what he would get by reissuing the > same request by which
the cached page was originally

fetched.

Can u explain more about this. I not clear to it. Thanks.
Recently I deal with the form processing. I have one form, user will key
in a lot of the field. After human user finish key in, the enter the
submit, the *confirmation page* will display, which show all the data key
in by user. If human user need to change the information, their can click
*back* button to rekey in again.
But if I click the back button, all the information is the submit
form(first form) will lost.
So is it any way to solve it. If I use the session.setAttribute at the
submit form(first page) will it help?
Thanks in advance!

 

[John C. Bollinger]

to: john C. Bollinger&q;



web servers all may cache responses under


different from what he would get by reissuing the > same request by which
the cached page was originally



Can u explain more about this. I not clear to it. Thanks.

(*) User clicks hyperlink in page (1) displayed in browser window.

(*) Browser makes HTTP request for document associated with the link's URL

(*) Server prepares and sends a response, possibly changing session or
application state while so doing

(*) Browser renders the content of the HTTP response (page 2), and
caches a copy of it.

(*) User clicks a submit button or link in page 2

(*) Browser makes HTTP request for document associated with the link's
URL or the form's action

(*) Server prepares and sends a response, possibly changing session or
application state while so doing

(*) Browser renders the content of the HTTP response (page 3), and
caches a copy of it.

(*) User clicks his browser's "back" button

(*) Browser [maybe] displays page 2 _from cache_, exactly as it was
originally received. Depending on the application, this differ from the
result of a new request for page 2's URL.

Recently I deal with the form processing. I have one form, user will key
in a lot of the field. After human user finish key in, the enter the
submit, the *confirmation page* will display, which show all the data key
in by user. If human user need to change the information, their can click
*back* button to rekey in again.

No, they can't.

But if I click the back button, all the information is the submit
form(first form) will lost.

That's why they can't.

So is it any way to solve it. If I use the session.setAttribute at the
submit form(first page) will it help?

Surely it depends on what attribute you set to what value, when, and on
how your application thereafter uses the the attribute.

If you want to provide a robust means for the user to update data they
already submitted to the server then it must operate by means of the
user sending a _new HTTP request_, not by their use of the browser's
"back" button. The user's current responses must be remembered in some
way; this could be in one or more session attributes or in the
confirmation page itself. The data entry page would be populated (on
the server side) with whatever remembered information the server has to
work with. This is all very high level. The details of how you might
accomplish such behavior are quite varied.


John Bollinger
(e-mail address removed)