You make it sound so simple..yet its not quite that easy. I do keep the
state of the user on the server, of course. But that still wont prevent the
user from stopping a query that could potentially take a long time, then
submitting again, while the original one is still going on. I would love for
you to explain to me what you mean, and how it works, because frankly your
reply was a little vague for me to come up with a resolution out of.
Thanks.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Magnus Rydin
> Sent: Wednesday, August 15, 2001 11:23 PM
> To: Orion-Interest
> Subject: SV: When user hits STOP..any way to trap that and terminate an
> ongoin g request..
>
>
> Just keep the users state server side and you're home.
> WR
>
> -----Ursprungligt meddelande-----
> Från: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]För Aaron Tavistock
> Skickat: den 14 augusti 2001 02:50
> Till: Orion-Interest
> Ämne: RE: When user hits STOP..any way to trap that and terminate an
> ongoin 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.
>
