108

Una de las primeras cosas que aprendí sobre el desarrollo de Java EE es que no debería generar mis propios hilos dentro de un contenedor Java EE. Pero cuando lo pienso, no sé la razón.¿Por qué se desaconsejan los hilos de desove en el contenedor Java EE?

¿Puede explicar claramente por qué se desaconseja?

estoy seguro que la mayoría de aplicaciones empresariales necesitan algún tipo de peticiones asíncronas como demonios electrónico, sesiones inactivas, trabajos de limpieza, etc.

Por lo tanto, si es que uno no debe generar discusiones, ¿cuál es la forma correcta de hacerlo ¿cuando sea necesario?

Fuente

2009-02-10 LiorH

tareas asíncronas se realiza a través de mensajes y BMD JMS. –

Este problema debería ser pronto una cosa del pasado una vez que [JSR 236] (http://jcp.org/en/jsr/detail?id=236) se implementa en los contenedores. – letmaik

No se recomienda porque el contenedor debe crear y gestionar cualquier segundo subproceso, de modo que el subproceso tendrá acceso a los otros recursos de la empresa. Con Java EE7, existe una forma estándar y correcta de crear subprocesos en un entorno empresarial. Al utilizar Concurrency Utils, se asegura de que su nuevo hilo sea creado y gestionado por el contenedor, garantizando que todos los servicios de EE estén disponibles. Ejemplo [aquí] (http: // stackoverflow.com/questions/3212255/java-ee-specification-and-multi-threading/19404307 # 19404307) –

Se desaconseja porque el servidor debe gestionar y controlar potencialmente todos los recursos del entorno. Además, gran parte del contexto en el que se utiliza un subproceso generalmente se adjunta al subproceso de ejecución en sí. Si simplemente inicia su propio hilo (que creo que algunos servidores ni siquiera permitirán), no puede acceder a otros recursos. Lo que esto significa es que no puede obtener un InitialContext y realizar búsquedas JNDI para acceder a otros recursos del sistema, tales como Fábricas de conexiones JMS y Fuentes de datos.

Hay formas de hacerlo "correctamente", pero depende de la plataforma que se utilice.

The commonj WorkManager is common for WebSphere and WebLogic as well as others

More info here

And here

también menos duplicaba this one de esta mañana

ACTUALIZACIÓN: Tenga en cuenta que esta pregunta y la respuesta se relacionan con el estado de Java EE en 2009, las cosas ¡Han mejorado desde entonces!

Fuente

2009-02-10 19:43:40 Robin

_ no puede obtener un InitialContext y realizar búsquedas JNDI para acceder a otros recursos del sistema como JMS Factory y Datasources._ Tengo una aplicación que funciona al respecto inyectando el origen de datos al iniciar los hilos, pero podría tener que replantear este enfoque. .. – rjohnston

Ahora existe una forma estándar y correcta de crear subprocesos con la API principal de Java EE. Al utilizar Concurrency Utils, se asegura de que su nuevo hilo sea creado y gestionado por el contenedor, garantizando que todos los servicios de EE estén disponibles. Ejemplos [aquí] (http://blog.chris-ritchie.com/2013/09/simple-concurrency-example-with-wildfly.html) y [aquí] (http: //blog.chris-ritchie. com/2013/10/managed-thread-factory-example-in-wildfly.html) –

@ChrisRitchie gracias por la sugerencia. si solo JBoss AS/IBM WAS es compatible con Java EE 7 ... :-( – asgs

Nunca he leído que esté desaconsejado, excepto por el hecho de que no es fácil hacerlo correctamente.

Es una programación de bajo nivel, y al igual que otras técnicas de bajo nivel, debe tener una buena razón. La mayoría de los problemas de concurrencia se pueden resolver de forma mucho más efectiva utilizando construcciones integradas como grupos de subprocesos.

Fuente

2009-02-10 19:28:42 levand

es de hecho prohibido por la especificación. –

http://java.dzone.com/articles/5-quick-points-about-threads – newday

La razón por la que no debe generar sus propios hilos es que estos no serán gestionados por el contenedor. El contenedor se encarga de un montón de cosas que un desarrollador principiante puede encontrar difícil de imaginar. Por ejemplo, el contenedor utiliza cosas como la agrupación de subprocesos, la agrupación en clústeres y las recuperaciones de bloqueos. Cuando comienzas un hilo, puedes perder algunos de esos. Además, el contenedor le permite reiniciar su aplicación sin afectar la JVM en la que se ejecuta. ¿Cómo sería posible si hay hilos fuera del control del contenedor?

Este es el motivo por el que se introdujeron los servicios del temporizador J2EE 1.4. Vea el artículo this para más detalles.

Fuente

2009-02-10 19:39:29 kgiannakakis

JSR 236 funciones adicionales para admitir subprocesos de desove en Java EE 7 y versiones posteriores. Ver [este hermano Respuesta de Chris Ritchie] (http://stackoverflow.com/a/19404453/642706). –

No hay una razón real para no hacerlo. Usé Quarz con Spring en una webapp sin problemas. También se puede usar el marco de concurrencia java.util.concurrent. Si implementa su propio manejo de subprocesos, configure theads en deamon o use un grupo de subprocesos propio deamon para que el contenedor pueda descargar su aplicación web en cualquier momento.

Pero tenga cuidado, el grano alcances sesión y petición no funcionan en las discusiones engendrado!Además, el otro código que se basa en ThreadLocal no funciona de la caja, usted debe transferir los valores a los hilos engendrados por usted mismo.

Fuente

2009-02-10 19:48:44

Siempre puede decirle al contenedor que inicie cosas como parte de sus descriptores de implementación. Estos pueden hacer las tareas de mantenimiento que necesites hacer.

Siga las reglas. Estarás contento algún día lo hiciste :)

Fuente

2009-02-10 19:56:02

Una razón que he encontrado si engendras algunos hilos en tu EJB y luego tratas de que el contenedor descargue o actualice tu EJB vas a tener problemas. Casi siempre hay otra manera de hacer algo que no necesita un hilo, así que solo diga NO.

Fuente

2009-02-10 22:40:05 Javamann

Para EJBs, no es solamente desanimado, está prohibido expresamente por la specification:

un bean empresarial no debe utilizar hilo primitivas de sincronización a ejecución de sincronización de múltiples casos.

El enterprise bean no debe intentar para manejar los hilos. El enterprise bean no debe intentar iniciar, detener, suspender, o reanudar un hilo, o cambiar la prioridad o el nombre de un hilo. Enterprise Bean no debe intentar para administrar grupos de subprocesos.

El motivo es que los EJB están diseñados para funcionar en un entorno distribuido. Un EJB puede moverse de una máquina en un clúster a otro. Los hilos (y los enchufes y otras instalaciones restringidas) son una barrera significativa a esta portabilidad.

Fuente

2009-02-10 23:06:58

Java EE7 Concurrency Utils proporciona una forma correcta de crear subprocesos en un entorno empresarial. Ejemplos [aquí] (http: // blog.chris-ritchie.com/2013/09/simple-concurrency-example-with-wildfly.html) y [aquí] (http://blog.chris-ritchie.com/2013/10/managed-thread-factory -example-en-wildfly.html) –

@Dan ¿Puede explicarme por qué un subproceso sería una barrera importante para la portabilidad de mover un EJB de una máquina en un custer a otro? – Geek

Los hilos están prohibidos en los contenedores Java EE de acuerdo con los planos. Consulte el blueprints para obtener más información.

Fuente

2010-12-23 10:55:10 Ojitha

de concurrencia Utilidades para Java EE

En la actualidad existe un estándar, y la forma correcta de crear hilos con el núcleo de Java EE API:

JSR 236: Concurrency Utilities for Java™ EE

Mediante el uso de concurrencia Utilidades, se asegura de que su nuevo hilo sea creado y gestionado por el contenedor, garantizando que todos los servicios de EE estén disponibles.

Ejemplos here

Fuente

2013-10-16 13:14:25

¿Por qué se desaconsejan los hilos de desove en el contenedor Java EE?

Respuesta

de concurrencia Utilidades para Java EE

Cuestiones relacionadas