Is it safe to manually start a new thread in Java EE?

Question

I could not find a definitive answer to whether it is safe to spawn threads within session-scoped JSF managed beans. The thread needs to call methods on the stateless EJB instance (that was dependency-injected to the managed bean).

The background is that we have a report that takes a long time to generate. This caused the HTTP request to time-out due to server settings we can't change. So the idea is to start a new thread and let it generate the report and to temporarily store it. In the meantime the JSF page shows a progress bar, polls the managed bean till the generation is complete and then makes a second request to download the stored report. This seems to work, but I would like to be sure what I'm doing is not a hack.

Answer 1

Check out EJB 3.1 @Asynchronous methods. This is exactly what they are for.

Small example that uses OpenEJB 4.0.0-SNAPSHOTs. Here we have a @Singleton bean with one method marked @Asynchronous. Every time that method is invoked by anyone, in this case your JSF managed bean, it will immediately return regardless of how long the method actually takes.

@Singleton public class JobProcessor {      @Asynchronous     @Lock(READ)     @AccessTimeout(-1)     public Future<String> addJob(String jobName) {          // Pretend this job takes a while         doSomeHeavyLifting();          // Return our result         return new AsyncResult<String>(jobName);     }      private void doSomeHeavyLifting() {         try {             Thread.sleep(SECONDS.toMillis(10));         } catch (InterruptedException e) {             Thread.interrupted();             throw new IllegalStateException(e);         }     } } 

Here's a little testcase that invokes that @Asynchronous method several times in a row.

Each invocation returns a Future object that essentially starts out empty and will later have its value filled in by the container when the related method call actually completes.

import javax.ejb.embeddable.EJBContainer; import javax.naming.Context; import java.util.concurrent.Future; import java.util.concurrent.TimeUnit;  public class JobProcessorTest extends TestCase {      public void test() throws Exception {          final Context context = EJBContainer.createEJBContainer().getContext();          final JobProcessor processor = (JobProcessor) context.lookup("java:global/async-methods/JobProcessor");          final long start = System.nanoTime();          // Queue up a bunch of work         final Future<String> red = processor.addJob("red");         final Future<String> orange = processor.addJob("orange");         final Future<String> yellow = processor.addJob("yellow");         final Future<String> green = processor.addJob("green");         final Future<String> blue = processor.addJob("blue");         final Future<String> violet = processor.addJob("violet");          // Wait for the result -- 1 minute worth of work         assertEquals("blue", blue.get());         assertEquals("orange", orange.get());         assertEquals("green", green.get());         assertEquals("red", red.get());         assertEquals("yellow", yellow.get());         assertEquals("violet", violet.get());          // How long did it take?         final long total = TimeUnit.NANOSECONDS.toSeconds(System.nanoTime() - start);          // Execution should be around 9 - 21 seconds         assertTrue("" + total, total > 9);         assertTrue("" + total, total < 21);     } } 

Example source code

Under the covers what makes this work is:

• The JobProcessor the caller sees is not actually an instance of JobProcessor. Rather it's a subclass or proxy that has all the methods overridden. Methods that are supposed to be asynchronous are handled differently.
• Calls to an asynchronous method simply result in a Runnable being created that wraps the method and parameters you gave. This runnable is given to an Executor which is simply a work queue attached to a thread pool.
• After adding the work to the queue, the proxied version of the method returns an implementation of Future that is linked to the Runnable which is now waiting on the queue.
• When the Runnable finally executes the method on the real JobProcessor instance, it will take the return value and set it into the Future making it available to the caller.

Important to note that the AsyncResult object the JobProcessor returns is not the same Future object the caller is holding. It would have been neat if the real JobProcessor could just return String and the caller's version of JobProcessor could return Future<String>, but we didn't see any way to do that without adding more complexity. So the AsyncResult is a simple wrapper object. The container will pull the String out, throw the AsyncResult away, then put the String in the real Future that the caller is holding.

To get progress along the way, simply pass a thread-safe object like AtomicInteger to the @Asynchronous method and have the bean code periodically update it with the percent complete.