¿Es seguro iniciar un nuevo hilo en un frijol administrado por JSF?

Echa un vistazo a EJB 3.1 @Asynchronous methods. Esto es exactamente para lo que están.

Pequeño ejemplo que usa OpenEJB 4.0.0-SNAPSHOTs. Aquí tenemos un frijol @Singleton con un método marcado @Asynchronous. Cada vez que ese método es invocado por alguien, en este caso su JSF managed bean, volverá inmediatamente sin importar cuánto tiempo tome realmente el método.

@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);
        }
    }
}

Aquí hay un pequeño testcase que invoca ese método @Asynchronous varias veces seguidas.

Cada invocación devuelve un Future objeto que esencialmente comienza empty y más tarde tendrá su valor rellenado por el contenedor cuando la llamada al método relacionado realmente se complete.

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);
    }
}

Ejemplo de código fuente

Bajo las cubiertas lo que hace que este trabajo es:

• El JobProcessor que ve el llamante no es realmente una instancia de JobProcessor. Más bien es una subclase o proxy que tiene todos los métodos anulados. Los métodos que se supone que son asíncronos se manejan diferente.
• Las llamadas a un método asincrónico simplemente resultan en la creación de un Runnable que envuelve el método y los parámetros que dio. Este ejecutable se le da a un Ejecutor que es simplemente una cola de trabajo adjunta a un grupo de subprocesos.
• Después de agregar el trabajo a la cola, la versión proxy del método devuelve una implementación de Future que está vinculada a Runnable que ahora está esperando en la cola.
• Cuando Runnable finalmente ejecuta el método en el real JobProcessor instancia, tomará el valor devuelto y lo establecerá en el Future poniéndolo a disposición del llamante.

Es importante tener en cuenta que el objeto AsyncResult que devuelve JobProcessor no es el mismo objeto Future que el llamador está sosteniendo. Habría sido genial si el verdadero JobProcessor pudiera devolver String y la versión de la persona que llama de JobProcessor pudiera devolver Future<String>, pero no vimos ninguna manera de hacerlo sin agregar más complejidad. Así que el AsyncResult es un objeto de envoltura simple. El el contenedor sacará el String, tirará el AsyncResult lejos, luego pondrá el String en el real Future que la persona que llama está sosteniendo.

Para obtener progreso en el camino, simplemente pase un objeto seguro para subprocesos como AtomicInteger al método @Asynchronous y haga que el código bean lo actualice periódicamente con el porcentaje completo.

Probé esto y funciona muy bien desde mi JSF gestionado frijol

ExecutorService executor = Executors.newFixedThreadPool(1);

@EJB
private IMaterialSvc materialSvc;

private void updateMaterial(Material material, String status,  Location position) {

    executor.execute(new Runnable() {
        public void run() {
            synchronized (position) {
                // TODO update material in audit? do we need materials in audit?
                int index = position.getMaterials().indexOf(material);
                Material m = materialSvc.getById(material.getId());
                m.setStatus(status);
                m = materialSvc.update(m);
                if (index != -1) {
                    position.getMaterials().set(index, m);
                }

            }
        }
    });

}

@PreDestroy
public void destory() {
    executor.shutdown();
}