java - variables threadlocal en un servlet
multithreading servlets (5)
¿Las variables threadlocals son globales para todas las solicitudes realizadas al servlet que posee las variables?
Estoy usando resina para el servidor.
Gracias por sorpresa.
Creo que puedo ser más claro.
El caso específico:
Quiero:
- Inicialice una variable estática cuando la solicitud inicie la ejecución.
- poder consultar el valor de la variable en las ejecuciones posteriores de los métodos llamados desde el servlet en un modo de seguridad de subprocesos hasta que la solicitud finalice la ejecución
Respuesta corta: Sí.
Un poco más largo: así es como Spring hace su magia. Ver RequestContextHolder (a través de DocJar).
Sin embargo, es necesario tener precaución: debe saber cuándo invalidar el ThreadLocal, cómo diferir a otros hilos y cómo (no) enredarse con un contexto no threadlocal.
O podrías usar Spring ...
Creo que son globales para todas las solicitudes realizadas solo con ese hilo específico. Otros hilos obtienen otras copias de los datos locales del hilo . Este es el punto clave del almacenamiento local de subprocesos: http://en.wikipedia.org/wiki/Thread-local_storage#Java .
A menos que marque la opción apropiada en la configuración de servlets, el contenedor de servlets usará su servlet con múltiples hilos para manejar las solicitudes en paralelo. Entonces, efectivamente, tendrías datos separados para cada hilo que esté sirviendo a los clientes.
Si su aplicación web no está distribuida (se ejecuta en varias máquinas virtuales Java), puede usar el objeto ServletContext para almacenar datos compartidos entre las solicitudes y los hilos (asegúrese de hacer el bloqueo correcto en ese momento).
Las variables de Threadlocal siempre se definen para ser accedidas globalmente, ya que el punto es pasar información de forma transparente alrededor de un sistema al que se puede acceder desde cualquier lugar. El valor de la variable está vinculado al hilo en el que está establecido, de modo que aunque la variable sea global, puede tener diferentes valores según el hilo desde el que se acceda.
Un ejemplo simple sería asignar una cadena de identidad de usuario a un subproceso en una variable local de subproceso cuando la solicitud se recibe en el servlet. En cualquier lugar a lo largo de la cadena de procesamiento de esa solicitud (suponiendo que esté en el mismo hilo en la misma máquina virtual), la identidad se puede recuperar accediendo a esta variable global. También sería importante eliminar este valor cuando se procese la solicitud, ya que el hilo se volverá a colocar en un grupo de subprocesos.
Como dice Adiel, la forma correcta de hacerlo es, probablemente, utilizar el contexto de solicitud (es decir, HttpServletRequest), no crear un ThreadLocal. Si bien es cierto que es posible utilizar un ThreadLocal aquí, debes tener cuidado de limpiar tu hilo si lo haces, ya que de lo contrario la próxima solicitud que obtenga el hilo verá el valor asociado con la solicitud anterior. (Cuando se realiza la primera solicitud con el hilo, el hilo volverá al grupo y entonces la próxima solicitud lo verá). No hay razón para tener que gestionar ese tipo de cosas cuando el contexto de solicitud existe precisamente para este propósito.
El uso de ThreadLocal para almacenar la información del alcance de la solicitud tiene el potencial de romperse si usa Servlet 3.0 Solicitudes suspendidas (o contingencias de Jetty) El uso de múltiples subprocesos de la API procesa una sola solicitud.