Nic - Thanks for your information on this. Sorry I called your example a proposal.
Below is text from the Servlet 2.4 spec. It appears that if you had called setContentLength that would have made your example work in the way you intended.
FYI - the Servlet API is part of Enterprise Java, not core Java. But I certainly don't find the distinction between Enterprise and Core Java to be very meaningful either way.
The scalability point I made is that in high volume websites it is considered best-practice (in many books and patterns on the subject) to not execute transaction processing inline in the servlet service thread. In addition to reducing the load on the servlet container, this kind of modularization (via EJB, RMI, JMS, etc.) provides flexibility in distributing the application. The technique in your example is perfectly adequate for performance in many cases of course.
Thanks again - Paul Copeland
- - - - - - - Servlet 2.4 Specification - - - - - - SRV.5.5 Closure of Response Object When a response is closed, the container must immediately flush all remaining content in the response buffer to the client. The following events indicate that the servlet has satisfied the request and that the response object is to be closed: • The termination of the service method of the servlet. • The amount of content specified in the setContentLength method of the response has been written to the response. • The sendError method is called. • The sendRedirect method is called.
Nic Ferrier wrote:
Paul Copeland <[EMAIL PROTECTED]> writes:
So your example boils down to a proposal to close the Response output stream before the servlet service() routine returns.
It's not a proposal. It's an example of an alternative to using JMS. And it's a perfectly valid example of how to do batching inside a container.
It is also an illustration of the logic flow for more complex systems, you could create a thread to process the job, or spawn another process. Maybe the call to the stored proc in my example is doing some message queueing of it's own.
The point is that the pattern is always the same.
It may be this only works if there is no ServletResponseWrapper that might have modified the response stream.
Certainly anthing hooking onto the post execution of the service won't run till the method completes (which it will eventually). This is a feature, not a bug.
Any filter altering the content output will still work. Study the way filters are done and you should see that.
Some webserver-servlet container configurations may not actually close the HTTP response until the service routine returns.
Software can always be incorrectly implemented. But the requirement is to close the response if the content length is written. Sending HTML in the way I did should cause that to happen.
Again I haven't tested this, but the technique relies on the Response output stream being connected to the HTTP response stream.
Err... yes. It does. It is.
If you need scalability you may still want a design that uses JMS or a message driven bean to offload the processing from the servlet container.
I think this is a meaningless statement. What do you mean scalability? JMS is not a blanket solution. It's one possibility, yes.
In short, I believe that you're making the quite common Java is Enterprise Java mistake.
___________________________________________________________________________ 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
