Interesting question. My instincts say you can't win as long
as your data integrity is determined by your ability to determine
the exact status when the situation is inherently a race condition.
That may be overly pessimistic given that it takes the client
a finite amount of time to stop one transaction and start the next,
but still, I'd try a different approach.
For instance, give each request a serial number, hold each
response in the session separately, and build the serial number
into the links of the output page. Then you know it will work,
but the overhead is minimal (you're assuming that this won't
happen often, so it's rare that you'll have multiple results
sitting in the session).
I haven't run into this problem yet, so I'm glad you pointed
it out ;)
Gary
Today, Duffey, Kevin ([EMAIL PROTECTED]) wrote:
> 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.
>
>
