Or you can fake it like most of the web sites do and pop up a window with an animated gif file in the onsubmit event handler of the <form> and close the window in the onunload event handler of the <body> tag. That way it pop's up and stays there until the response is ready to be processed by the browser, then goes away by itself. It's a totally client side solution that takes no cycles on the server side. (*Chris*)
-----Original Message----- From: A mailing list for discussion about Sun Microsystem's Java Servlet API Technology. [mailto:[EMAIL PROTECTED] On Behalf Of Paul Copeland Sent: Sunday, October 10, 2004 11:09 am To: [EMAIL PROTECTED] Subject: Re: [SERVLET-INTEREST] (New subscriber) "Busy Page" So your example boils down to a proposal to close the Response output stream before the servlet service() routine returns. I expected that was what you meant, but thought there might be more to it. It may be this only works if there is no ServletResponseWrapper that might have modified the response stream. There might be other limitations, but I have not tested it. Some webserver-servlet container configurations may not actually close the HTTP response until the service routine returns. Again I haven't tested this, but the technique relies on the Response output stream being connected to the HTTP response stream. 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. - Paul > >Date: Sat, 9 Oct 2004 21:19:37 +0100 >From: Nic Ferrier <[EMAIL PROTECTED]> >Subject: Re: (New subscriber) "Busy Page" > >Paul Copeland <[EMAIL PROTECTED]> writes: > > > >>Nic - Can you be more specific about how you "batch away" the >>transaction? What thread is this transaction running in? JMS would make >>it asynchronous. You imply some other mechanism would also work. What >>would that be? >> >> > >Sure. The thread servicing the request can be used. > >Here is a specific example: imagine we have a legacy call logging >system which has a SQL stored proc interface allowing you to: > >- create a call >- change a call's priority >- plus a bunch of other stuff (mark calls done, etc...) > >We're asked by the PHB to build a web interface that allows someone to >send a POST which creates a call of one of a number of different >prioritys. The current SQL proc create interface doesn't allow for >that so we're gonna have to join two operations together. > >The trouble is, the creation of the call is a very long process; it's >a foxpro database running on a 386 in a cupboard next to the loo: but >hey, it's legacy so we're not allowed to change it. > > >So here's an almost complete example of a servlet's doPost: > >public void doPost (...) >{ > PrintWriter out = response.getWriter(); > response.setContentType("text/html"); > String caller = request.getParameter("caller"); > String problem = request.getParameter("problem"); > String priority = request.getParameter("priority"); > > HttpSession session = request.getSession(); > Hashtable callDetails = new Hashtable(); > session.setAttribute("caller", callDetails); > > String checkUrl = request.getServletPath(); > out.println("<html><body><a href='" + checkUrl + "'>"); > out.println("Check the call here"); > out.println("</a></body></html>"); > // The client sees a completed page from here > out.close(); > > try { > Connection con = conPool.getConnection(); > CallableStatement create > = con.prepareCall("{ ? = call call_make ( ?, ? ) }"); > create.setString(2, caller); > create.setString(3, problem); > create.execute(); > String callId = create.getString(1); > > // Update the record > callDetails.put(callId, ""); > > CallableStatement create > = con.prepareCall("{ call call_set_pri ( ?, ? ) }"); > create.setString(1, callId); > create.setString(2, priority); > create.execute(); > > callDetails.put(callId, priority); > } > catch (SQLException e) { > throw new AghException(e); > } > finally { > conPool.returnConnection(con); > } >} > > >So the thread servicing the request is used, after the response has >been finished, to do some important work. This only works if you've >understood and implemented the asynchronous nature of the web. > >btw this is the most misunderstood and least applied technique of web >programming. Most programmers just don't seem to understand that the >web is asynchronous and try to make it synchronous. The whole of EJB >can be seen as a misguided attempt to apply synchronicity to webapps. > >Once you accept that the web is async, and learn how to deal with it, >life gets much much easier. > >-- >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
