On Wed, 15 Nov 2000, Duffey, Kevin wrote:
> 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.
>
<snipped>
I think your proposed solution seems kinda kludgy (either that, or I'm a
bit slow and don't fully understand it...) also as you said it only tracks
two references, and can be foiled by starting 2 long running searches,
aborting them, then doing a quick third one.
You don't need to keep track of each request, you just need to provide
very basic tagging of results so they can be verified against requests.
A slight variant: Instead of passing in the timestamp have the bean return
one as part of the result, which you could then sanity check to ensure
that the timestamp in the session is before the time the search bean
thinks it started. If you get a mismatch, then discard the results as
they're stale.
This does leave a race condition, where the critical section is in between
placing the timestamp in the session and the search bean creating its own
timestamp, you can minimise this by synchronising your code up to (but not
including!) calling the search bean, and creating the 'result' timestamp
first thing in the search bean method.
> >
> > 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.
> >
