• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JSP/FORM question

 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

My JSP has a form which collects request information.
The form has a SUBMIT button. Once user hits this
button, it calls a servlet, which in turn goes to
database to process information and output results.
Usually,it takes a while to for the servlet to do
the calculation. If, while the servlet is doing the
heavy calculation, the user hits the SUBMIT button
again, another request will be sent to the servlet
again, etc. If user keeps hitting the SUBMIT button
before the servlet ever returns the results, the
program could be in trouble, the servlet may be busy
fending off all the unnecessary & duplicate requests
from the user.
I need a way to get around this. I can think of two
general ways:
(1) make sure when the user hits the SUBMIT button once,
the button will be disabled so that he/she cannot
hit it again.
(2) alternatively, somehow in the servlet, don't process
repeat requests from the same source within a certain
period of time.
How can I implement any of the above two ways in JSP/SERVLET?
I would appreciate your comments and suggestions.
Sam
 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just tested it,you could do that with javascript. Call a function that will disable that submit button passing this.document as argument on the onclick argument.
That function will execute before the form is submitted.
HTH
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have used the javascript approach to disable the submit button in the past with poor results. The problem is that if the user hits the STOP button after submitting the form, they are now in limbo. They can not resubmit the form and will not receive the response to the previous submission. They basically have to close the browser and start over. It also does not prevent the user from hitting the REFRESH button and resubmitting the data.
To avoid the STOP button scenario, we provide a confirmation message when the submit button is clicked while a response is pending. The message tells the user that they have a submission pending and it would be prudent to wait for the response before resubmitting or else they may experience some unexpected results. This helps in situations where users get impatient and start clicking away. If a user really wants to continue they can.
We ofcourse had to then deal with the mutliple submissions in the servlet processing the requests. In our case this amounted to making the method which processes the request synchronized.
I also tried an approach like you mentioned where I only synchronized part of the request processing method. In the non-synchronzied section I tried to create a request queue of sorts so I could circumvent the bulk of the processing for any requests but the last which would obviouslly never receieve a response. I had limited success with this approach. I am not sure if I ran across a bug or what but it appeared to me that the threads for the queued requests were processed in random order and the parameters associated with the
corresponding requests were sometimes null. I performed this test on Weblogic 5.1. Maybe someday if I get a chance I will look into it again with WLS 6.1.
Hope this helps and is atleast partially intelligible.
Steve

 
Sam Zheng
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Confirmation is a nice way to try. But is there any way
to disable the SUBMIT button in JSP?
Also in servlet when there are many requests coming from
the same source in a short period of time, can we build
any intelligence in the servlet such that it only picks
up one request and discards the rest of them?
Any more comments from you Java Gurus?
Sam
 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another method you can try is to create a unique number every time the form is loaded. The first time the page is submitted capture the number. If subsequent requests have the same unique #, discard that request. Once the processing of the servlet is over, discard the unique number. Hope that helps
 
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This particular problem ranks right up there with the no-cache meta tags one.

I've thought about this a bit, but I don't know the first thing about DHTML, so perhaps my idea is not do-able.

Is it possible that you have the form and it's submit button on a (is it a layer or div?)... whatever it's called. Then in the onclick of the submit button you hide this layer and expose a new one which has a message "Thanks for submitting... processing" or whatever you want it to say.

The point is... once the user clicks the submit button, the button (and the form) completely disappears. So how can they click it again?

I suppose the same problem exists that they can click "Stop" and then "Back". But perhaps out of sight is out of mind.
 
