People People! I think you should not try to use HTTP for things it is not meant to do. Like Mark mentioned before, the protocol is simply meant for a client request, followed by a server response.
If you want people to give a chance to overthink their decision, then first show a page with all information he/she has just submitted with a button asking the crucial question "Are you sure you want to do this?". If your audience is stupid enough to still click the button, while they don't want, than you might put a few more "Are you sure?" pages before actual submitting the form and store it in the database. .... or you might consider targetting a smarter audience (though dumb people might spend more money... ) Frans On 9 Oct 2002 at 8:15, Paul Copeland wrote: > The rollback suggestion seems like a naive understanding of database > commit semantics. If you respond to the client BEFORE doing the > sql/jdbc commit then you risk having a database failure that is not > reported to the client. If you respond to the client AFTER doing the > sql/jdbc commit (as you normally would) then you are back to the > original problem since you can't rollback a committed transaction. One > could play games with some sort of pseudo-two-phase sql commit, but > keeping jdbc/sql transactions open between requests is really digging > into a bigger nest of problems. > > BTW - This discussion about 2-tier and 3-tier application architecture > is entirely on-topic for Servlets. That's what its all about. > > -- Paul Copeland, JOT Object Technologies - http://www.jotobjects.com > > > ------------------------------ > > > > Date: Tue, 8 Oct 2002 06:33:59 -0400 > > From: "Galbreath, Mark" <[EMAIL PROTECTED]> > > Subject: Re: Clients that disconnect after inovking a servlet > > > > Me thinks you do not understand HTTP. And I'm not sure what you mean by the > > "'right way to handle it' as opposed to the Servlet specification." Is > > there a difference? > > > > Anyhoo, the standard method of not committing a confirmed transaction is > > called a "rollback" and it's available from both your JDBC driver and your > > database (I think even MySQL supports transactions now), but this has > > nothing to do with the Servlet specification. You need something like > > White, et al, "JDBC API Tutorial and Reference, 2d ed.," (Addison Wesley > > 1999). Although dated, it remains an invaluable desktop reference. > > > > Mark > > > > -----Original Message----- > > From: Neel Narayan [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 07, 2002 7:10 PM > > To: [EMAIL PROTECTED] > > Subject: Clients that disconnect after inovking a servlet > > > > > > What should be the servlet behavior when clients close the connection after > > invoking a servlet? I ask this question more from the perspective of the > > "right way to handle it" as opposed to the Servlet specification. > > > > Let's say a client has invoked a servlet that opens a DB transaction and > > then hits the stop button on the browser. This causes the connection to end. > > The user intent here is to prevent the transaction from happening - but the > > servlet of course does not know this and commits the transaction and will > > realize that the connection is broken when it's time to respond. > > > > How is this problem typically handled? Should I continuously check to see if > > the connection is alive? > > > > Please comment. > > > > Thanks, > > Neela > > ___________________________________________________________________________ > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff SERVLET-INTEREST". > > Archives: http://archives.java.sun.com/archives/servlet-interest.html > Resources: http://java.sun.com/products/servlet/external-resources.html > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
