RE: Client hits STOP button..is there a way to detect this before sending a response?

[Matt Krevs]

How about you have one hidden form field which is a unique key that
identifies the bean that should be used

Basically a user's session would have some sort of hashtable in it
containing a number of beans keyed by your hidden form field?

Then you dont have to send heaps of data around when doing multipage
transactions - just your 'transaction key' in the hidden form field.

I guess these beans in the hastable would somehow get garbage collected
after some interval.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Duffey
Sent: Thursday, 16 November 2000 3:01 PM
To: Orion-Interest
Subject: RE: Client hits STOP button..is there a way to detect this
before sending a response?


Thats a good approach to take for things like a "list" of items, such as a
search engine or a list of rows from a table. But what about when your
building up a single transaction, and you need to keep the state of several
pages across requests? While there is even less of a chance of what I am
asking about happening in that case..it could happen.

My worse fear is someone doing a DOS (Denial Of Service) on our
site..imagine 1000 virtual users, and possibly each having the same cookie
passed in so the server sees it as a single session.

You would think though..since when trying to return a response the
application server can throw an exception..there would be some way of
checking if the connection still exists before sending the response back.
That would solve this problem. :)

I did think about using request scope..I just wasn't sure how I could
maintain the other pages info across requests without sending large amounts
of data as part of the query string..and I don't want to use hidden form
fields.


> Quick answer - i dont know how to do an 'early detection' of the user
> pressing the stop button. I dont think its possibly - at least I
> dont think
> there is a non-super-difficult way of doing it.
>
> I think you may need to do more than just put your results bean in the
> session when providing a means to return results to the user.
>
> For example, what happens if both requests occur successfully

> ie the user
> has 2 browser windows open and does 2 successful searches). Seems
> as though
> whatever search finished first will have its results bean overwritten.
>
> In our project we almost exclusively use the request scope to put
> our beans
> in. When the user clicks the 'get me more button' we pass extra parameters
> that tell the server to get the next X rows.
>
> eg
> user clicks 'find' -> get me the first X rows where 
> user clicks 'more' -> get me the first X rows where primary key is > the
> primary key of the last row returned in the previous search.
>
> Basically then each search is independent of the last and you dont have to
> worry about cleaning up session beans, overwriting session beans etc.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin
> Sent: Thursday, 16 November 2000 8:42 AM
> To: Orion-Interest
> Subject: Client hits STOP button..is there a way to detect this before
> sending a response?
>
>
> Hi,
>
> I have a need to find out if the connection back to the browser from a
> servlet is still good or not, before an attempt to send the
> response occurs.
> Is this possible? I know when I do a response.sendRedirect() or
> requestDispatcher().forward() Orion will throw an exception if the
> connection to the browser (or client for that matter) has been terminated.
> The problem is..I want to check for this before an attempt is
> made, so that
> incase the connection is lost, I don't populate the javabean. I'll give a
> reason why this is necessary (and very helpful). I have my code organized
> into JSP pages, ControllerServlet/Action classs, JavaBeans and Session
> classes. Session classes are STATELESS classes, so that I can get ready to
> move to EJB when I get time. Each time a request is submitted, it
> goes to an
> action class method to be handled. The action class instantiates a new
> session class (I am not bothering with a pooled setup for session
> classes at
> this point as EJB will do this for me when I move to it). The
> session class
> performs some logic..usually database acitivty of some sort. The action
> class is then given a result (usually a Vector of some sort of
> objects). The
> action class then sets a bean variable to point to the vector of results.
> The bean is stateful and is session scope (HttpSession). At the end of the
> action, the response is forwarded to a JSP page. That page then uses the
> bean and its reference to results to display them.
>
> So here is the problem. If a 

RE: Client hits STOP button..is there a way to detect this before sending a response?

[Hani Suleiman]

On Wed, 15 Nov 2000, Kevin Duffey wrote:

> So in code it might look something like:
> 
> 
> {
>   SomeSession ss = new SomeSession();
>   SomeBean bean = getBean(); // gets the javabean used by jsp page
> 
>   Date date = new Date();
>   ss.setDate(date);
>   bean.setDate(date);
> 
>   ss.doLogic();
>   if(checkDate( ss.getDate(), bean.getDate()) )
>   {
> bean.setResults( ss.listAllResults() )
>   }
> }
> 
> 
> Is that good enough? 

Yep, except I'd say use new Long(System.currentTimeMillis()) instead of
new Date(). You don't need any date functionality, and Date objects are
notoriously heavy to create. Longs are more efficient in every way
compared to Dates.

> You said something about a race condition. I recall
> reading about this in my threading book, but I never was quite clear on it.
> My assumption is that it would be possible for two thread/requests to
> interrupt one another, thus in the middle of one thread checking the date,
> another one could be altering it, or something like that.
> 
Imagine this scenario:

