Ralph Johnston wrote:
We're trying to prevent redirecting to a page that we don't want the user to go to.
Granted, they might learn after they get the exception page a couple of times and
stop doing multiple submissions, that just isn't a very user friendly way of handling
this issue.
What we need to do is find a way to stave off or queue up other page
renders (and ignore them) that might follow the initial call of one of the listener
methods we're trying to prevent multiple submissions of. The synchronization
solution seems to be the best bet but will this prevent a rerender of the page if other
multiple submissions, which would we would return from, occur? Flow synchronizer
looks to be really good but I like stated, redirecting to an exception page generally is
bad user friendly design.
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
You appear to have a little confusion as to how the web works. If the
user clicks submit a second time, before the first submit has returned,
the browser will close its end of the connection to the server for the
1st submit, and open a new connection. However the server will not know
this and will merrily carry on processing the first submit request, and
also start on the second submit request. When the server finally
finishes processing the first submit request, it will try to write the
result (the real result that you want) back down a closed connection,
and therefore loses it. The second request when finished will be the
actual result returned back to the browser, since its connection is the
one that is open. Note that the second request could theoretically
finish before the first request!
So, what you could do to protect against this accidental double submit,
is separate the processing of the request from the returning of the
resulting page. Then by using the unique token in the form pattern, you
can detect a double submit. A rough flow would be:
1. Page with form is requested. Generate a unique token hidden on the form.
2. Form listener request comes in with unique token.
3. Form Listener, synchronizing on some shared object, such as your
Visit object, immediately checks to see if the unique token has already
been processed.
If so, it looks up the result (waiting for the result - using a
semaphore perhaps) of that processing and renders the response.
If not, it notes that the unique token is being processed, and then
starts processing (such as adding the data from the form into the database).
When the processing has finished, it notes that the unique token has
finished, and stores any required result. It then renders the response.
On a multiple submit scenario - all the submits will send the same
unique token. The very first one will cause the form processing to
happen, and all the rest will wait until the processing has finished
before attempting to send back the resulting response. Only the last
submit will actually send a response that the browser will see, since
all the previous connections will be closed by the browser!
Hope this helps
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
