O que colocar em uma variável de sessão

Question

Eu vim recentemente através de uma ASP 1.1 aplicação web que colocar um montão de coisas na variável de sessão, incluindo todos os dados do bd objetos e até mesmo o DB objeto de conexão.Ele acaba por ser enorme.Quando o web sessão expirar (quatro horas após o utilizador terminar de usar o aplicativo), algumas vezes, as transações de banco de dados se rolou para trás.Eu estou supondo que isso é porque a conexão do DB não está a ser bem fechada quando o IIS mata a sessão.

De qualquer maneira, a minha pergunta é o que deve ser a variável de sessão?Claramente, algumas coisas precisam ser lá.O usuário seleciona qual o plano que deseja editar na tela principal, de modo que o plano de identificação vai para a variável de sessão.É melhor tentar e reduzir a carga na base de dados armazenando todos os detalhes sobre o usuário (e a sua manager, etc.) e o plano que está a editar a variável de sessão ou devo tentar minimizar coisas na variável de sessão e consulta o banco de dados para tudo que eu preciso no evento Page_Load?

Answer 1

Isso é muito difícil de responder, porque é muito específica do aplicativo, mas aqui estão algumas orientações que eu uso:

1. Usar o mínimo possível na sessão.
2. Usuário seleções específicas que devem durar apenas durante uma visita à são uma boa escolha
3. muitas vezes, variáveis que precisam ser acessíveis para várias páginas, durante a visita do usuário ao seu site (para evitar passá-los de uma página para outra) também são bons para colocar na sessão.

Do pouco que você disse sobre a sua aplicação, eu provavelmente selecione os dados a partir do banco de dados e tentar encontrar maneiras de minimizar o impacto dessas consultas em vez de carregar para baixo a sessão.

Answer 2

Fazer não colocar o banco de dados de informações de conexão na sessão.

Na medida em cache, eu gostaria de evitar a utilizar a sessão para o cache, se possível, você vai correr em problemas onde alguém altera os dados de um usuário está usando, além disso, você não pode compartilhar o cache de dados entre os usuários.Use o ASP.NET Cache, ou algum outro utilitário de cache (como o Memcached ou Velocidade).

Tanto quanto o que deve vá na sessão, qualquer coisa que se aplica a todos janelas do browser de um utilizador tem de abrir para o seu site (login, configurações de segurança, etc.) deve ser na sessão.Coisas como o que o objeto está a ser visualizados e/ou editado deve ser realmente GET/POST variáveis são passadas entre as telas de modo que um usuário pode utilizar várias janelas do navegador para funcionar com a sua aplicação (a menos que você gostaria de impedir que).

Answer 3

NÃO colocar objetos de INTERFACE do usuário na sessão.

além do que, eu diria que ela varia.muito em sessão pode atrasar você para baixo se você não estiver usando-o no processo de sessão porque você está indo ser serialização muito + a velocidade do fornecedor.Cache e a Sessão deve ser usado com moderação e cuidado.Não basta colocar em sessão porque você pode ou é conveniente.Sentar e analisar se faz sentido.

Answer 4

Idealmente, a sessão em ASP deve armazenar a menor quantidade de dados que você pode começar afastado com.Armazenar uma referência para qualquer objeto que está segurando recursos de sistema aberto (especialmente uma conexão de banco de dados) é um definitivo escalabilidade assassino.Além disso, o armazenamento de dados não confirmados em uma variável de sessão é apenas uma má ideia, na maioria dos casos.No geral parece que a implementação atual é de forma abusiva usando objetos de sessão para tentar simular um aplicativo com monitoração de estado em um suposto ambiente sem estado.

Apesar de muito criticado, o ASP.NET modelo de gestão do estado, automaticamente, através de campos ocultos deve-se realmente a eliminar a maioria da necessidade de manter tudo em variáveis de sessão.

Minha regra de ouro é que o mais escalável (em termos de usuários/hits) que o aplicativo precisa ser, a menos que você pode começar afastado com o uso de estado de sessão.No entanto, há um trade-off.Para aplicativos da web onde o usuário é repetidamente acessando os mesmos dados e, normalmente, tem bastante longa sessão de acordo com o uso do site, de alguns cache (se necessário, em sessão de objetos) pode realmente ajudar a escalabilidade, reduzindo a carga no servidor de banco de dados.A idéia aqui é que ele é muito mais barato e menos complexa para a fazenda a camada de apresentação que o back-end DB.É claro que, com todas as coisas, este conselho deve ser tomado com moderação e não se aplica em todas as situações, mas de uma forma bastante simples em casa CRUD app, deve servir bem.

Answer 5

Um muito semelhante pergunta foi perguntado a respeito de PHP sessões anteriores.Basicamente, as Sessões são um ótimo lugar para armazenar dados específicos do usuário que você precisa para acesso através de vários carregamentos de página.As sessões NÃO são um ótimo lugar para guardar conexão de banco de dados de referências;você seria melhor usar algum tipo de conexão de pool de software ou abrir/fechar sua conexão em cada carregamento de página.Na medida do cache de dados na sessão, isso depende de como os dados da sessão está sendo armazenado, quanto a segurança que você precisa, e se ou não os dados é específica para o usuário.Uma melhor aposta seria a de usar algo diferente para o armazenamento de dados em cache.

Answer 6

armazenar a navegação dicas em sessões é complicado.O mesmo usuário pode ter várias janelas abertas e, em seguida, as alterações são propagadas de uma maneira confusa.Conexões a banco de dados deve definitivamente não serão armazenados.ASP.NET mantém o pool de conexão para você, não há necessidade de recorrer a seu próprio feitiço.Se você necessitar de um cache de coisas por curtos períodos de tempo e tamanho do conjunto de dados é relativamente pequena, olhar para ViewState como uma opção possível (com o custo de carregamento de mais massa para o tamanho da página)

Answer 7

A:De dados que é apenas em relação ao usuário.Ou seja:um username, um ID de usuário.No mais um objeto que representa um usuário.Às vezes URL relativo de dados (como onde levar alguém) ou uma mensagem de erro de pilha são muito úteis para empurrar para a sessão.

Se você deseja compartilhar coisas potencialmente entre diferentes usuários, use o Aplicativo de armazenamento ou o Cache.Eles são muito superiores.

Answer 8

Stephen,
Você trabalha para uma empresa que começa com "eu", que tem um site que começa com "BC"?Que soa exatamente como o que eu fiz quando eu comecei a desenvolver em .net (e era jovem e estúpido) -- eu a abarrotar de tudo que eu poderia pensar em sessão e de aplicação.Escusado será dizer, que foi duas vezes mais ungood.
Em geral, abster-se da sessão o máximo possível.Certamente, não serializáveis objetos não devem ser armazenados lá (conexões de banco de dados e tal), mas mesmo grande, serializable objetos não deveria ser.Você só não quer a sobrecarga.

Answer 9

Gostaria de manter sempre muito pouca informação em sessão.Sessões de servidor de uso de recursos de memória que é caro.Salvar muitos valores na sessão aumenta a carga no servidor e eventualy o desempenho do site vai para baixo.Quando você usar o equilíbrio de carga de servidores, o uso de sessão pode executar em problemas.Então o que eu faço é usar o mínimo ou nenhum sessões, usar cookies, se a informação não é muito crítico, usar campos ocultos mais e sessões de banco de dados.