Yes, I think this is what does in fact happen... BUT there must be a
serverside method for handling this, since this is potentially very
destructive if two requests come in to "subtract $10 from account xyz".....
I was thinking that the session would contain a sequence number embedded in
the HTML, which would be returned to the server, and then would be "locked".
So if two near simultaneous requests came in with sequence number 123, the
first request would be set to "locked" in the session and then processed.
Meanwhile the second request would come in and see that the sequence number
123 is "locked" or that the sequence number is no longer valid (having been
processed). BUT I am not sure what to do with the second request. The client
browser is expecting a request. In fact, the first request will not be
displayed by the client.....
What I think is missing, is a method for determining that a client did in
fact receive and display the results of a given session transaction.....
Keith
----- Original Message -----
From: "M Sankar" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 30, 2001 9:26 PM
Subject: Re: Double submit
> I got it now. The moment U click on the second link the browser discards
the first
> link response. So the second link response is shown. It is not on the
server side.
> But browser handles it.
>
>
>
> Erwin wrote:
>
> > Thanks, but I think you misunderstood my question.
> > I Don't intend to create new threads. But I was wondering whether the
> > browser or the server creates a new thread or the equivalent of one.
> > We know that whenever a user clicks 2 links in succession, only the
> > response of the second link is displayed on the browser. But why is
this?
> > Where is it handled?
> > Does the *browser* accept both the responses & choose to display only
the
> > second one? Or does the *server* choose to send only the second
response?
> > Or is it worse, and does the server halt the first request when the
second
> > request arrives (but that would mean inconsistent data)?
> >
> > Life is easiest for us server-side programmers if the browser handles
it.
> > But does it?
> >
> > I hope I made some sense this time. Anybody knows the solution?
> > Thanks,
> > Erwin
> >
> > At 04:05 PM 4/30/01 +0400, you wrote:
> > >Nothing happens to the old request. If U r starting a thread to send
> > >communication
> > >to the server, the second thread also would be initialised on second
> > >click. Then
> > >two processes will run parallely. But this is not a commendable coding
> > >solution.
> > >
> > >Erwin wrote:
> > >
> > > > Hi,
> > > >
> > > > Just a simple question. What happens when a user clicks a button (or
a
> > > > link) and then clicks again before the response arrives? Is the old
request
> > > > stopped dead in its tracks? Do the two requests run in parallel on
the
> > > > server? If the old request starts sending its response, is the rest
of it
> > > > discarded?
> > > >
> > > > Basically, how much does this affect server-side programming?
> > > >
> > > > thx
> > > > Erwin
> > > >
> > > >
===========================================================================
> > > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> > > JSP-INTEREST".
> > > > For digest: mailto [EMAIL PROTECTED] with body: "set
JSP-INTEREST
> > > DIGEST".
> > > > Some relevant FAQs on JSP/Servlets can be found at:
> > > >
> > > > http://java.sun.com/products/jsp/faq.html
> > > > http://www.esperanto.org.nz/jsp/jspfaq.html
> > > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
> > >
> >
>===========================================================================
> > >To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> > >JSP-INTEREST".
> > >For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
DIGEST".
> > >Some relevant FAQs on JSP/Servlets can be found at:
> > >
> > > http://java.sun.com/products/jsp/faq.html
> > > http://www.esperanto.org.nz/jsp/jspfaq.html
> > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
> >
> >
===========================================================================
> > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
> > For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
DIGEST".
> > Some relevant FAQs on JSP/Servlets can be found at:
> >
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
>
===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
> For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
DIGEST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
