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