Recientemente, cuando trabajaba en un proyecto, algunas páginas necesitaban cargar muchos datos, y a veces hacía clic en la página sin esperar a que terminara de cargarse, y luego volvía a hacer clic en otra página
Habrá un estado muy lento de animación suspendida al cargar la página web, así que estudiémoslo detenidamente hoy.
Al principio pensé que esta situación ocurriría en muchas webs o que el problema de velocidad de mi red informática, pero descubrí que esta web no tenía esta situación; a veces me quedaba atascado al publicar, pero hice clic en otras páginas de la pestaña para cargar rápido.
¡Vamos a echar un vistazo más de cerca hoy! El código probado primero:
Código Homeview:
Código del controlador:
Para el análisis de código de prueba, nuestro controlador tiene 3 métodos: uno es la página principal y los otros dos son métodos de prueba
El Test1 solicita bloqueos durante 5 segundos y luego devuelve los datos al usuario
Las peticiones Test2 no se bloquearán y devolverán los datos directamente al usuario
Nuestra página principal tiene dos interfaces para las solicitudes Ajax, que son solicitudes asincrónicas, así que no hay problema de bloqueo.
Veremos que el método Test1 solo genera contenido después de que Test2 produzca contenido (Normalmente, la página genera el contenido devuelto directamente por Test2 y luego espera 5 segundos para que se genere el contenido devuelto por Test1, porque js no bloquea)
Luego, accedemos directamente a las interfaces de Test1 y Test2, accedemos primero a Test1 y luego inmediatamente a Test2, y vemos que Test2 debe esperar hasta que Test1 regrese a completarse, como se muestra en la figura siguiente:
Si una solicitud de página establece un bloqueo de lector, otras solicitudes que se procesan al mismo tiempo en la misma sesión no podrán actualizar el estado de la sesión, pero al menos podrán ser leídas. Si una página solicita un bloqueo de escritura para el estado de la sesión, entonces todas las demás páginas quedan bloqueadas, independientemente de si quieren leer o escribir contenido. Por ejemplo, si dos vistas de programa están escribiendo contenido en la misma sesión al mismo tiempo, un programa debe esperar a que el otro esté terminado antes de poder escribirse. En la programación AJAX, es importante ser consciente de que esto ocurre.
Nota especial: Solo al escribir una sesión, Asp.net bloqueará la solicitud, pero siempre que hayas visitado la página donde se escribe la sesión, como la operación tras iniciar sesión con la sesión (la sesión está bloqueada hasta que expira, por supuesto, solo es el caso de que el SessionID sea el mismo). Habrá este problema.
Información para internautas
Mientras el sitio web utilice una sesión, cada solicitud bloqueará la sesión durante toda su vida útil, por lo que las solicitudes con el mismo sessionid deben esperar a ser desbloqueadas
Esto significa que si la página tiene una página con tiempo muerto, no puede hacer nada y tienes que esperar a que cargue la página con tiempo limitado.
Tú tampoco puedes hacerlo, varias solicitudes ajax simultáneas en la misma página, no puedes hacerlo, solicitudes de sondeo por mensajes.
En resumen:Si aceptas una sesión a la solicitud, si no aportas una sesión a la solicitud, la situación anterior no ocurrirá
Solución:
Se añadió la función SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly) al controlador controlador
Nota:
Obligatorio significa que estás solicitando un bloqueo exclusivo en Session (es decir, no hay procesamiento paralelo de solicitudes para el mismo Session ID) Solo lectura significa que estás solicitando un bloqueo no exclusivo en Sesión (es decir, tu solicitud aún tiene que esperar a que finalice las solicitudes con bloqueo exclusivo, pero puedes procesar solicitudes con bloqueo no exclusivo cerraduras en paralelo. Sin embargo, depende de ti asegurarte de que tu código no escriba en Session. No necesariamente está obligado por el marco) Obligatorio significa el mutex de sesión que solicitaste (es decir, no hay requisito de procesar el mismo SessionID en paralelo)
Solo lectura significa que la sesión que solicitas es un bloqueo no exclusivo (es decir, tu solicitud aún tiene que esperar a completarse, la solicitud de bloqueo exclusivo, pero puedes procesar una solicitud con un bloqueo paralelo no exclusivo). Pero quieres asegurarte de que tu código no escriba sesiones. No tiene que ser ejecutado por el framework)
|