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]



Reply via email to