Реализация параллелизма в Java EE Веб-приложение

Question

Мы создаем веб-приложение, где нам нужно иметь параллелизм для нескольких бизнес-кейсов. Это приложение будет развернуто в контейнере tomcat. Я знаю, что создание пользовательских потоков в веб-контейнере - плохая идея, и я пытаюсь изучить варианты, которые у меня есть.

1. Имейте мою многопоточную библиотеку, используемую в качестве компонента JCA. Мы не склонны использовать этот подход из-за кривой обучения, которая может быть задействована.
2. Я знаю, что есть API WorkManager API, но я думаю, что это не реализовано tomcat, поэтому этот параметр гаснет.
3. Я провел некоторое исследование и выяснил, что библиотека CommonJ рекомендуется для Tomcat. Кто-нибудь использовал его?
4. Кроме того, я вижу, что есть ManagedExecutorService, но я не уверен, как его использовать, и отличается ли он от API WorkManager API (и библиотеки commonJ)?

Любая помощь по этому признанию. Кстати, использование JMS не может быть и речи из-за среды развертывания. Я склоняюсь к пунктам 3 и 4, но у меня мало знаний об этом. Может ли кто-нибудь руководить PLS.

Answer 1

Поскольку вы используете Tomcat, не беспокойтесь об этом и не делайте все, что хотите. Раздел Servlet Java EE не упоминает о потоках и т. Д. Это в основном в разделе EJB.

Tomcat сам по себе не делает ничего общего с точки зрения заботы об управлении потоками, это довольно неинвазивный контейнер.

Лучше всего связать свои потоки с ServletContextListener, чтобы вы могли обращать внимание на жизненный цикл приложения и отключать свои приложения, когда приложение закрывается, но помимо этого не чрезмерно беспокоиться об этом и использовать все, что угодно «доволен.

Addenda -

Простая истина заключается в Tomcat не заботится, и это не так уж сложной. Tomcat имеет пул потоков для каждого из HTTP-прослушивателей, и это конец его уровня управления. Tomcat не собирается принимать потоки от тихого прослушивателя HTTP и, например, посвящает их занятому. Если Tomcat действительно заинтересовался тем, как вы создаете потоки, это помешает вам сделать это - и это не так.

Это означает, что управление потоками вне контекста HTTP попадает прямо на плечи в качестве разработчика. Java EE предоставляет такие возможности, а интерфейсы отлично читают. Но простая истина заключается в том, что теоретические возможности, поддерживаемые документами Java EE API, и реальность современных реализаций сильно отличаются друг от друга, особенно в системах с низким уровнем, таких как Tomcat.

Не пренебрегать Tomcat. Tomcat - отличное программное обеспечение. Но для большинства своих случаев использования дополнительные возможности управления просто не нужны.

Настройка собственного пула потоков (с использованием предоставленных JDK объектов) и работа с вашей собственной жизненной моделью потока, вероятно, позволит вам успешно выполнить любой проект, над которым вы работаете. Это действительно не большое дело.

Answer 2

Каждый базовый компонент Servlet -Java EE для обработки HTTP-запросов - в вашем веб-приложении - это Singleton, и каждый запрос выполняется в собственном независимом потоке, поэтому нет необходимости запускать/останавливать созданные пользователем потоки самостоятельно. Ваш веб-контейнер - в этом случае Tomcat - управляет всем этим.

Кроме того, вам необходимо иметь в виду некоторые соображения для многопоточной обработки в вашем коде. Например, поскольку сервлеты являются одноточечными и многие нити порождены для этого класса, это плохая идея иметь атрибуты экземпляра в этих компонентах.

Answer 3

Есть несколько вариантов. Независимо от ограничений контейнера, которые могут быть или не быть на месте, нерестование отдельных потоков по требованию почти всегда является плохой идеей. Дело не в том, что это не будет работать в среде Servlet, но количество потоков, которые вы можете создать, может полностью выйти из-под контроля.

Простейшим решением является простой старый пул потоков Java SE через обычную службу запуска. Запустите пул в приемнике Servlet и обеспечите доступ к нему через некоторую статическую переменную. Не слишком красиво, но он выполняет свою работу. В зависимости от вашего конкретного варианта использования это может быть лучшим решением (если ваш вариант использования довольно низкий).

Другой вариант - добавить OpenEJB к вашей войне, а затем воспользоваться @Asynchronous аннотацией.

Еще один вариант - понять, что обычно используется Tomcat, если бизнес-требования чрезвычайно просты или низки. Это в значительной степени смысл использования чего-то, как голой кости Tomcat. Как только вы обнаружите, что вам нужно добавлять (тонны) библиотек, вы могли бы перерасти Tomcat и могли бы лучше использовать сервер, на котором уже есть необходимая функциональность (в данном случае асинхронное выполнение). Примеры: TomEE, GlassFish, Resin, JBoss AS, Geronimo и т. Д.

Answer 4

Я использовал CommonJ много раз, и он работает очень хорошо. Он может быть инициализирован и уничтожен из ServletContextListener.