I thought I would add in the fact that JDK 1.5 adds in
java.util.concurrent.Executors and thread pools, which can be much more
efficient than creating many new Threads.
I don't think that for a simple case, there is a problem with
creating a busy page, and processing the request in the same VM. If
you find that you have problems with memory or thread exhaustion, then
you can refactor to a larger solution.
Nic Ferrier wrote:
Zerbe John W <[EMAIL PROTECTED]> writes:
My own background is that of a mainframe assembly language programmer on a
team of people who supported a "home grown" TP monitor that is much like
and predates IBM's CICS product. By the way, this TP monitor is still in use
today and can still perform well on a machine that is running at 99% cpu busy.
I guess that makes me a bit sensitive to how the applications use/abuse
the supporting infrastructure. After having spent years preaching to
application programmers how queueing theory works and getting transaction
response times measured in the milliseconds, I still find it difficult to
imagine building an application where 10+ second response times are
"acceptable".
10+ second response times are not acceptable. That is the whole point
of this thread!
As you rightly intimate, asychronous coding is the way round such
delays and that is what everyone in this thread has been talking
about.
Briefly the Java based suggestions to solve the problem have been:
- dispatch a new Thread from the servlet request handler method to do
the work and respond to the user with a "check status page"
- variation on the above: respond to the user with a "check status
page" but then continue using the servlet container's Thread to do
the actual work
- use JMS to queue the work to some other place
- call a db stored proc to do the same (though this presumes your DB
supports queuing... Oracle maybe?)
--
Nic Ferrier
http://www.tapsellferrier.co.uk
___________________________________________________________________________
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
|
