3rd Repost
-----Original Message-----
From: Andre Vanha
Sent: Monday, August 13, 2001 6:27 PM
To: 'Orion-Interest'
Subject: RE: When user hits STOP..any way to trap that and terminate an
ongoin g request..
Hi Kevin,
although as you describe there isn't any way to notify the server when a
user hit's the stop button, I thought of a possible solution.
Since the only indication of an aborted request is a closed connection there
must be a way to monitor for this event.
You mention you use a transition page, which could be used to implement
this.
Theoretically it could be done like this:
A user submits a large query to your server. Your server sends back the
transition page, but not all of it. On the server the query is dispatched
and processing starts. Either your query process could periodically make
calls to some sort of update method, or your query process could be spawned
in a new thread, and the servlet thread would periodically check the status
of the query thread. Whenever the "isAlive" check would occurr you could
attempt to send something to the client browser. If you receive an error
during the send process, you can assume the user has either pressed the stop
button, or navigated to a different page, and kill your query processing.
If the query completes successfully while the user is waiting, you can
either send the results directly, or send a redirect to a page where the
results can be viewed.
There are several things you could send to the client browser during your
"isAlive" check. For simplicity, you could send dots ".". If your query
job supports it, you could send progress updates "10% Complete....<BR>", 20%
Complete....<BR> etc...
For fancy effects, you could send javascript that could swap an image on the
page to simualte a graphical progress bar or some other effect.
This solution will impose more overhead on the server, since response
caching would have to be turned off, and there might be other issues, but
it might do what you need.
Andre
-----Original Message-----
From: Duffey, Kevin [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 13, 2001 2: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.
