I thought I said what you said in terms of it being a problem. If you prevent the user from submitting the form again, they have to wait for that first query to finish..and being that the connection to the browser is terminated from that first query, there is never a way for the user to know other than trying to wait and submit again. This is why I don't like it. However, what I don't like even more is the ability for a user to submit, stop, submit, stop and so on. It can easily consume all of our resources from connections and so on. What you said Struts did sounds fine, but I am not sure how what they did is much different than what I am proposing. If you prevent a user from resubmitting the same form, how is that any different than what I proposed, which is set a flag in the session on a per module basis. Per module would be almost the same thing as per form, and infact I like the per form method better. My method would prevent a user from say..submitting a form, hitting stop, going back two pages and changing something then submitting again. They would still be in the same module. The per form method at least blocks them from resubmitting the same form twice. What you didn't explain though..is if the Struts method prevents them from submitting the same form again until the original submission is done? This is much the same problem my method comes across...being that the connection to the browser is gone when they hit stop, the user will never know when the first request they sent is done, so the only thing they can do is try submitting the form until it finally takes. Now, perhaps what you meant is that Struts prevents the user from submitting the same form while on the same page..but if the user hits back, then forward, the "hidden" field of the form is gone and now they can submit the form again? Thanks for the reply. > -----Original Message----- > From: Aaron Tavistock [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 13, 2001 5:50 PM > To: Orion-Interest > Subject: RE: When user hits STOP..any way to trap that and > terminate an > on goin g request.. > > > This is a fairly classic web issue and unfortunately there is > simply no way > to tell if the client has hit the stop button. No matter > what happens your > going to be stuck running that long query no way out... > > But on the resubmit issue and using the session to flag a > large transaction, > I would worry about this alot. For one, what if the user > really didn't want > that massive query, now they are being penalized until their query is > completed. > > Personally I think the Jakarta Struts folks came up with a > fairly decent way > of curbing reposters. Basically they add a hidden field to > every form with > a unique token, that token is recorded when the form is submitted, and > thereafter the same form will not be accepted. So the user > can't just hit > back and then OK, but they can go through the normal route to > search again. > > > > > -----Original Message----- > From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 13, 2001 1:23 PM > To: Orion-Interest > Subject: When user hits STOP..any way to trap that and > terminate an ongoin g > request.. > > > Hi al, > > I am almost positive the answer is no, but I thought I'd see > if anyone has > come up with a solution. All too often, we have some users > that submit a > large query, then hit the STOP button on the browser, then > change something > and submit again. In the meantime, their original query is > still executing > on the server-side. Sure..Orion throws an exception when it > tries to send > the response back and the connection to the browser is gone. But I am > wondering if there is any way at all to just kill that > particular request. > Like..is there some way the app server or web server can send > pings every > say, 100ms to the browser to make sure its connection is > still alive..and if > not, just kill the request in some manner. Perhaps by having a special > interface that an application can implement, so that a > particular method can > be called if the server detects that the connection to the > browser is dead > before the response has gone back. In this way, that method > call can get > ahold of the session, and perhaps get ahold of a connection > being used, > close it, etc. > > Ofcourse, you can use some client-side javascript to > "disable" a button > after its been clicked. We have done this, and we also inserted a > "transition" page in particular areas where long queries > might occur. In > this case, the user sees an animated gif and a message that > tells them not > to hit stop or back. Ofcourse..you're still going to get > those users that do > this. My personal opinion is that if they call in, we tell > them they are > stupid, they should unplug their computer and quit their job > because they > can't follow instructions. Ofcourse..that wont fly, > especially if they are a > big money client. Besides, its ethically wrong to screw your > clients over. > ;) > > So, one possible idea I have had is to do the following. Each > user has a > session when they log in. Upon any request, a "flag" is set > in the session > of that user, indicating a transaction is starting. If the > user hits STOP, > then submits while that transaction is still going on, the > server will see > the flag is set, and send back a response indicating that a > transaction is > currently happening and they have to wait for it to be done > before another > submit can occur. There is a plus side to this..it prevents > any user to > doing more than one thing. The down side is, it is possible > using the File > -> New -> Window to open up another window with the same > cookie/sessionID > and the user could actually go to a different module and do > MORE work at the > same time. This would allow, for example a large query to be > performing in > one module and they could go do some work in another module. > My method of a > flag would prevent this type of multiple-module capability. > The solution, > ofcourse is to allow one flag per module, thus only one > transaction per > module could be performed, which is what I intend to > implement to at least > keep the user experience at a satisfactory level while > preventing tons of > form submissions from inundating the server. > > So anyone had this experience and resolve it in some manner? > > Thanks. >
