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
