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
>
>
>
>
>
>
