17.3. Database Session State
Sessão gravada no banco como dado comprometido; servidor sem estado.
Resumo
- Sessão guardada no banco como dado; servidores ficam sem estado.
- Cada requisição lê a sessão do banco e grava de volta no fim.
- Separe dados de sessão dos dados de registro: campo 'pendente' ou tabelas de sessão separadas.
- Prós: cluster e failover naturais. Contras: custo de leitura/gravação; limpar sessões abandonadas.
- Bom para muitos usuários, cluster sem afinidade e quando a sessão precisa sobreviver a quedas.
Perguntas-chave
responda de cabeça, depois abraComo evitar que dados de sessão apareçam como dados oficiais?
Com um campo de pendência (isPending) ou tabelas separadas para dados de sessão.
Qual a principal vantagem?
Servidores sem estado: qualquer nó atende e a queda de um não perde a sessão.
Qual o custo?
Ida ao banco a cada requisição e necessidade de limpar sessões abandonadas.
Exercícios de fixação
0/5 respondidas1.
Um pedido em edição é gravado com
pendente = true e só vira oficial no 'Finalizar'. Qual padrão?2.
Um relatório de vendas soma pedidos ainda em edição. Que cuidado faltou?
3.
Qual a principal vantagem do Database Session State?
4.
Que tarefa operacional o Database Session State exige?
5.
Qual o custo de desempenho do Database Session State?