Czy można bezpiecznie założyć nowy wątek w JSF managed bean?

Sprawdź EJB 3.1 @Asynchronous methods. Właśnie po to są.

Mały przykład, który używa OpenEJB 4.0.0-SNAPSHOTs. Tutaj mamy @Singleton fasolę z jedną metodą oznaczoną @Asynchronous. Za każdym razem, gdy ta metoda jest wywoływana przez kogokolwiek, w tym przypadku twój JSF managed bean, natychmiast powróci niezależnie od tego, jak długo metoda faktycznie trwa.

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

Każde wywołanie zwraca Future obiekt, który zasadniczo zaczyna się empty, a później jego wartość zostanie wypełniona przez kontener, gdy powiązane wywołanie metody zakończy się.

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

Przykładowy kod źródłowy

Pod pokrywami co sprawia, że ta praca jest:

• JobProcessor widziany przez rozmówcę nie jest w rzeczywistości instancją JobProcessor. Jest to raczej podklasa lub proxy, która ma nadpisane wszystkie metody. Obsługiwane są metody, które mają być asynchroniczne inaczej.
• wywołania metody asynchronicznej po prostu powodują utworzenie Runnable, która zawija podaną metodę i parametry. Ta funkcja jest przekazywana do executora, który jest po prostu kolejką roboczą dołączoną do puli wątków.
• Po dodaniu pracy do kolejki, wersja Proxy metody zwraca implementację Future, która jest powiązana z Runnable, która teraz czeka w kolejce.
• kiedy Runnable W końcu wykona metodę na real JobProcessor instancja pobierze wartość zwracaną i ustawi ją w Future, udostępniając ją wywołującemu.

Należy pamiętać, że obiekt AsyncResult, który zwraca JobProcessor, nie jest tym samym obiektem Future, który przechowuje wywołujący. Byłoby fajnie, gdyby prawdziwa {[6] } mogła po prostu powrócić String, a wersja wywołująca JobProcessor mogła powrócić Future<String>, ale nie widzieliśmy żadnego sposobu, aby to zrobić bez dodawania większej złożoności. Więc {[14] } jest prostym obiektem wrappera. Na pojemnik wyciągnie String, wyrzuci AsyncResult, a następnie umieści String w rzeczywistym Future że rozmówca trzyma.

Aby uzyskać postęp po drodze, po prostu przekaż obiekt bezpieczny dla wątku, taki jak AtomicInteger do metody @Asynchronous i poproś, aby Kod bean okresowo aktualizował go z procentami.

Próbowałem tego i działa świetnie z mojego JSF managed bean

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