Client request comes in on thread A
Servlet gets session (in thread A)
Servlet creates timestamp (thread A)
User hits stop, then does another query (assume it takes 0 time)
Client refresh request comes in on thread B
Servlet get session (in thread B)
Servlet creates timestamp, puts it in session (thread B)
Servlet puts timestamp in session (thread A)

Because of the way threading works, you're not guaranteed that they
execute in any given order. In the scenario above, if you don't
synchronise, the 'later' value might get clobbered with an incorrect
earlier one. Granted, this is VERY unlikely, and will probably happen one
in a million times, but the potential exists nevertheless.

Regarding your connection issues, I'd say look into your transactions! Two
minutes is an awfully long time. Also you should be closing them after
every transaction anyways. It doesn't really matter if the final
presentation layer gets to the client or not, when the transaction is
complete, the connection gets closed (in a finally block).

Hani

RE: Client hits STOP button..is there a way to detect this before sending a response?

[Kevin Duffey]

Thats a good approach to take for things like a "list" of items, such as a
search engine or a list of rows from a table. But what about when your
building up a single transaction, and you need to keep the state of several
pages across requests? While there is even less of a chance of what I am
asking about happening in that case..it could happen.

My worse fear is someone doing a DOS (Denial Of Service) on our
site..imagine 1000 virtual users, and possibly each having the same cookie
passed in so the server sees it as a single session.

You would think though..since when trying to return a response the
application server can throw an exception..there would be some way of
checking if the connection still exists before sending the response back.
That would solve this problem. :)

I did think about using request scope..I just wasn't sure how I could
maintain the other pages info across requests without sending large amounts
of data as part of the query string..and I don't want to use hidden form
fields.


> Quick answer - i dont know how to do an 'early detection' of the user
> pressing the stop button. I dont think its possibly - at least I
> dont think
> there is a non-super-difficult way of doing it.
>
> I think you may need to do more than just put your results bean in the
> session when providing a means to return results to the user.
>
> For example, what happens if both requests occur successfully

> ie the user
> has 2 browser windows open and does 2 successful searches). Seems
> as though
> whatever search finished first will have its results bean overwritten.
>
> In our project we almost exclusively use the request scope to put
> our beans
> in. When the user clicks the 'get me more button' we pass extra parameters
> that tell the server to get the next X rows.
>
> eg
> user clicks 'find' -> get me the first X rows where 
> user clicks 'more' -> get me the first X rows where primary key is > the
> primary key of the last row returned in the previous search.
>
> Basically then each search is independent of the last and you dont have to
> worry about cleaning up session beans, overwriting session beans etc.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin
> Sent: Thursday, 16 November 2000 8:42 AM
> To: Orion-Interest
> Subject: Client hits STOP button..is there a way to detect this before
> sending a response?
>
>
> Hi,
>
> I have a need to find out if the connection back to the browser from a
> servlet is still good or not, before an attempt to send the
> response occurs.
> Is this possible? I know when I do a response.sendRedirect() or
> requestDispatcher().forward() Orion will throw an exception if the
> connection to the browser (or client for that matter) has been terminated.
> The problem is..I want to check for this before an attempt is
> made, so that
> incase the connection is lost, I don't populate the javabean. I'll give a
> reason why this is necessary (and very helpful). I have my code organized
> into JSP pages, ControllerServlet/Action classs, JavaBeans and Session
> classes. Session classes are STATELESS classes, so that I can get ready to
> move to EJB when I get time. Each time a request is submitted, it
> goes to an
> action class method to be handled. The action class instantiates a new
> session class (I am not bothering with a pooled setup for session
> classes at
> this point as EJB will do this for me when I move to it). The
> session class
> performs some logic..usually database acitivty of some sort. The action
> class is then given a result (usually a Vector of some sort of
> objects). The
> action class then sets a bean variable to point to the vector of results.
> The bean is stateful and is session scope (HttpSession). At the end of the
> action, the response is forwarded to a JSP page. That page then uses the
> bean and its reference to results to display them.
>
> 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

RE: Client hits STOP button..is there a way to detect this before sending a response?

[Kevin Duffey]

Hi again,

Actually..I hashed out your first idea with two other guys and it seems like
it should work. Let me see if I got this straight.

1) When the action class is called..create a timestamp.
2) Create the stateless session class.
3) Get the javabean associated with the series of pages (session scope)
4) set the timestamp in the bean.
5) set the timestamp in the session.
6) do session logic.
7) check to see if the session timestamp and bean timestamp are the same.
8) if so, set the bean reference to the session return results
9) if not, ignore everything else...most likely the connection was lost
10) return jsp page

So in code it might look something like:


{
  SomeSession ss = new SomeSession();
  SomeBean bean = getBean(); // gets the javabean used by jsp page

  Date date = new Date();
  ss.setDate(date);
  bean.setDate(date);

  ss.doLogic();
  if(checkDate( ss.getDate(), bean.getDate()) )
  {
bean.setResults( ss.listAllResults() )
  }
}


