Implementación de concurrencia en la aplicación web Java EE

Question

Estamos creando una aplicación web en la que necesitamos concurrencia para algunos casos comerciales. Esta aplicación se implementaría en un contenedor Tomcat. Sé que la creación de subprocesos definidos por el usuario en el contenedor web es una mala idea y estoy tratando de explorar las opciones que tengo.

1. Haga que mi biblioteca multiproceso se utilice como un componente JCA. Somos reacios a utilizar este enfoque debido a la curva de aprendizaje que podría estar involucrada.
2. Sé que hay API de WorkManager disponible, pero supongo que eso no está implementado por tomcat, por lo que esta opción se apaga.
3. Hice algunas investigaciones y descubrí que se recomienda la biblioteca CommonJ para Tomcat. ¿Alguien lo ha usado?
4. Además, veo que hay ManagedExecutorService disponible, pero no estoy seguro de cómo usarlo y ¿es diferente de la API de WorkManager (y de la biblioteca commonJ)?

Cualquier ayuda sobre esto apreciada. Por cierto, el uso de JMS está fuera de toda duda debido al entorno de despliegue. Me inclino por los puntos 3 y 4, pero no tengo mucho conocimiento al respecto. Podría alguien guiar a los pls.

Answer 1

Dado que está utilizando Tomcat, no se preocupe y haga lo que desee. La sección Servlet de Java EE no hace mención de hilos, etc. Eso es principalmente bajo la sección EJB.

Tomcat en sí no hace mucho en términos de preocuparse por la gestión de los hilos, es un contenedor bastante no invasivo.

Lo mejor es conectar sus hilos a un ServletContextListener para que pueda prestar atención al ciclo de vida de la aplicación, y apagar sus cosas cuando la aplicación se apaga, pero más allá de eso, no se preocupe demasiado por eso y use lo que sea estoy contento con.

Adenda -

La simple verdad es Tomcat no le importa, y que no es tan sofisticado. Tomcat tiene un grupo de subprocesos para cada uno de los oyentes HTTP y eso es casi el final de su nivel de gestión. Tomcat no va a tomar los hilos de un oyente HTTP silencioso y dedicarlos a uno ocupado, por ejemplo. Si Tomcat estaba realmente interesado en cómo crear subprocesos, le impediría hacerlo, y no es así.

Eso significa que la gestión de subprocesos fuera del contexto HTTP recae directamente sobre sus hombros como implementador. Java EE expone este tipo de instalaciones, y las interfaces hacen grandes lecturas. Pero la verdad es que las capacidades teóricas expuestas por los documentos de la API de Java EE y la realidad de las implementaciones modernas son muy diferentes, particularmente en sistemas de gama baja como Tomcat.

Para no menospreciar Tomcat. Tomcat es una gran pieza de software. Pero para la mayoría de sus casos de uso, la capacidad de gestión adicional simplemente no es necesaria.

Configurar su propio grupo de subprocesos (utilizando las instalaciones proporcionadas por JDK) y trabajar con su propio modelo de ciclo de vida de subprocesos probablemente lo verá con éxito en cualquier proyecto en el que esté trabajando. Realmente no es un gran problema.

Answer 2

Cada componente base Servlet -Java EE para el procesamiento de solicitudes HTTP en su aplicación web es un Singleton, y cada solicitud se ejecuta en su propio hilo independiente por lo que no es necesario iniciar/detener hilos generados por el usuario. Su contenedor web, en este caso Tomcat, gestiona todo eso.

Además de eso, debe tener en cuenta algunas consideraciones para el procesamiento de subprocesos múltiples en su código. Por ejemplo, como los Servlets son singleton y se generan muchos hilos para esta clase, es una mala idea tener atributos de instancia en estos componentes.

Answer 3

Hay un par de opciones. Independientemente de las restricciones de los contenedores que podrían estar o no en su lugar, engendrar hilos individuales a pedido es casi siempre una mala idea. No es que esto no funcione en un entorno Servlet, pero la cantidad de subprocesos que potencialmente se pueden crear podría quedar completamente fuera de control.

La solución más simple es un antiguo grupo de subprocesos Java SE simple a través de un servicio de ejecución normal. Inicie el grupo en un oyente Servlet y proporcione acceso a él a través de una variable estática. No demasiado bonito, pero hace el trabajo bien. Dependiendo de su caso de uso exacto, esta podría ser la mejor solución (si su caso de uso es bastante bajo).

Otra opción es agregar OpenEJB a su guerra, y luego tomar ventaja de la anotación @Asynchronous.

Otra opción más, es darse cuenta de que uno normalmente utiliza Tomcat si los requisitos del negocio son extremadamente simples o de bajo nivel. Ese es casi todo el punto de usar algo como hueso desnudo un Tomcat. Tan pronto como tenga la necesidad de agregar (toneladas de) bibliotecas, es posible que haya superado a Tomcat y que sea mejor utilizar un servidor que ya tenga la funcionalidad que necesita (en este caso, la ejecución asincrónica). Ejemplos son TomEE, GlassFish, Resin, JBoss AS, Geronimo, etc.

Answer 4

He usado CommonJ muchas veces y funciona muy bien. Se puede inicializar y destruir desde un ServletContextListener.