Preventing duplicate form submission

I have a Java/JavaScript GUI application where I perform a lot of long DB
operations
[e.g. massive SQL Insert's], which takes 5-60 secs to perform.
Sometimes user double-clicks the button or just gets impatient and clicks
again,
which created duplicate forcm submission and hence duplicate records.
So I am trying to disable the button as soon as it is clicked, and as soon
as it's done,
re-enable it again.

I tried to do it in Javascript, just simple: <input... name=Save...
onclick="enabled=true;">
and as soon as screen refreshes, it re-enables the button automatically.
That works in some cases, however when I need to do some other Javascript
operation
(e.g. validate the fields on the screen), disabling the button automatically
stops both Javascript
and associated form action in Java which is totally unacceptable.

Is there any other simple solution to such problems in Java or Javascript ?
Maybe AJAX ?

Any help is very appreciate. Please provide a code sample or a pointer to
the resources.

Thank you in advance,
Oleg.
P.S.: It probably doesn't matter much, but that is a Cocoon2.0/XSLT app
with Actions in Java [servlet based], using JDK1.4.2 and IE6.

Advertisements

Advertisements

On Tue, 31 Oct 2006 04:31:26 GMT, "Oleg Konovalov"
<> wrote:
>Hi,
>
>I have a Java/JavaScript GUI application where I perform a lot of long DB
>operations
>[e.g. massive SQL Insert's], which takes 5-60 secs to perform.
>Sometimes user double-clicks the button or just gets impatient and clicks
>again,
>which created duplicate forcm submission and hence duplicate records.
>So I am trying to disable the button as soon as it is clicked, and as soon
>as it's done,
>re-enable it again.
>
>I tried to do it in Javascript, just simple: <input... name=Save...
>onclick="enabled=true;">
>and as soon as screen refreshes, it re-enables the button automatically.
>That works in some cases, however when I need to do some other Javascript
>operation
>(e.g. validate the fields on the screen), disabling the button automatically
>stops both Javascript
>and associated form action in Java which is totally unacceptable.
>
>Is there any other simple solution to such problems in Java or Javascript ?
>Maybe AJAX ?
>
>Any help is very appreciate. Please provide a code sample or a pointer to
>the resources.
>
>Thank you in advance,
>Oleg.
>P.S.: It probably doesn't matter much, but that is a Cocoon2.0/XSLT app
>with Actions in Java [servlet based], using JDK1.4.2 and IE6.
>

If you're able to submit multiple, duplicate records, the database
most likely does not have proper constraints set up. Good software
design practices do not rely on the GUI to prevent multiple
submissions.

Oleg Konovalov <> wrote:
>I have a Java/JavaScript GUI application where I perform a lot of long DB
>operations
>[e.g. massive SQL Insert's], which takes 5-60 secs to perform.

Don't do these synchronously. It's just mean to users, and a bad design. You
should use a background thread to do the inserts, and have a status page that
auto-refreshes (or uses AJAX if you're fancy) until the operation is complete.
>Sometimes user double-clicks the button or just gets impatient and clicks
>again, which created duplicate forcm submission and hence duplicate records.

Make your call idempotent. Include on the form a unique identifier (cf
java.util.UUID) that gets submitted along with the data, and the server
can simply ignore duplicate submissions.
>So I am trying to disable the button as soon as it is clicked, and as soon
>as it's done, re-enable it again.

Good. This is a nice backup to the above. But if you do it right, you
never need to re-enable it explicitly. The form submission disables it, and
the results page doesn't have the button on it. When the user wants to make
a new submission, they go to the submission page, where it's enabled because
it's a new load of the page.
>and as soon as screen refreshes, it re-enables the button automatically.

So don't do that. Don't refresh the page, go to a results page instead.
>That works in some cases, however when I need to do some other Javascript
>operation (e.g. validate the fields on the screen), disabling the button
>automatically stops both Javascript and associated form action in Java
>which is totally unacceptable.

What? I don't understand this requirement. If you're showing the user a
form, it is because you want them to submit it. If you don't want them to
submit it, don't show the form. Showing a form that you can validate but not
submit is lunacy.
>Is there any other simple solution to such problems in Java or Javascript ?
>Maybe AJAX ?

Gray Matter wrote:
> On Tue, 31 Oct 2006 04:31:26 GMT, "Oleg Konovalov"
> <> wrote:
>> I have a Java/JavaScript GUI application where I perform a lot of long DB
>> operations
>> [e.g. massive SQL Insert's], which takes 5-60 secs to perform.
>> Sometimes user double-clicks the button or just gets impatient and clicks
>> again,
>> which created duplicate forcm submission and hence duplicate records.
>> So I am trying to disable the button as soon as it is clicked, and as soon
>> as it's done,
>> re-enable it again.
> If you're able to submit multiple, duplicate records, the database
> most likely does not have proper constraints set up. Good software
> design practices do not rely on the GUI to prevent multiple
> submissions.

Not necesarrily.

Maybe not even likely.

Only INSERT where the business rules guarantee a field
mapped to user input to be unique should fall in that
category.

Mark Rafn wrote:
> Make your call idempotent. Include on the form a unique identifier (cf
> java.util.UUID) that gets submitted along with the data, and the server
> can simply ignore duplicate submissions.

I have seen variations on the token pattern in Web forms -

- The cited approach - a hidden field that keys the transaction. Presumably
the key is matched to a session token that is kept until the transaction
completes.

- A session token that is generated on page load and removed from the session
upon first submit; absent the token the transaction request is ignored. This
does not require unique token values.
session.setAttribute( "idempotency", SAME_VALUE_EVERY_TIME );

It surprised me when I first read of this pattern that the writer espoused the
latter variant.

I wonder of the advantages, disadvantages and gotchas of each approach.

IMHO:
- The second seems slightly more elegant, and idioms of void appeal to me
anyway. (Checking for absence, rather than checking for presence.) Checkng
for absence is slightly simpler than checking for equality.

"Oleg Konovalov" <> writes:
> I have a Java/JavaScript GUI application where I perform a lot of
> long DB operations [e.g. massive SQL Insert's], which takes 5-60
> secs to perform.

Look into optimizing that using JDBC batches.

As another poster suggested, return to the user immediately after
setting up the job in a different thread. However, since you're really
not supposed to fire off threads in app-server containers - even
servlet containers - it would be better to deliver the "job" to a JMS
queue and have some other app read from it and do the actual database
work.

Oleg Konovalov wrote:
> Hi,
>
> I have a Java/JavaScript GUI application where I perform a lot of long DB
> operations
> [e.g. massive SQL Insert's], which takes 5-60 secs to perform.
> Sometimes user double-clicks the button or just gets impatient and clicks
> again,
> which created duplicate forcm submission and hence duplicate records.
> So I am trying to disable the button as soon as it is clicked, and as soon
> as it's done,
> re-enable it again.

Trying to disable a browser control (back button, refresh) from the server is
wrong and fraught with difficulty.

Make your transactions idempotent and stop trying to screw up people's browsers.

Another poster already referred you to the Token pattern. It is a solution.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!