Question

Say, you are submitting a form, which affects your database (adding records/ deleting them/ updating them) and this is how your request looks like:

POST /application/action=update

Now, say, you are done with your update, so you would like to take the user to the home page.

Response.sendRedirect /application/action=home

This works wonderfully well. User is sent a redirect after POST, so even if the user tries to refresh the page by hitting F5, you are good. However, this will not work if you did this:

requestDispatcher.forward(/application/action=home)

Given that there is a scenario where you have to display different kinds of error / success messages after you are done with your update, you are most likely doing a forward after POST. In such a scenario, how do you avoid update actions from happening twice?

I find it rather amusing that many secure sites (banks) / payment gateways tend to inform the user by placing text on screen, such as “Please don’t press back / refresh buttons”.

Is there no better way to handling this? Other than requesting the user not to press these buttons? When I last checked, there was something called the ‘Vertical Response Cache’. A Filter that would identify uniqueness of your request in a session and tries to send a cached response if the request is duplicate. Are there any simpler ways to solving this classic problem?

Here is a link to the vertical response cache solution I was talking about: http://www.fingo.info/en/articles/_1.html. I am, However, not sure as to how well this really works.

Answer 1

One thought that I’ve had is to embed a unique ID (probably a random string) as a hidden form field in the form that is being POST-submitted. The ID string can be put in the database as a “transaction ID”. Now, when you go to update the database, first check whether there’s an existing record with the submitted transaction ID, and if so, assume it’s a duplicate and don’t change the database.

Of course, as I said, this is just a thought. I don’t know what methods are actually used in practice. (I suspect that a lot of less-critical sites just ignore the problem and hope their users will be smart… a losing proposition if I ever saw one 😉

EDIT: as pointed out in the comments, storing transaction IDs in the database might take up a lot of space, but if that’s an issue, you could keep an in-memory cache of all transaction IDs processed in the last 5 minutes/1 hour/1 day/whatever. That should work unless you’re up against a determined hacker…