Por lo que entiendo, es ilegal generar subprocesos desde dentro de un EJB, ya que puede interferir con el ciclo de vida del EJB. Sin embargo, ¿es ilegal usar clases Java predefinidas desde el JDK que engendran y manejan hilos internamente como Executor dentro de un EJB, específicamente un MDB?EJB y subprocesamiento
El mayor problema con los subprocesos y los EJB es que los subprocesos son un recurso limitado muy utilizado por el contenedor y los errores de subprocesos generan filtraciones de agrupaciones de subprocesos que pueden matar efectivamente a toda la instancia de JVM.
Executor debería comportarse mejor, pero todavía va a utilizar un hilo durante un período de tiempo; también puede fallar instantáneamente si alguien ha sintonizado el contenedor para agotar los hilos disponibles.
El resumen es que vas a caminar sobre la cuerda floja.
Para agregar a la respuesta de @Charlie Martin, sea lo que sea que necesite el Ejecutor, puede diseñar otro EJB para realizar la misma acción sin el Ejecutor. Esto permite que el nuevo EJB se ejecute en un subproceso separado manejado por el contenedor. La desventaja es que es posible que tenga que "volver a implementar la rueda", ya que todavía no desea utilizar hilos/Ejecutor de la JVM. También se agrega a la sobrecarga de obtener un EJB para ubicar/solicitar/conectar/llamar a otro.
La conclusión es que se supone que los EJB son hilos de trabajo. Puede parecer excesivo repetir el código en lugar de usar el Ejecutor y hasta cierto punto. La mayor distinción es una de escala. Los ejecutores estarán limitados a una sola JVM, mientras que los EJB se pueden escalar a través de las JVM y entre los servidores.
Usted "no puede" (no debería) usar hilos, grupos de hilos, ejecutores ... todo lo anterior. El punto de usar un servidor de aplicaciones es escribir solo la lógica de negocios y dejar que el servidor de aplicaciones haga el trabajo pesado. Si realmente, realmente necesita hacer su propio enhebrado, use un servicio EJB 3.1 "singleton" para administrar el enhebrado. sin embargo, como mencionaron otros, es mejor dejar esto al servidor de la aplicación. Una forma de hacer el procesamiento paralelo en un servidor de aplicaciones es usar MDB (que parece que ya está usando), aunque dependiendo del tipo de procesamiento paralelo, puede ser demasiado pesado.
Esto es lo que EJB 3.1 @Asynchronous es para y definitivamente debe utilizarse en lugar de un ejecutor. En general, es muy peligroso competir con los grupos de subprocesos del contenedor. Hacerlo es una excelente manera de matar el rendimiento.
El soporte Asynchronous utilizará las agrupaciones de hilos del contenedor y será mucho más seguro. Consulte this answer para obtener detalles sobre cómo funciona Asynchronous.
Estoy de acuerdo con Charlie, solo pensé en agregar algo y decir que un MDB definitivamente sería la mejor solución. – vickirk
¿Eso significa que puedo usar Executor dentro de un MDB sin ningún riesgo? – TheWolf
@Vapen no, mira mi respuesta. – jtahlborn