Thanks for the reply..
Your idea has some merit..the only problem is, we have so many different
searches and profile updates that could be happening..I would need to keep
track of each of those separately.
Here is what I had in mind if there isn't any way to detect ahead of time
that a connection to the browser was terminted.
1) When stateless session class returns its Vector of objects, the action
class creates points a "second" pointer in the bean to the results that are
already there (unless they are null at that point). Then it assigns the main
results variable (defined as Vector results = null; in the bean) to the new
list of items. It then forwards to the page. But before it forwards, if the
connection was lost and it throws the exception, in the catch() block I
could just point the results reference back to the "second" pointer so it
doesn't lose that..in other words..because the 2nd pointer references the
old vector, the GC can't recollect it, thereby saving it..incase of a
problem. In the finally block, I would set this 2nd variable to null. It
should be safe to do it there..because the catch() block would execute
BEFORE the finally() block..incase the connection is lost..therefore it can
still assign the main results back to the 2nd variable reference before the
finally() block sets it to null.
Do you think this would work? My main worry is that of concurrency. What if
the user hits submit, stop, submit, stop, submit, stop, and so on..several
times (should never happen..most likely wont..but its still a
possibility..and I like to make sure we think about all
possibilities..especially these days where people purposely attack sites and
bring them to a halt). If that happens, there could be x number of
threads..all running at the same time. Thread 3 might finish before thread
1. Therefore, I am wondering if using only a 2nd reference variable will
really be enough, or if one thread finishes in between another thread (in
other words..the jvm switches to another running thread right in the middle
of one running), if the variables could get screwed up. I don't want to use
the Singleton model though.
> -----Original Message-----
> From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 15, 2000 3:49 PM
> To: Orion-Interest
> Subject: Re: Client hits STOP button..is there a way to detect this
> before sending a response?
>
>
> Here's another approach.
>
> Put a timestamp in your session to denote when a search request was
> started, and have the searcher object track this timestamp
> too. When you
> get the results back, check that the timestamps match before
> populating
> your bean. If another search had happened in the meantime, then the
> timestamps won't match, and so you can ensure that no
> mismatch happens.
>
> On Wed, 15 Nov 2000, Boris Erukhimov wrote:
>
> >
> >
> > "Duffey, Kevin" wrote:
> >
> > >
> > > So here is the problem. If a user submits a form (say..to
> search for all
> > > clients) and lets say that search will take two minutes.
> 10 seconds later,
> > > the client sees he/she made a mistake on what they were
> searching for. As if
> > > often the case..they hit STOP on the browser, change
> their mistake and
> > > submit the form again. On the server..there are now two threads
> > > running..because the first one hasn't completed yet
> (assuming the user
> > > submitted the form the 2nd time fairly quickly). The 2nd
> request is
> > > quick..it populates the javabean reference to a Vector of
> objects say in 20
> > > seconds. The response is sent back and the user sees a
> list of say 20 items.
> > > Now, while they are looking over this list, the 1st
> request they sent is
> > > still going on. At some point it too populates the SAME
> javabean with its
> > > results, which are now different than what the client is
> actually looking at
> > > on the page. The action tries to return its response but
> it finds its
> > > connection was terminated. It throws an exception (which
> I catch), and
> > > voila..the client sees nothing. Where the problem lies
> though..is when the
> > > first request populates the javabean that the 2nd request
> already populated.
> > > So when the user clicks on say item 3 of what he sees..it
> refers to item 3
> > > in the results Vector that has now been replaced with the
> first requests
> > > results. Therefore, the information is incorrect.
> > > Thanks for any ideas and info on this topic.
> >
> > I guess what you need is to implement what is called a
> "delayed response" to
> > avoid
> > make user waiting about 2 min.
> >
> > Here is a flow:
> > 1. User makes search or whatever request which is handled
> with delayed
> > response.
> > Your action or session class launches a separate thread
> to do the actual job
> > if
> > let's say an "in process" flag is set to "false" or
> not exist in your
> > HttpSession.
> > If thread is launched set that flag to "true". If not
> (meaning thread is
> > running) go to the step 2.
> >
> > 2. Your action class responds with JSP page saying "Please
> wait ....".
> > Put in the page a simple javascript code sending
> another request after some
> > timeout, say 8 sec.
> >
> > 3. Your action class process incoming request and checks if
> flag "in process" is
> > still on.
> > If yes it responds with the same "Please wait..." page
> which will schedule
> > another try in 8 sec.
> > If no, it responds with your result page populated by
> bean, which itself
> > uses result
> > data passed through HttpSession from completed job thread.
> >
> > Note that actual job is now almost untied from browser
> connection. If user hits
> > "Stop" and then decides to repeat search request still
> being within the same
> > HttpSession and his previously
> > launched job thread is not completed, he will receive
> "Please wait ..." page.
> >
> > Hope it helps
> > ~boris
> >
> >
> >
> >
> >
> >
>
