"Wang, Dapeng" wrote:
> Hi,
>
> sorry for the belated response. I'm facing the same problem in the
> development. I am aware that a HTTP redirect requires one extra round trip
> to client, but RequestDispatcher.forward or jsp:forward may bring problems
> with browser reload. If a user fills in a form and pushes submit, one record
> (e.g an order item) will be inserted in the database by a servlet or a jsp,
> and the request is forwarded to another JSP(e.g. to show the order). At that
> moment if the browser reload button is pressed, the formeer servlet or JSP
> will be invoked again, which tries to insert the same record again in the
> database. So I think HTTP redirect should be used to prevent such duplicate
> data problem. Any comment?
>
If you set your HTTP headers appropriately so that the original page is not
cached by the browser, the second submit won't be able to happen. How to do
this has been discussed extensively on both the JSP-INTEREST and
SERVLET-INTEREST lists Alternatively (or in addition), you can record
information in the user's session that indicates "when a request comes in that
looks like this, reject it because we have already processed that one." A
simple way to do this would be to include a serial number of some sort in a
hidden form field.
To see why you really don't want to use sendRedirect(), try your app --
designed both ways -- from home on a crappy modem connection, and see how
visible the performance difference is. Now, imagine that your user has to
suffer that difference every time they submit a form. How happy are they going
to be that you used sendRedirect() instead of coding your app so that Reload
does not cause a problem?
>
> regards
> Dapeng
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
