Keith,
> Date: Wed, 16 May 2001 17:13:15 -0700
> From: Keith Kwiatek <[EMAIL PROTECTED]>
> Subject: Re: Double submit
>
> 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
I think it's the locking and not the sequence numbering that is key.
Here's an (untested) idea.
The first request sets a lock in the session and commences doing
whatever state change it's trying to do. The second one then
sees the lock and blocks. It either polls the session, waiting for
the lock to clear, or maybe you could work out something with
HttpSessionBindingEvent to have it be notified when the lock clears.
The first request completes the state change and clears the lock and
redirects to the appropriate JSP depending upon what happened. This
one never gets seen by the client. But the second request unblocks,
skips the action, looks at the state (results of the first request)
and redirects to the appropriate page.
The sequence numbering becomes necessary when you want to keep
the operation from happening twice if the user does a "reload"
on the result page.
This makes a lot more sense and is easier to implement if all of
your state-changing operations are in servlets and all of your displays
are in JSPs.
Robert Merrill
Software Engineer
Berbee
5520 Research Park Drive Madison, WI 53711
[EMAIL PROTECTED]
608.298.1036 Fax 608.278.8539
Berbee...putting the E in business
===========================================================================
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
