Zerbe John W <[EMAIL PROTECTED]> writes: > My preference would be to send a jms message to an MDB and return to > the browser with a page that does a meta-refresh to keep checking if > there is a "reply" message. This gets you out of the server so that > it can service other requests between "checks". Ultimately, it > should scale better than tying up the servlet thread for "long > running" operations. It also has the advantage that the mdb can > potentially be on another machine, again, for scalability.
I think you've got the basic idea right but over-complicated the picture. The web is an asynchronous medium. If you have a long transactional operation the thing you need to do is batch it away for completion and allow the user to poll the results of the transaction on a separate page. But JMS is a red herring. You can implement this pattern with just a doGet: - collect data from the request - setup a session and mark the session as having access to the transaction you're about to start - respond to the client with a page saying "click here to see the status of your transaction" - do your transaction - mark your transaction done (by setting the value on the session) Implement another doGet to return the state of the transaction. Of course, you can use JMS to batch away the transaction... but it's not necessary. -- 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
