Originally posted by Balaji Venkat: Hi, GET method is Idempotent and POST is not.
In case of GET, the data will be sent in the URL as query string. That's why, the data is stored in the database again & again, on refresh.
To avoid the problem, you can use POST method to send data.
I tried with post method also. In case of post method, the only difference I felt is, browser ask user to send information again or cancel the refresh action.... but if user click on retry then the same thing happens...
I'm a big fan of the PRG pattern linked above. That's a very good article about it. It avoids the browser warning that it must resubmit to display a page, avoids accidental duplicate updates, allows bookmarking, and comes closer to the REST architecture definitions of GET and POST. It's all good.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
You may also consider the Synchronizer Token design pattern. It is a general solution to avoid duplicated submission. Essentially, you just create a new unique token for the form as a hidden field. And your form processing servlet check to ensure the submitted token is the one your are expecting. Check the book Core J2EE Patterns for details.
R u displaying any resultant page after submitting the values??
If you are displaying the result in other page, it leads to the problem. Do one thing , submit the values and redirect the result to result page. Even u refresh the page the data wont be submitted. Only result page will be refreshed. I had the same problem before, but got out of it.
Try this once.
Always do what you are afraid to do..
cheers<br /> <br />mohan.<br /> <br /><br />Always do what you are afraid to do...
Mohan Reddy, JavaRanch is a community of people from all over the world, many of who are not native English speakers. While using abbreviations like "u" instead of spelling out "you" is convenient when text messaging your friends on a cell phone or in a chat room, it presents an extra challenge to those that are already struggling with English. Additionally, such shortcuts may confound automated translation tools that patrons of the Ranch may be making use of.
I would like to ask for your help in making the content of JavaRanch a little easier to read for everybody that visits here by not using such abbreviations.