Метод действия JSF не завершается, если был запущен новый поток [duplicate]

Проверьте EJB 3.1 @Asynchronous methods. Это именно то, для чего они предназначены.

Небольшой пример использования OpenEJB 4.0.0-SNAPSHOT. Здесь у нас есть @Singleton компонент с одним методом, отмеченным @Asynchronous. Каждый раз, когда этот метод вызывается кем-либо, в этом случае ваш управляемый bean-компонент JSF, он немедленно возвращается независимо от того, сколько времени действительно принимает метод.

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

Вот небольшой тестовый файл, который вызывает @Asynchronous метод несколько раз подряд.

Каждый вызов возвращает объект Future , который по существу запускает empty и позже будет иметь свое значение, заполненное контейнером, когда вызов соответствующего метода фактически завершается

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

Пример исходного кода

Под обложками, что делает эту работу, является:

• JobProcessor, вызывающий не видит на самом деле экземпляр JobProcessor. Скорее это подкласс или прокси-сервер, у которого все методы переопределены. Методы, которые должны быть асинхронными, обрабатываются по-разному.
• Вызовы асинхронного метода просто приводят к созданию Runnable, которое обертывает метод и параметры, которые вы указали. Эта runnable предоставляется Executor , которая является просто рабочей очередью, прикрепленной к пулу потоков.
• После добавления работы в очередь проксированная версия метода возвращает реализацию из Future, который связан с Runnable, который теперь ожидает в очереди.
• Когда Runnable, наконец, выполняет метод на экземпляре real JobProcessor , он примет возвращаемое значение и установит его в Future, сделав его доступным для вызывающего.

Важно отметить, что объект AsyncResult, возвращаемый JobProcessor, не является тот же объект Future, который удерживает вызывающий объект. Было бы здорово, если бы реальный JobProcessor мог просто вернуться String, а версия JobProcessor вызывающего абонента могла вернуться Future<String>, но мы не видели никакого способа сделать это, не добавляя дополнительной сложности. Таким образом, AsyncResult представляет собой простой объект-оболочку. Контейнер вытащит String, выбросит AsyncResult, а затем String в real Future, который удерживает вызывающий абонент.

To получите прогресс на этом пути, просто передайте потокобезопасный объект, например AtomicInteger , к методу @Asynchronous и периодически обновляйте его компонентом с кодом процента.

Я пробовал это и отлично работал с моим управляемым bean-файлом JSF

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