Temas en primavera

Question

que tienen una aplicación web usando primavera y Hibernate y puntales (que se ejecuta en Tomcat)

La secuencia de llamada es algo como esto ...

puntales acción requiere frijol servicio de resorte, que a su vez llama a Spring DAO bean. La implementación de DAO es una implementación de Hibernate.

La pregunta es ¿Funcionarían todos mis granos de primavera en el mismo hilo? ¿Puedo guardar algo en ThreadLocal y obtenerlo en otro bean?

Estoy bastante seguro de que esto no funcionaría en Stateless Session Bean. El contenedor EJB puede generar (o generará) un nuevo hilo para cada llamada al bean de sesión

¿El contenedor de resorte hará lo mismo? es decir, ¿ejecuta todos los beans en el mismo hilo?

Cuando intentaba realizar una prueba unitaria -. Tengo el mismo ID a través Thread.currentThread() getId() en el caso de prueba y los dos beans- lo que me lleva a creer que había sólo un hilo en la acción

¿O el comportamiento es impredecible? ¿O cambiará cuando se ejecute en el servidor Tomcat?

aclaración No deseo intercambiar datos entre dos hilos. Quiero poner datos en ThreadLocal y poder recuperarlos de todos los beans en la pila de llamadas. Esto solo funcionará si todos los beans están en el mismo subproceso

Answer 1

El resorte no genera los subprocesos. Tomcat lo hace. Spring solo está creando y conectando los objetos para ti.

Cada solicitud del navegador se procesa en una sola solicitud. Es Tomcat quien maneja la solicitud. Es Tomcat quien crea el hilo para procesar la solicitud.

Suponiendo que acaba de crear un bean Singleton en Spring llamado "X". Entonces, la misma instancia de X es utilizada por todas las solicitudes.

Los granos de primavera no viven en un hilo. Simplemente están asignados en el montón.

Answer 2

¿Funcionarían todos mis granos de primavera en el mismo hilo? ¿Puedo almacenar algo en ThreadLocal y obtener en otro bean? AFAIK para los componentes que mencionó (servicio de frijoles, DAO frijol - supongo que son simples granos de primavera), Spring no genera un nuevo hilo. No entiendo su caso de uso (es decir, el intercambio de datos entre dos hilos).

Para la mayoría de aplicaciones web, un nuevo hilo se genera para cada nueva solicitud, y si desea compartir datos entre dos peticiones que normalmente: - utilizar los parámetros GET/POST para pasar los datos - utilizar la sesión para compartir datos

Para responder a su pregunta, estoy bastante seguro de que el contenedor de resorte no genera hilos para la mayoría de los componentes.

Answer 3

Sí, puedes hacer esto.El mismo hilo se usará para ejecutar su acción para que ThreadLocal funcione. Normalmente, el mismo subproceso se usa también para el bean de sesión sin estado, suponiendo que se ejecute en la misma instancia del servidor de aplicaciones. Sin embargo, no confiaría en esto, ya que probablemente dependa del proveedor.

Utilizamos esta técnica para acceder a la identidad de las personas que llaman en cualquier parte del código. También usamos session beans y jms, pero pasamos explícitamente la información entre contenedores y establecemos ThreadLocal en cada punto de entrada. De esta forma, no importa si el bean (sesión o mdb) es local o no.

Answer 4

Además de todas las otras respuestas, sólo añadiremos lo siguiente:

Normalmente, la única razón para cambiar de hilos es debido a algún requisito para PARALELISMO. Dado que esto normalmente no es gratis en términos de complejidad, generalmente se le informará claramente cuando esto suceda.

La conversión de subprocesos dentro de lo que parece ser un procesamiento de subproceso único de una solicitud es realmente extremadamente compleja. Esto normalmente solo ocurrirá en un lugar en un contenedor, y esto generalmente es manejado por lectores de socket tcp/ip que reciben la solicitud de los clientes externos. Estos subprocesos de lector suelen determinar qué subproceso (grupo) debe procesar la solicitud y reenviar la solicitud a ese subproceso. Después de eso, la solicitud se mantiene con ese hilo.

Normalmente, lo único que ocurrirá o sucederá es que se crean subprocesos adicionales para la paralelización o el procesamiento asíncrono (como JMS).