Si mi aplicación web y aplicación ejb están en la misma máquina (en la misma JVM) y todas las llamadas ejb son llamadas locales, ¿creará algún problema el uso de ThreadLocal al pasar información de web a ejb?Uso de ThreadLocal en la aplicación empresarial
¿Alguna solución si las llamadas ejb son remotas? ¿Estará disponible la información ThreadLocal desde la aplicación web a la aplicación ejb? ¿Es aconsejable el uso de ThreadLocal en tal escenario?
Para la primera pregunta, no hay problema siempre que elimine las variables de ThreadLocal al final de cada llamada. Esto es importante porque los contenedores (servlet o ejb) típicamente subprocesos del usuario y, por lo tanto, reutilización de subprocesos, esto tiene dos efectos: una "llamada" puede ver información de subprocesos proveniente de una llamada anterior, y si elimina una aplicación del contenedor sin detener la JVM es posible que algunas clases no se recojan como basura porque aún se hace referencia a ellas por una cadena de contenedores. Así que coloque datos en un threadlocal en un bloque try/finally y elimínelos en la parte finally.
Aquí está un post que muestra una manera de manejar el problema: ThreadLocal in web applications
Para la segunda pregunta como datos es ThreadLocal no vendrá con una llamada remota, hay que añadir un parámetro para las interfaces, extraer ThreadLocal datos sobre un lado y se recrean en el otro lado ...
¡Depende de la información que está pasando! La primera pregunta es demasiado genérica. Sugiero leer el JavaDoc relacionado con ThreadLocal here.
ThreadLocal vive desde el lado del servidor de la aplicación y se utiliza para permitir Thread-safe las llamadas de sus objetos Thread.
El javadoc de ThreadLocal no será suficiente. No se sabe con certeza cómo el servidor gestionará los hilos, los vinculará a las solicitudes, etc. – ymajoros
todas las llamadas EJB son llamadas locales, será el uso de ThreadLocal crear ningún problema mientras
No, usted respondió su pregunta usted mismo. Como las llamadas son locales, se ejecutan en el contexto de un hilo.
¿Alguna solución si las llamadas ejb son remotas?
En el caso de las llamadas remotas, el contenedor Java EE se llevará a cabo en otra JVM, que se generan sus propios hilos para manejar la petición RMI entrante, no hay manera para un contenedor Java EE remota a saber sobre el hilo variables locales que se declararon en el otro lado. Pásalo como un objeto de parámetro.
Para llamadas locales, el ThreadLocal debería funcionar bien, siempre que todo se haga en el mismo hilo.
Para las llamadas remotas, que potencialmente pueden ejecutarse en un servidor diferente, tendrá que proponer algo más. Pase todos los valores como parámetros (lo que funcionará, pero introduce complejidad en el código) o use algo como un caché distribuido, p. Hazelcast, que funcionará como un HashMap global, al que tienen acceso todos los nodos del clúster.
Al usar EJB 3.1 puede pasar información contextual en el EJBContext usando su context data. Esto es solo un Map<String,Object>.
ThreadLocal no debe utilizarse en contextos EJB.No se puede garantizar que las invocaciones del método EJB estén todas en el mismo hilo (por supuesto, debería ser).
En EJB hay una llamada de enfoque diferente TransactionSyncrhonizationRegistry. Ver Explanation/Usage para más detalles.
ThreadLocal no se puede utilizar con 100% de certeza en aplicaciones web. Simplemente no tienes la garantía de que un hilo se utilizará para una sesión. Desde mi punto de vista, esto puede ser un agujero de seguridad muy difícil de encontrar.
no funciona para mí, siempre devuelve null!
También probé TransactionSynchronizationRegistry, pero obtengo null también.
Lo único que funcionó es utilizar JAAS como solución alternativa. Pero no es una buena solución.
Gracias.Básicamente estoy agregando capacidades multilingües a una aplicación ee existente, sin tener que modificar gran parte del código. Estableceré el idioma información en la sesión HTTP y luego usar esa información en la sesión HTTP para establecer el valor en 'ThreadLocal'. Entonces tendrá que identificar un lugar en la aplicación (HTTPFilter quizás) que se llama antes de cada solicitud y establecer el valor en 'ThreadLocal 'de HTTPSession. Esto asegurará que esté disponible en EJB, que eventualmente se pasará como un parámetro de base de datos. –
Esto asegurará que incluso si no lo elimino, se sobrescribirá cada vez. Gracias por tu respuesta. –