Well, in most cases, you are SOL. You have no possible way of finding out (under any current spec) that the client has hit the "stop" button except to try and write something back to the OutputStream and hope that you get an IOException in return (and even this is not guaranteed :).
Generally, you want to handle IOExceptions gracefully (and, in probably 90% of cases, this means simply declaring 'throws IOException' on relevant methods since you can't talk to the browser after this happens). "Tam, Michael" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi Eric, > > I do understand the Servlet is a request based ( new request -> new thread ) > and how to avoid this with session attribute .. etc. > > However, my concern was under the same request, if a client make a request > to (A), which passes to(B) and (B) passes to (C) and so on, then a client > could terminate the process by quitting the browser or "stop" the browser am > I correct? If so, my question would be how to avoid the client to interfere > the process after (A) is completed [If (A) is terminate before it is > complete, then the entire process should terminate and it is ok]? > > Regards, > Michael > > -----Original Message----- > From: Erik Price [mailto:[EMAIL PROTECTED] > Sent: Friday, March 21, 2003 12:31 PM > To: Tomcat Users List > Subject: Re: [OT] Servlet process issue > > > > > Tam, Michael wrote: > > Hi all, > > > > Sorry for the [OT]. Since many of you are the experts on servlet > > technology, I'd like to ask for suggestions or comments on the servlet > > process I am working on. > > > > Process: > > 1) I have a form html (A) to upload data files through an UploadServlet > (B) > > which stores the files in the file system. > > 2) Then (B) will forward the request to ValidationServlet (C) which reads > > the files for validation and generates log file. > > 3) Then (C) will forward the request to LoadServlet (D) which use the log > > file to load the clean data to DB. > > A servlet is a highly specialized kind of object that is specifically > designed to receive, process, and respond to requests. In the case of > HttpServlets, this would be HTTP requests. > > It seems that unless your ValidationServlet and LoadServlet are ever > going to be directly accessed with HTTP requests, they're probably > better off being written as regular Java classes (like Validator and > Loader). I do not know anything about the overhead incurred by making > them servlets, but it just seems that by subclassing HttpServlet for > these objects, at least for the use case you've described, you're > inheriting a lot more functionality than you'd ever need. > > This will also simplify the design question you're asking -- you don't > have to "backtrack" anywhere, your UploadServlet can just do whatever it > is you want to be done when the request processing is finished (dispatch > to a JSP saying "thank you"?). > > Note that when your HTTP request is sent to UploadServlet, UploadServlet > /is/ a new thread, so the user should not be able to interfere with this > process. If the user tries clicking "Submit" again, a totally new > UploadServlet will respond. If you wish to disable this ability, there > is a technique involving the setting of a flag in the user's session > that prevents any further requests being received until the processing > is done. But you have to implement this yourself. The whole technique > is detailed at > <http://developer.java.sun.com/developer/EJTechTips/2003/tt0114.html#2> > > > HTH, > > Erik > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
