Asynchronous beans and methods in WebSphere

The Java EE specification does NOT allow to (manually) create threads in order to parallelize work.
Manually created threads usually result in warnings like this:

ThreadMonitor W   WSVR0605W: Thread "Default : 0" (<ThreadID>) has been active for xxx milliseconds and may be hung.  There is/are 1 thread(s) in total in the server that may be hung.
Example log entry:
WSVR0605W: Thread "WebContainer : 124" (0000045c) has been active for 666666 milliseconds and may be hung.  There is/are 3 thread(s) in total in the server that may be hung.

The root cause is that the threads are running outside of the Java EE context. The application server has no control over them.

In WebSphere versions < 8 (without Java EE 6) IBM offers the so called Asynchronous Beans to solve this issue. This blog article discribes the usage of Asynchronous Beans in WebSphere 7.

Since WebSphere 8 (Java EE 6) it's possible to use asynchronous method invocation.

Simply add an @Asynchronous annotation to the method.

public class AsyncService {
    public void doAsyncWork(){
        try {
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
        System.out.println("Async work done");

A sample asynchronous method invocation project for WebSphere Application Server 8.5.5. can be downloaded here. 

The WebSphere administration console allows you to config the basic setups of the underlying thread pool used for the asynchronous handling.
It is also possible to create custom Work Manager instance for a more large-scale setup ("Use custom work manager instance"). The default setup uses the DefaultWorkManager. The DefaultWorkManager is a shared resource, also used for other asynchronous work tasks of the application server (!).
To create a custom (and dedicated) Work Manager go to Resources > Asynchronous beans > Work managers > New ... and create a new Work Manager instance.