Skip to content

Long running queries in servlets

The stateless nature of the web presents some user interface issues. Not least of these is how to handle long running processes most efficiently. Do you keep the user waiting, do you poll, etc? Remember, even if everything is going dandy, normal users like to see something.

This JavaRanch article is a good explication of how to use message driven beans and asynchronous access to data in the web tier to deal with these problems. It leans a bit heavily on WebSphere, but does seem to address some of Dion’s issues about there not being enough use of messaging systems. And it even throws a couple of design patterns in as well.

2 thoughts on “Long running queries in servlets

  1. Kris Thompson says:

    Inversoft’s framework has the feature for long running transactions. I don’t know how they do it but it has the feature.

    http://www.inversoft.com/products.html

    Since you know the author maybe you could ask him -;)

  2. Brian Pontarelli says:

    Yeah, long transaction support is the name of the solution available in the Verge framework from Inversoft. Before I get to it, I have to put in a disclaimer, this functionality is patented for certain circumstances. For example, if you want to display an ad to the user while they wait, you may need to pay royalties. Lame, I know, but some idiot patented this and the patent office accepted it. You can run google searchs for “interstitial patent” and find some leads on that front.

    Okay, here’s how it works:

    1. When a request comes into the Verge MVC, the first thing that is done is a server-side include of a JSP page. This page contains some nice HTML for the user to look at while their request is processing. This HTML is partial and does not contain the close HTML tag.
    2. Verge processes the request.
    3. Rather than forwarding or redirecting to the result JSP (which is impossible because the output stream to the client was flushed in step 1), Verge outputs another HEAD HTML section that contains a meta-refresh. The URL of this meta-refresh is the URL of the result JSP. This will cause the browser to reload the page and display the result.

    The HTML of the server-side include might look like this:

    <html>
    <head><title>Waiting is boring huh?<title><head>
    <body>
    Have a nice wait dude.
    <body>

    The HTML of the meta-refresh might look like this:

    <head><meta http-equiv=’REFRESH’ content=’0;url=/result.jsp’/><head>
    <html>

    Of course, this should be transparent to the application developer and probably configured using a configuration file. If you are using a framework such as Struts, I would suggest creating a base Action class that implements this type of functionality and all Actions that require it must extend from that. This will remove the messy-ness from the application code. If you need more complex handling such as multiple wait pages and chained Actions, I would suggest checking out the ActionFlow system of the Verge MVC.

    – Brian

Comments are closed.