Sam Zheng
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I guess giving the user a confirmation msg after clicking
is a practical way to discourage the user from clicking
the SUBMIT button again. This solves half of the problem,
but doesn't fix the situation when the crazy dude keeps
hitting reload/refresh button on the browser.
But my curiosity remains. This should be a very common
technical issue for most of the enterprise web application.
However, so far I have yet received any comments from
those experienced hands. Where are you, dudes?
My question is that if SUBMIT is a button, can't I simply
disable it after I click it once?
My other question is that if, from servlet point of view,
it keeps receiving tons of requests from the same source,
aren't there any easy way not to process any subsequent
requests coming within a certain time frame? Sound like
a way to fend off denial of service (DOS) attack. Session
tracking seems to be a likely solution, but I deem that to
be too cumbersome. I believe you guys know a better way
to do this, please share :-)
Finally, I check Yahoo to see if it does anything in its
log on page. To my surprise, no, it doesn't. After I type
my user name and password, if I hit the button "Sign In" once,
and again, and again, and again, and again, and again, it
keeps processing my request (I guess) without giving
me any response. The log in page finally shows up
after I stop clicking. Of course, the log on page in Yahoo
doesn't need to build in the capacity I talked about
before since it doesn't take much time to process
login authentication. But to me, that still reflects bad
programming.
Any suggestions and comments, people?
Andrew
 
Steve Snodgrass
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are quite a few ways to disable the submit functionality after the user clicks submit once.
1) Instead of using a submit button, use a regular button which calls a javascript function. This function submits the form, or if a flag has been set indicating the form was already submitted, does not submit the form.
2) Actually disabling the submit button is easier. Refer to
http://www.dynamicdrive.com/dynamicindex11/submitonce.htm
for the code.
As for the second part of your question, I posted a possible solution to this problem in some detail a while ago either on this board or on www.theserverside.com. It didn't get much attention which surprised as I too thought this issue would be more widely addressed. If you can find that post (search using my last name... it is pretty distinctive) it will describe a means whereby you can probably accomplish this. I am pretty sure my approach would work if not for the little quirks I stumbled across which could most likely be accounted for quite easily.
Good luck and if you find a good answer please post it.
Steve
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Guys,
You could try the HTTP_REFERER Server variable,
the has a reference to the previous page accessed by the user, if they have accessed a page, and then posted from that page
the current page and the referrer page will be identical,
so if you test the referrer page & if its the same then
don't process any further.
good luck,
Dave
 
Sam Zheng
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Hi Guys,
It seems the second alternative as proposed in my first message
is harder than it appears to be. This second alternative is
to build some intelligence into the servlet such that it
will not process repeat requests from the same source within
a certain period of time.
The difficulty lies in the fact that when you handle the
request to the servlet, the servlet will start to crank
out its engine without knowing what is happening at the
client side, even if thereafter the user clicks the stop
button on the netscape to abandon the request. Thus, if
the user clicks the submit button again, (to my understanding)
it is equivalent to pressing the stop button on the
netscape and press that SUBMIT button again. Here from
the client side, the output window for the previous is gone.
As a result, no matter what kind of output the servlet will
generate for the previous request, there will be no output
for the user. This dictates us that we should not discard
the new request, instead, if we want to build some kind of
intelligence in the servlet, we have to somehow keep the
new request alive and discard the old request, meaning to
find a way to stop the servlet from responding to the
previous request. THIS SEEMS TO BE DIFFICULT.
Again, I think this should be a very common problem
facing enterprise web developers and should have long
been resolved. Are there any java/web genius out
there who are willing to shed some light on this
issue? Thanks! Sam
 
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just for laughs, try this:
1. Open up SEVERAL browser windows, EACH with the request page in them.
2. Start clicking SUBMIT buttons.
If you can handle THIS, you're halfway there. And you need to be able to anyway, since there are people evil enough to do this just to see what sory of mayhem they can wreak.
Multiple submits are easy to do accidentally, though. People have been conditioned to double-click. If the interval is short, all that will happen is that the first submit will abort and the second one replaces it. IMHO the browser should lock all control processing once a posting starts and unlock when STOP is clicked, but this doesn't seem to be how it works.
 
reply
    Bookmark Topic Watch Topic
  • New Topic