Todos os dados na sessão, afinal memória é infinita

O título é brincadeira, mas reflete bem a realidade, é muito comum encontrar aplicações web que simplesmente acreditam que todos os dados podem ser guardados na sessão. Que a medida que os usuários tem sua sessão invalidada, o garbage collector irá cuidar de destruir tudo.

Este tipo de problema não existiria se a aplicação fosse usada por alguns poucos usuários. Tentem imaginar centenas de atendentes de telemarketing, trabalhando continuamente, entrando em todas as telas possíveis do sistema, executando todo o tipo de ações, e em cada ação mais e mais dados na sessão que somente serão retirados após 6 horas de jornada de trabalho (ou pelo menos deveriam ser 6 horas perante a lei trabalhista, não vou entras nestes detalhes =D). Mas e aí, nestas condições, quanto tempo até chegarmos a um OutOfMemory ?

É muito fácil colocar algo na sessão, por exemplo a lista de cidades de um estado, se a intenção é ajudar no desempenho, esta é a pior estratégia que se pode escolher. Para isso que existem excelentes técnicas de caching e várias bibliotecas que as implementam, a qual garantirá que existe apenas uma única lista em cache para qualquer usuário, além de implementar o padrão Observer para possíveis alterações na lista.

Claro que não estou dizendo que devemos banir o uso de sessões, muito pelo contrário, devemos usá-la, mas tome o cuidado de gerenciar o conteúdo. Um meio simples de se fazer isso é controlar todas as requisições via Servlet Filter em Java ou Filters em Rails, colocando/retirando dados conforme a necessidade.

Tão ruim quanto já colocar tudo na sessão é utilizar péssimas chaves, por exemplo:

JAVA:
  1. session.setAttribute("customerId", id);

Não sabemos de onde veio isso, para onde vai e pior ainda, alguma outra ação pode sobrescrever este valor. Sem uma identificação correta, nem um controle com filtros vai ajudá-lo.

Pensem duas vezes antes de usar o escopo session, em boa parte dos casos usar os escopos page e request é suficiente, analisem cada situação, vai tomar pouquíssimo tempo e cada bit de memória economizado é bem vindo. Há o velho pensamento: "Depois faço um profiling para eliminar alguns gargalos", isto só irá trazer várias dores de cabeça em um código session-macarrônico.

Deixe seu comentário