"High volume Web sites often require asynchronous or threaded operations to achieve target performance criteria. While threads in Web containers are considered bad practice, the alternative is for developers to make blocking calls to code they cannot control. It becomes important that dependencies of this nature fail-fast."

For the full article, please visit : http://www-106.ibm.com/developerworks/web/library/wa-shortcir

In a web app, spawning a thread for every request (beyond the thread the container created for the request) seems like a real bad idea. It may guarantee no user has to wait for a response too long, but it may also cause more requests to fail than otherwise would.

For new ideas, I'd prefer to look in the direction of using fewer threads, as in SEDA, and staging patterns.

"make blocking calls to code they cannot control"

I think this is what JMS is good at. If the time of request execution is not known and potentially very long, submit request for processing in the queue. This approach requires indeed some additional development to treat timeouts gracefully as well as to manage state of user session.

At least 100% J2EE compatible, no threads, no blocks. Also it seems like exactly what happens when you use flight reservation system e.g. to check availability and a huge mainframe is queried somewhere behind the scenes.

High volume Web sites often require asynchronous or threaded operations to achieve target performance criteria

So does high volume enterprise application. Alas, no such pattern is even allowed by the EJB standard.

Bummer.

How does this pattern behave if "br.readLine()" encounters a network contention situation? Or maybe a CPU overload? I don't think it will work as expected.

This pattern can be applied only where the calls are made to code that you CAN control. Elsewhere, ony real time VMs are appropiate.

Regards,
Horia

I have used this approach for a task that would use up to 10 threads. However, this was not in a J2EE application server. In my solution the threads also regularly updated a float (0.0 up to 1.0) to report progress. A continuously reloading page presented this as a percentage.

As the article says, you have to be very carefull when you use this approach; threads that lock up are not removed.

Java5 contains a lot of new interfaces for managing task/thread execution. Would be interesting to see how these relate.

I think one thing that would help is better (more complex, yet more flexible) library design. If you had an asynchronous library available to use and didn't have to spawn a thread, the time taken in your routine would be reduced to the amount of time of the longest asynchronous call. They could all be short-circuited in parallel using the pattern described here too, perhaps, but good libraries (especially for network calls) allow a timeout to be specified directly.

I know in the .NET world web services can be invoked asynchronously, and this is really useful. Never saw this feature in the Java Web Services libraries, but it might have been added since the last time I looked - it seems like a cinch to include.

Fortunately, with the 1.4 release of Java, solid asynchronous IO is available, but its use is not so extensive yet.

For the record, it IS fine to use threads that you spawn, if you follow some basic rules, mainly that you have to make bean method calls if you want managed access to container resouces. So you can have a thread that manages a bunch of async calls and invokes a bean method to handle the result.

WebSphere has full application controlled threading with the async beans features. A subset of this is now a standard in the commonj implementation which should be in the next versions of WebLogic and WebSphere.

Billy (IBM)