 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2006Preventing duplicate form submission
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. >Hi, > [quoted text clipped - 27 lines] >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. >> I have a Java/JavaScript GUI application where I perform a lot of long DB >> operations [quoted text clipped - 5 lines] >> 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. Arne >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 ? Design your app rationally. There's no technological pixie dust that fixes a bad design. -- Mark Rafn dagon@dagon.net <http://www.dagon.net/> > 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. - Second one has slightly less work to do, without UUIDs. - First one might be more extendible in the security aspect. /Lew > 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. Some open-source products to help you get there: ActiveMQ for the JMS bit: http://www.activemq.org/site/home.html Or take the plunge into using the MULE ESB container if you want to automate as much as possible of the work: http://mule.mulesource.org/wiki/display/MULE/Home (f-u set to clj.programmer) > Hi, > [quoted text clipped - 7 lines] > 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. - Lew Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.