Recentemente, quando eu estava trabalhando em um projeto, algumas páginas precisavam carregar muitos dados, e às vezes eu clicava na página sem esperar ela terminar de carregar, e depois clicava em outra página novamente
Haverá um estado muito lento de animação suspensa ao carregar a página web, então vamos estudar isso com atenção hoje.
No começo, achei que essa situação aconteceria em muitos sites ou que o problema de velocidade da minha rede de computadores, mas percebi que esse site não tinha essa situação, às vezes eu travava ao postar, mas clicava em outras páginas da aba para carregar rápido.
Vamos dar uma olhada mais de perto hoje!! O código testado primeiro:
Código Homeview:
Código do Controlador:
Para análise de código de teste, nosso controlador possui 3 métodos: um é a página inicial e os outros dois são métodos de teste
O Test1 solicita bloqueios por 5 segundos e então retorna os dados ao usuário
Solicitações Test2 não bloqueiam e retornam dados diretamente ao usuário
Nossa página inicial tem duas interfaces para requisições Ajax, que são solicitações assíncronas, então não há problema de bloqueio.
Vamos descobrir que o método Test1 gera conteúdo apenas depois que Test2 gera conteúdo (Normalmente, a página gera o conteúdo retornado diretamente pelo Test2 e então espera 5 segundos para gerar o conteúdo retornado pelo Test1, porque o js não bloqueia）
Depois, acessamos diretamente as interfaces Test1 e Test2, acessamos primeiro o Test1 e então imediatamente acessamos o Test2, e descobrimos que o Test2 deve esperar até que o Test1 volte a completar, como mostrado na figura abaixo:
Se uma requisição de página estabelece um bloqueio de leitor, outras solicitações que estejam sendo processadas ao mesmo tempo na mesma sessão não poderão atualizar o estado da sessão, mas pelo menos podem ser lidas. Se uma página solicitar um bloqueio de escrita para o estado da sessão, então todas as outras páginas são bloqueadas, independentemente de quererem ler ou escrever conteúdo. Por exemplo, se duas visualizações de programa estiverem escrevendo conteúdo na mesma sessão ao mesmo tempo, um programa deve esperar até que o outro esteja finalizado antes que possa ser escrito. Na programação AJAX, é importante estar ciente disso acontecendo.
Nota especial: somente ao escrever uma sessão, Asp.net bloqueará a solicitação, mas desde que você tenha visitado a página onde a sessão foi escrita, como a operação após fazer login no sistema com a sessão (a sessão fica bloqueada até expirar, claro, é só o caso de o SessionID ser o mesmo). Vai ter esse problema.
Informações para internautas
Enquanto o site usar uma sessão, cada requisição irá bloquear a sessão durante toda a sua vida útil, então as requisições com o mesmo sessionid devem aguardar para serem desbloqueadas
Isso significa que, se o site tiver uma página com tempo de expiração, ele não pode fazer nada, e você precisa esperar a página com tempo limitado carregar.
Você também não pode fazer, múltiplos pedidos ajax simultâneos na mesma página, você não pode fazer, solicitações de consulta de mensagens.
Para resumir:Se você levar uma sessão ao pedido, se não levar uma sessão ao pedido, a situação acima não ocorrerá
Solução:
Adicionada a funcionalidade SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly) ao controlador controlador
Nota:
Obrigatório significa que você está solicitando um bloqueio exclusivo na Sessão (ou seja, sem processamento paralelo de solicitações para o mesmo SessionID)
ReadOnly significa que você está solicitando um bloqueio não exclusivo na Sessão (ou seja, seu pedido ainda precisa esperar que os pedidos com bloqueio exclusivo terminem, mas você pode processar pedidos com bloqueio não exclusivo Fechaduras em paralelo. No entanto, cabe a você garantir que seu código não escreva no Session. Não é necessariamente aplicado pelo framework)
Somente Leitura significa que a sessão que você solicita é um bloqueio não exclusivo (ou seja, sua solicitação ainda precisa esperar a conclusão, a solicitação de um bloqueio exclusivo, mas você pode processar uma solicitação com um bloqueio paralelo não exclusivo). Mas você quer garantir que seu código não escreva sessões. Não precisa ser executado pelo framework)
|
Publicado em 22/09/2017 17:32:59
|
|
|
|
Senhorio