Multithreading in a stateless session bean?_问答_开发者

The EJB 3.0 specification does not allow a business method of a stateless session bean to create new threads. Why is that? What is wrong with creating additional worker threads that only do raw computations and never call into the app server?

Say, my session bean implements a service that lets users to upload images, and the business method does cpu-intensive image processing on these images. Then it can only use one cpu core to do this job, even if the machine has 8 or more 开发者_JAVA百科cores? If i utilize a third party image processing library, that internally creates worker threads, i would also violate the EJB specs, even though that library and these threads have nothing to do with the EJB container at all. This does not seem right.

What can happen if i ignore the EJB rules and still create some worker threads to do cpu intensive processing? Of course these threads will never touch any app server objects and the bean thread will join them before returning. Can still something bad happen?

The EJB 3.0 specification does not allow a business method of a stateless session bean to create new threads. Why is that?

Short version: managing threads from EJBs is disallowed because it would harm resource management, transaction management, security (technical reasons) and also because this is something the EJB model doesn't want to promote (philosophical reason).

The EJB specification puts it like this:

21.1.2 Programming Restrictions

...

The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.

These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads would decrease the container’s ability to properly manage the runtime environment.

Related Questions

How can an EJB parallelize a long, CPU intensive process?

In my simplified understanding, it's like running a company. You're the boss (the container), and there's an employee which suddenly just hire 100 people out of the blue without any notice (the bean).

But you can still easily do multithreading with the @Asynchronous annotation (there are other ways too).

@Stateless
public class Employee {
    @Asynchronous
    public Future<Void> work(Project projectThatTakeTooLong) {
        // work work work
        return new AsyncResult<Void>(null);
    }
}

@Stateless
public class Boss {

    @Inject
    private Employee randomStatelessEmployee;

    public void giveWork() {
        Future<Void> result1 = randomStatelessEmployee.work(new Project());
        Future<Void> result2 = randomStatelessEmployee.work(new Project());
        Future<Void> result3 = randomStatelessEmployee.work(new Project());
        result1.get();
        result2.get();
        result3.get();
    }
}

There's also a better example here: Jboss Java EE container and an ExecutorService

One type of workaround:

import java.util.concurrent.Executor;
import javax.ejb.Asynchronous;
import javax.ejb.Stateless;

@Stateless
public class TransactionalExecutor implements Executor {

    @Override @Asynchronous
    public void execute(Runnable command) {
        command.run();
    }
}

Now you can use TransactionalExecutor as an executor:

@Stateless
public class SlowService {

    @Inject
    Executor command;

    public void invoke(){
        Runnable command = new Runnable() {
            @Override
            public void run() {
                // heavy task
            }
        };
        command.execute(command);
    }    
}

This is known restriction not to use threads in J2EE applications. Application server should take care of parallel execution of the program

Yes, you can ignore the EJB rules but can face with extremely unpredictable behaviour.