Is it safe to manually start a new thread in Java EE?
Solution 1
Introduction
Spawning threads from within a session scoped managed bean is not necessarily a hack as long as it does the job you want. But spawning threads at its own needs to be done with extreme care. The code should not be written that way that a single user can for example spawn an unlimited amount of threads per session and/or that the threads continue running even after the session get destroyed. It would blow up your application sooner or later.
The code needs to be written that way that you can ensure that an user can for example never spawn more than one background thread per session and that the thread is guaranteed to get interrupted whenever the session get destroyed. For multiple tasks within a session you need to queue the tasks. Also, all those threads should preferably be served by a common thread pool so that you can put a limit on the total amount of spawned threads at application level.
Managing threads is thus a very delicate task. That's why you'd better use the built-in facilities rather than homegrowing your own with new Thread()
and friends. The average Java EE application server offers a container managed thread pool which you can utilize via among others EJB's @Asynchronous
and @Schedule
. To be container independent (read: Tomcat-friendly), you can also use the Java 1.5's Util Concurrent ExecutorService
and ScheduledExecutorService
for this.
Below examples assume Java EE 6+ with EJB.
Fire and forget a task on form submit
@Named
@RequestScoped // Or @ViewScoped
public class Bean {
@EJB
private SomeService someService;
public void submit() {
someService.asyncTask();
// ... (this code will immediately continue without waiting)
}
}
@Stateless
public class SomeService {
@Asynchronous
public void asyncTask() {
// ...
}
}
Asynchronously fetch the model on page load
@Named
@RequestScoped // Or @ViewScoped
public class Bean {
private Future<List<Entity>> asyncEntities;
@EJB
private EntityService entityService;
@PostConstruct
public void init() {
asyncEntities = entityService.asyncList();
// ... (this code will immediately continue without waiting)
}
public List<Entity> getEntities() {
try {
return asyncEntities.get();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new FacesException(e);
} catch (ExecutionException e) {
throw new FacesException(e);
}
}
}
@Stateless
public class EntityService {
@PersistenceContext
private EntityManager entityManager;
@Asynchronous
public Future<List<Entity>> asyncList() {
List<Entity> entities = entityManager
.createQuery("SELECT e FROM Entity e", Entity.class)
.getResultList();
return new AsyncResult<>(entities);
}
}
In case you're using JSF utility library OmniFaces, this could be done even faster if you annotate the managed bean with @Eager
.
Schedule background jobs on application start
@Singleton
public class BackgroundJobManager {
@Schedule(hour="0", minute="0", second="0", persistent=false)
public void someDailyJob() {
// ... (runs every start of day)
}
@Schedule(hour="*/1", minute="0", second="0", persistent=false)
public void someHourlyJob() {
// ... (runs every hour of day)
}
@Schedule(hour="*", minute="*/15", second="0", persistent=false)
public void someQuarterlyJob() {
// ... (runs every 15th minute of hour)
}
@Schedule(hour="*", minute="*", second="*/30", persistent=false)
public void someHalfminutelyJob() {
// ... (runs every 30th second of minute)
}
}
Continuously update application wide model in background
@Named
@RequestScoped // Or @ViewScoped
public class Bean {
@EJB
private SomeTop100Manager someTop100Manager;
public List<Some> getSomeTop100() {
return someTop100Manager.list();
}
}
@Singleton
@ConcurrencyManagement(BEAN)
public class SomeTop100Manager {
@PersistenceContext
private EntityManager entityManager;
private List<Some> top100;
@PostConstruct
@Schedule(hour="*", minute="*/1", second="0", persistent=false)
public void load() {
top100 = entityManager
.createNamedQuery("Some.top100", Some.class)
.getResultList();
}
public List<Some> list() {
return top100;
}
}
See also:
Solution 2
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);
}
}
Under the covers what makes this work is:
- The
JobProcessor
the caller sees is not actually an instance ofJobProcessor
. 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 theRunnable
which is now waiting on the queue. - When the
Runnable
finally executes the method on the realJobProcessor
instance, it will take the return value and set it into theFuture
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.
Related videos on Youtube
Dmitry Chornyi
Updated on September 13, 2020Comments
-
Dmitry Chornyi over 3 years
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.
-
Basil Bourque almost 8 yearsFYI, JSR 236 added features to support spawning threads in Java EE 7 and later. See this Answer by Chris Ritchie on a similar question.
-
-
David Blevins almost 13 yearsFully agree that spawning threads is ok as long as it's done with extreme care (prefect wording). Note we finally addressed this need at the spec level in EJB 3.1. See my @Asynchronous answer.
-
Arjan Tijms almost 13 yearsNice comment indeed! We recently started calling @Asynchronous annotated methods from JSF backing beans and the results have been great. If the code is able to fire off the async action early, its execution can overlap with part of the life-cycle processing that JSF does. If you use this feature intensively, it does pay off to learn what the size of the thread pool is. In JBoss AS 6.0 this appeared to be
10
. -
Arjan Tijms almost 13 years@Asynchronous was truly one of the best additions in EJB 3.1. I hope for EJB 3.2/Java EE 7 the managed variant of fork/join from JDK 7 will be considered.
-
idolize almost 13 yearsIs there a good alternative library for non-JEE web servers like Tomcat?
-
David Blevins almost 13 years@mxrider You can drop OpenEJB as a war file into any 5.5 or greater version of Tomcat and get all this. As well check out Apache TomEE openejb.apache.org/3.0/apache-tomee.html
-
Adam over 12 years@BalusC could you elaborate on some tools/features that one could use to know when the session gets destroyed and end the thread (in an EJB 3.0 setting). If need be I can create a new question
-
Craig Ringer over 12 yearsNote that JBoss AS 7 doesn't support @Asynchronous unless you use the standalone-preview.xml profile (AS 7.0.2) or standalone-full.xml profile (AS 7.1.x). The basic profiles silently ignore the \@Asynchronous annotation, which will cause much swearing and hair-tearing.
-
Damian about 12 yearsNice, but I am still wondering what class the "real Future" implementation is? FutureTask?
-
David Blevins about 12 years@Damian Typically. OpenEJB/TomEE's implementation is driven by
public <T> Future<T> submit(Callable<T> task)
onExecutorService
, which usesFutureTask
as the implementation. The contract on theFuture.cancel()
method is slightly different, so containers will also wrap that object with aFuture
the implements the extra bits and ultimately delegates to aFutureTask
-
atamanroman over 11 yearsGreat answer. Adam Bien posted about this topic a few days ago: adam-bien.com/roller/abien/entry/…
-
Basil Bourque almost 8 yearsFYI: Java EE 7 and later gained new threading features with JSR 236: Concurrency Utilities for Java™ EE.