Is that good enough? You said something about a race condition. I recall
reading about this in my threading book, but I never was quite clear on it.
My assumption is that it would be possible for two thread/requests to
interrupt one another, thus in the middle of one thread checking the date,
another one could be altering it, or something like that.

Here is why I don't think this would ever happen. First, because each bean
is tied to an HttpSession, on a per-client basis, it would be almost
impossible for a client to submit to the same method in the same action
class at the same time..much less at least seconds apart. It is possible
that the two sessions do different amounts of work..such as one searching
for everything, and one searching for a few items..with both ending up
finishing at the same time. In this case..what to do?

There is one other thing to think about though. By actually fixing this
problem, we introduce another one. By allowing a user to hit STOP on the
browser and submit the form again, each request (at least in our case) will
pull a connection from the connection pool. If you have one user that
submits, stops, submits, stops, etc..and possibly several sessions (not
http..but logic session classes) running on the server for just a single
user..its very possible we will run out of connections in the connectin pool
(our own home brewn class right now). We did add some code that will open
new connections, but until we move to EJB and have the container manage all
of this, it can get quite bad if too many requests from one user keep going.
Ofcourse, at some point the session/logic class thread will be done and the
connection will get returned.

However, my thinking is..a J2EE web app is like an application. The user
shouldn't be prevented from stopping a form right after its submitted..maybe
they see something they forgot, or some wrong info. If it was a desktop
application..they could stop it, change, and restart the transaction (unless
its using RMI or CORBA or something to talk to a logic tier of servers). So,
I think as a web-application, they should be able to do this too. If this
means we should have 1000 connections in the pool (hopefully not), then so
be it..but the end user should never be burdened because we simply only
allow them to do one transaction at a time. We did however allow them to do
one transactio per module on our site..meaning, if they were to send a fax,
and check for an invoice, each one is a separate module..so they could get
away with doing each one of those at the same time.

Anyways..I look forward to what you have to say about my understanding of
what you said in the first email reply, and see if I am on target with
implementing this.

Thanks again.



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

RE: Client hits STOP button..is there a way to detect this before sending a response?

[Hani Suleiman]

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


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

RE: Client hits STOP button..is there a way to detect this before sending a response?

[Duffey, Kevin]

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
&

RE: Client hits STOP button..is there a way to detect this before sending a response?

[Matt Krevs]

Quick answer - i dont know how to do an 'early detection' of the user
pressing the stop button. I dont think its possibly - at least I dont think
there is a non-super-difficult way of doing it.

I think you may need to do more than just put your results bean in the
session when providing a means to return results to the user.

For example, what happens if both requests occur successfully ( ie the user
has 2 browser windows open and does 2 successful searches). Seems as though
whatever search finished first will have its results bean overwritten.

In our project we almost exclusively use the request scope to put our beans
in. When the user clicks the 'get me more button' we pass extra parameters
that tell the server to get the next X rows.

eg
user clicks 'find' -> get me the first X rows where 
user clicks 'more' -> get me the first X rows where primary key is > the
primary key of the last row returned in the previous search.

Basically then each search is independent of the last and you dont have to
worry about cleaning up session beans, overwriting session beans etc.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin
Sent: Thursday, 16 November 2000 8:42 AM
To: Orion-Interest
Subject: Client hits STOP button..is there a way to detect this before
sending a response?


Hi,

I have a need to find out if the connection back to the browser from a
servlet is still good or not, before an attempt to send the response occurs.
Is this possible? I know when I do a response.sendRedirect() or
requestDispatcher().forward() Orion will throw an exception if the
connection to the browser (or client for that matter) has been terminated.
The problem is..I want to check for this before an attempt is made, so that
incase the connection is lost, I don't populate the javabean. I'll give a
reason why this is necessary (and very helpful). I have my code organized
into JSP pages, ControllerServlet/Action classs, JavaBeans and Session
classes. Session classes are STATELESS classes, so that I can get ready to
move to EJB when I get time. Each time a request is submitted, it goes to an
action class method to be handled. The action class instantiates a new
session class (I am not bothering with a pooled setup for session classes at
this point as EJB will do this for me when I move to it). The session class
performs some logic..usually database acitivty of some sort. The action
class is then given a result (usually a Vector of some sort of objects). The
action class then sets a bean variable to point to the vector of results.
The bean is stateful and is session scope (HttpSession). At the end of the
action, the response is forwarded to a JSP page. That page then uses the
bean and its reference to results to display them.

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.

So, what I am trying to do is find a way that if the connection is no longer
available BEFORE the bean is populated and anything else happens, it just
stops in its tracks. That way..if the user submitted another request, the
first one wont repopulate the bean with information that is inaccurate to
what the client is seeing.

Thanks for any ideas and info on this topic.

Re: Client hits STOP button..is there a way to detect this before sending a response?

[Hani Suleiman]

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

Re: Client hits STOP button..is there a way to detect this before sending a response?

[Boris Erukhimov]

"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