Adicionar a Meu favorito

Wednesday, 24 de October de 2007

Os aplicativos Web têm um problema intrínseco que os programas Windows nunca tiveram: como manter um valor disponível em todo o aplicativo. Em um programa Windows basta colocar o valor em uma variável global e pronto. Já os programas Web sofrem uma séria deficiência: como o protocolo HTTP não mantém uma conexão entre as chamadas das diferentes páginas, temos que encontrar algum mecanismo para passar informações de uma página para outra. Esta informação pode ser, por exemplo, um carrinho de compras ou um identificador do usuário.

O mecanismo usado tanto nos programas ASP tradicional como em programas ASP.NET® é basicamente o mesmo: variáveis de sessão. As variáveis de sessão funcionam como dicionários, onde o aplicativo armazena uma chave (uma string ou número inteiro) e um valor (número, strings e vários outros tipos). O interessante é que cada sessão tem uma cópia deste dicionário, esse conjunto dos pares chave-valor. Uma sessão corresponde, a grosso modo, a uma cópia de um navegador acessando o site. Como o servidor não tem como saber se um navegador remoto foi fechado (já que o protocolo HTTP não mantém conexão), as variáveis deixam de existir por "timeout", normalmente no prazo de vinte minutos.

Para implementar as variáveis de sessão, o ASP e o ASP.NET têm basicamente duas preocupações:

* O navegador remoto deve ser capaz de identificar qual dicionário é "dele". Este identificador é uma "chave" na base de dados das variáveis de sessão;
* A base de dados com todos os dicionários deve ser implementada de alguma forma, em algum servidor.

No ASP tradicional o identificador de sessão é sempre um "cookie" de sessão e a base de dados fica sempre na memória do servidor. Embora eficientes, este mecanismo pode ter alguns problemas:

* O suporte a cookies pelo navegador pode ser desligado pelo usuário. Alguns usuários confundem os "cookies de sessão" - temporários e inofensivos - com "cookies armazenados", que gravam informações no computador que acessa o site;
* O fato da base de dados residir na memória do servidor Web dificulta a implementação de sites de muito movimento, onde vários servidores Web servem as mesmas páginas. O problema é que se uma sessão é iniciada em um determinado servidor, os outros servidores não podem mais servir aquele usuário, já que apenas um deles enxerga os valores das variáveis de sessão. Existem formas de contornar este problema, mas nenhuma é perfeita.

O ASP.NET resolve os dois problemas acima. Em primeiro lugar, é possível implementar sessões sem cookies. Em segundo lugar, é possível armazenar a base de dados de sessão de vários servidores Web em um único "servidor de sessão", na rede. Estas opções são especificadas no arquivo de configuração web.config, localizado no mesmo diretório do aplicativo Web.

Entradas no web.config

As entradas que controlam as variáveis de sessão estão sob a tag session. Veja as opções possíveis:

Tag - Significado

Mode - Indica onde são armazenadas as variáveis de sessão.

InProc: Memória do servidor (padrão, igual ao ASP tradicional)
StateServer: Servidor de sessão
SQLServer: Servidor SQL Server
Off: Variáveis de sessão desligadas

Cookieless - Indica se a sessão usará cookies ou não.

False: Com cookies, igual ao ASP tradicional
True: Sem cookies

timeout - Tempo em minutos até que sessões sem uso sejam abandonadas. O padrão é vinte minutos.

stateConnectionString - Nome do servidor e porta usado para a opção mode=StateServer.

sqlConnectionString - String de conexão SQL para a opção mode=SQLServer.

Veja um exemplo completo:



Sessões sem cookies

Para implementar sessões sem cookies, basta abrir o arquivo web.config no Visual Studio .NET ou outro editor de textos, modificar a tag cookieless para true e salvar o arquivo:



Nada mais precisa ser feito. Observe que a URL passa a conter uma string "mágica". Esta string é a mesma usada no cookie quando cookieless=false e também é a chave usada em todos os bancos de dados.

Mudando o local de armazenamento

Servidor de sessão

O valor padrão de Mode é InProc, onde a base de dados é armazenada na memória do próprio servidor Web. Podemos armazenar a base em um "servidor de sessão" específico mudando a tag Mode para StateServer. Precisamos dizer quem é o servidor de sessão na tag stateConnectionString:



O número "42424" é a porta TCP padrão usada pelo servidor de sessão.

Este servidor de sessão roda um serviço especial chamado "ASP.NET State Service". Este serviço é normalmente instalado junto com o resto do ASP.NET e fica no executável WINDOWSMicrosoft.NETFrameworkversaoaspnet_estate.exe.". Você pode visualizá-lo junto aos outros serviços:

Evidentemente, o servidor de sessão normalmente não fica no mesmo computador que o servidor Web e sim em um computador dedicado. Note também que ele deve ser ligado manualmente, pois seu estado inicial é desligado com início manual.

SQL Server

Para usar o SQL Server 2000 como servidor de sessão, temos que modificar alguns ajustes no web.config e também criar um banco de dados no servidor. Os ajustes no web.config são os seguintes:



sqlConnectionString é a string de conexão ao SQL Server. Ela identifica o nome do servidor, nome e senha usados na conexão. Evidentemente serão diferentes dos valores mostrados acima.

Você deve também criar o banco de dados rodando o script "InstallSqlState.sql", normalmente a partir do diretório "WINDOWSMicrosoft.NETFrameworkv1.0.XXXX".

Rode o "SQL QueryAnalyzer", abra o script e execute-o:

Não é criada nenhuma tabela, e sim várias "stored procedures", estas sim capazes de criar tabelas temporárias. Você pode eliminar o banco de dados rodando o script "UninstallSqlState.sql".

Vantagens de cada modo

Cada modo tem as suas vantagens e desvantagens. InProc oferece a melhor performance de todas, sendo o modo mais recomendável quando apenas um servidor é usado. Já StateServer tem melhor performance que SQLServer e também compatibilidade com "WebFarms". SQLServer também é compatível com "WebFarms", mas com melhor confiabilidade que StateServer, pois o SQL Server pode ser instalado em um "cluster".

Por Mauro Sant'Anna ([email protected]). Mauro é um "MSDN Regional Director", consultor e instrutor da MAS Informática (www.mas.com.br), tendo ministrado treinamentos na arquitetura .NET desde outubro de 2000.

Outros artigos

Assine o Feed desta categoria

• Imagem de Segurança - CAPTCHA - 04/10/2007
• Debugando aplicações web no Visual Studio 2005 com firefox - 23/09/2007
• Server.Transfer ou Response.Redirect - 14/09/2007
• Remover som no evento KeyDown - 30/07/2007
• Ver mais...

Comentários do artigo [Novo comentário]