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
RE: Client hits STOP button..is there a way to detect this before sending a response?
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
RE: Client hits STOP button..is there a way to detect this before sending a response?
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.
RE: Client hits STOP button..is there a way to detect this before sending a response?
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.
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
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 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
RE: Client hits STOP button..is there a way to detect this before sending a response?
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?
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 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
