component - ¿Son seguros los subprocesos administrados de JSF 2.x @ViewScoped?

composite component jsf

Question

He estado buscando en Google por un par de horas en este tema para no evaluar.

Los documentos de WELD y las especificaciones de CDI son bastante claros con respecto a la seguridad de subprocesos de los ámbitos proporcionados.

Por ejemplo:

• Ámbito de aplicación - no es seguro

• Alcance de la sesión - no es seguro

• Solicitar alcance: seguro, siempre vinculado a un solo hilo

• Ámbito de conversación: seguro (debido al proxy de WELD que serializa el acceso desde múltiples subprocesos de solicitud)

No puedo encontrar nada en el alcance de vista definido por JSF 2.x.

Es más o menos el mismo grupo que el alcance de la conversación, ya que es muy posible que múltiples solicitudes lleguen al alcance simultáneamente, a pesar de estar vinculado a una sola vista / usuario. Lo que no sé es si la implementación de JSF serializa el acceso al bean desde múltiples solicitudes.

¿Alguien tiene conocimiento de la especificación o de las implementaciones de Morraja / MyFaces que podrían aclarar esto?

Answer 1

El alcance de la vista es con uso normal seguro de subprocesos. Puede ser utilizado por una sola ventana / pestaña del navegador. Es decir, está codificado por un campo de entrada oculto único que se establece en la solicitud GET inicial. Todas las devoluciones en la misma vista utilizarán el mismo frijol de una misma vista. El propio navegador ya "sincroniza" las solicitudes de devolución en la misma ventana / pestaña. Una nueva ventana / pestaña del navegador es efectivamente una nueva solicitud GET y, por lo tanto, creará una vista nueva y completamente independiente.

En cuanto a las devoluciones de datos ajax, son por especificación en cola. Esto se menciona en el capítulo 13.3.2 de la especificación JSF 2 :

13.3.2 Cola de solicitud de Ajax

Todas las solicitudes de Ajax se deben colocar en una cola de solicitudes del lado del cliente antes de que se envíen al servidor para garantizar que las solicitudes de Ajax se procesen en el orden en que se envían. La solicitud que ha estado esperando en la cola por más tiempo es la siguiente solicitud que se enviará. Una vez que se envía una solicitud, la función de devolución de llamada de la solicitud Ajax debe eliminar la solicitud de la cola (también conocida como puesta en cola). Si la solicitud se completó correctamente, debe eliminarse de la cola. Si hubo un error, se debe notificar al cliente, pero la solicitud aún debe eliminarse de la cola para que se pueda enviar la siguiente solicitud. Se debe enviar la siguiente solicitud (la solicitud más antigua en la cola). Consulte la documentación de JavaScript jsf.ajax.request para obtener más detalles sobre la cola de solicitudes de Ajax.

Solo cuando se utiliza PrimeFaces, la cola se puede desactivar con <p:ajax async="true"> . Cuando se usa esto en combinación con los frijoles de ámbito de vista, la seguridad de subprocesos debe reconsiderarse de la misma manera que para los frijoles de ámbito de sesión.

Ver también:

• Concurrencia de los beans gestionados por JSF de @ApplicationScoped
• Ayúdame a entender el alcance del bean administrado JSF desde la vista de concurrencia
• ¿Cómo elegir el alcance de frijol correcto?

Answer 2

ViewScoped beans ViewScoped se almacenan en un mapa "view" que se crea para cada UIViewRoot . Cuando un tiempo de ejecución JSF procesa dos solicitudes simultáneas, por lo general, es poco probable que se cree / restaure la misma instancia de UIViewRoot para estas solicitudes, ya que el parámetro de formulario javax.faces.ViewState en la solicitud HTTP se usa para determinar si un UIViewRoot existente La instancia debe ser restaurada o no (en la devolución). Como lo ha indicado BalusC, dos ventanas de navegador diferentes darán lugar a la creación de dos beans de vista diferentes, ya que los parámetros de ViewStates subyacentes son diferentes para ambas pestañas del navegador (si está emitiendo dos solicitudes HTTP diferentes y el navegador usa la respuesta de cada una para mostrar las pestañas individuales, en lugar de usar una copia en caché).

La parte sobre seguridad de subprocesos, sin embargo, va más allá de las pestañas / ventanas del navegador. No hay ningún mecanismo inherente dentro del tiempo de ejecución JSF (al menos dentro de Mojarra) que sincronizará el acceso a UIViewRoot y al mapa de vista, si dos solicitudes HTTP (y, por lo tanto, dos javax.faces.ViewState ) presentan el mismo valor javax.faces.ViewState en la solicitud para Ser procesados ​​por el contenedor. Por lo tanto, los beans de vista no son seguros para subprocesos por naturaleza, y tampoco se accede a ellos de una manera segura para subprocesos. Puede confirmarlo reproduciendo las solicitudes con los mismos valores de javax.faces.ViewState y observar el comportamiento del contenedor / JVM cuando el contenedor recibe varias solicitudes de este tipo en poco tiempo (lo que da lugar a la posibilidad de acceso simultáneo al mismo UIViewRoot instancia por múltiples hilos).