Introduction

EJB 3.1 added container-managed asynchronous methods through the @Asynchronous annotation. The important design point is that the application server, not your bean code, owns the thread pool that runs those methods, so the right mental model is "submit work to the container" rather than "create my own thread."

How @Asynchronous Works

When a client calls an EJB method annotated with @Asynchronous, the container dispatches that call for later execution and returns control immediately to the caller. The method can either return void for fire-and-forget style work or Future<T> if the caller needs a result later.

1import jakarta.ejb.Asynchronous;
2import jakarta.ejb.Stateless;
3import java.util.concurrent.Future;
4import jakarta.ejb.AsyncResult;
5
6@Stateless
7public class ReportService {
8    @Asynchronous
9    public Future<String> generateReport() {
10        String result = "report-ready";
11        return new AsyncResult<>(result);
12    }
13}

The container handles scheduling, thread assignment, and lifecycle integration.

The Thread Pool Is Container Managed

This is the part developers often misunderstand. EJB async methods do not create a dedicated thread per invocation in your code. They run on server-managed executor resources.

That means thread-pool behavior depends on the application server. WildFly, GlassFish, Payara, WebLogic, and other servers expose different configuration knobs, but the principle stays the same: thread count, queuing behavior, and resource isolation are configured at the container level.

This is also why directly creating your own unmanaged threads inside EJB code is usually discouraged. It bypasses container services such as transactions, security context, and lifecycle management.

Returning Results And Exceptions

If an asynchronous method returns Future<T>, the caller can check the result later:

Future<String> future = reportService.generateReport();
String value = future.get();
System.out.println(value);

future.get() blocks until completion and can surface exceptions through ExecutionException. For that reason, async methods move the wait point, but they do not remove the need for proper error handling.

If the caller truly does not care about the result, a void return type is simpler.

When Async EJB Is A Good Fit

Asynchronous EJB methods are useful for work that is slower than a normal request flow but still belongs under container management, such as report generation, notification dispatch, or background coordination triggered by business events.

They are less useful for CPU-heavy work that would saturate the server thread pool without capacity planning. Container-managed async is convenient, but it still consumes finite server resources.

Another reason container-managed async matters is context propagation. Security identity, naming resources, and transaction boundaries are managed in a way that matches the application server model. If you jump outside that model with unmanaged threads, code may appear to work in development while losing important container services under real load.

Tuning should be validated under realistic load, not only by annotation choice. A small async thread pool can serialize work and hide the intended concurrency benefit, while an oversized pool can create contention elsewhere in the server. The annotation declares the intent, but the container configuration decides the real concurrency envelope.

Common Pitfalls

One common mistake is assuming @Asynchronous means unlimited parallelism. In reality, execution still depends on the server’s configured thread pool and queueing limits.

Another mistake is starting custom threads manually inside EJB code. That usually fights the container rather than working with it.

A third issue is forgetting that Future.get() blocks. If the caller immediately waits for the result, the code may recover little practical benefit from the asynchronous dispatch.

Summary

• EJB 3.1 async methods are declared with @Asynchronous.
• The application server runs them on a container-managed thread pool.
• Use Future<T> when the caller needs a later result, or void when it does not.
• Treat async EJB work as managed background execution, not as a replacement for explicit thread creation.