As I am also using JSP's you get other problems such as
'InvalidStateExceptions' cropping up when the various threads try to
output their results. All attempts to block the request stream at the
server are useless, as the happy-clicker can click many times before
the server comes in to play due to the slow nature of the internet
connection.
I have however solved the problem where it was created, i.e. at the
browser. Between <HEAD> and <TITLE> add...
<!-- Next line ensures that JavaScript is used -->
<NOSCRIPT><meta http-equiv="refresh" content="0;
url=/IsJavaScriptEnabledNO.html"> </NOSCRIPT>
<!-- And here is the simple solution -->
<script language="JavaScript"><!--
var fts=0; // First time switch to stop multiple clicks
function doSubmit() {
fts++;
if (fts == 1) return true;
else {
alert("You only need to click once!");
return false;
}
}
//-->
</script>
in the HTML you just need to add the 'onSubmit' directive:
<form action="/servlet/myServlet" method="POST" onSubmit="return
doSubmit()">
This seems to work fine in IE5, Netscape, Mozilla and Opera.
Enjoy!
John Muir
On Sat, 16 Dec 2000 18:12:44 +0100, John Muir <john...@t-online.de>
wrote:
>This problem is driving me nuts!
>
>When a browser user double-clicks (instead of 'single clicking') the
>servlet gets started twice and both threads are active and doing their
>job.
>
>This could mean that e.g. a quantity gets incremented twice (or more
>if the user did multiple clicks).
>
>Does anyone know of a general way to handle this problem?
>
>Flushing the output stream doesn't help if the connection is slow as
>the second thread is started before the request stream is blocked.
>
>In normal GUI programming on the first click you can disable the
>button, but with browsers I could also be using an image to submit the
>form so JavaScript solution won't help much (I think).
>
>Any help greatly appreciated!
>
>John Muir
> Thanks to all who replied, but trying to solve this one on the server
> is almost impossible. Whatever you do, the initial thread(s) started
> by the first click is going to run to the end but the browser has
> already 'given it up for dead' so it ends up in the the big blue NULL
> in the sky. You can also have the problem that several threads can be
> 'racing' trying to handle the separate clicks unaware of the others.
Something like a unique constraint in a relational database would keep
data from going in twice. But the exact right solution depends on what
is/isn't exected user behavior. Might the user submit the form twice in
the same day with the same information? Is there a length of time over
which the user should never submit the form twice at all? More detail
about the app would be helpful.
Contrary to previous advice, a solution that makes it easy to break the
back button is not the right solution. It's just that when all you have
is session objects, everything looks like the user's thumb.
--
Bruce R. Lewis http://brl.sourceforge.net/