[quote=Maurício Linhares]Desde quando o uso de caches como o memcached não é transparente?
Isso vai ser tão transparente quanto você fizer ser. Em rails por exemplo você pode fazer cache de objetos que vão ser carregados pelo ActiveRecord usando memcached sem alterar nada das suas interfaces públicas, mesma coisa com o Hibernate em Java usando caches distribuúidos como JGroups.
[/quote]
Vc ta confundindo cache com sessao; ninguem se importa onde estao os dados da sessao, o container garante o servico.
É transparente para o programador porque nao pertence mais ao seu sistema e sim a sessao do usuario.
REST seria completamente diferente porque nao ha sessao de usuario. Curioso que dizem que a web foi construida seguindo os principios do REST!
[quote=Maurício Linhares]
Guardar em um banco de dados pode ser o ideal, especialmente se esse banco de dados puder ser apenas o banco de dados das sessões (claro que isso depende do seu tamanho)[/quote]
Mas o banco de dados é um dos elementos mais difíceis de se escalar, não? Além disso, idealmente os dados que se coloca em sessão são dados “temporários”, dados com um tempo de vida relativamente curto. O pessoal não tem usado mais o esquema de colocar a session no memcached?
[quote=Rubem Azenha][quote=Maurício Linhares]
Guardar em um banco de dados pode ser o ideal, especialmente se esse banco de dados puder ser apenas o banco de dados das sessões (claro que isso depende do seu tamanho)[/quote]
Mas o banco de dados é um dos elementos mais difíceis de se escalar, não? Além disso, idealmente os dados que se coloca em sessão são dados “temporários”, dados com um tempo de vida relativamente curto. O pessoal não tem usado mais o esquema de colocar a session no memcached?[/quote]
Uma coisa: escalabilidade != performance.
O tempo de acesso a memória não é constante, ela diminui à medida que mais coisas estão armazenadas nela. Numa situação onde tudo está no banco, o consumo de memória é menor e a aplicação consegue rodar mais rápido. Com isso, o tempo de execução geral pode ser menor do que se houvesse sessão, mesmo fazendo um acesso ao banco toda a hora. É questão de fazer um profile e ver o que é melhor em cada caso, acesso ao banco ou acesso à memória.
Gente, não achem que cache e sessão é a mesma coisa porque “é tudo armazenado na memória”. Não são a mesma coisa! Um cache está associado a políticas de armazenamento e de descarte definidos por alguma configuração. Sessão é somente um saco de memória associado a um id; se existir política, ela é misturada à logica da aplicação.
Nem sempre os desenvolvedores usam sessão para objetos temporários, usa mesmo é para cache. Porém é um risco, uma vez que já existem soluções prontas e que essa lógica de cache vai ser difícil de manter.
O que acontece é que em REST você mandaria o seu caminho pra sessão direto na URL (ou em um cookie) e o servidor iria buscar essa informação em algum lugar que não fosse ele mesmo, não é que a sessão não exista, mas ela não fica mais no servidor web nem é simplesmente uma “sessão HTTP”.
Simplificando, eu diria que a URL “seria” entao o resource e vc tem resource-state e nao mais session state. Cookies apesar de serem uma forma de armazenar resource state pra nao depender do contexto do servidor é uma forma nao padronizada (o que colabora pra falta de enderecabilidade da informacao, neste caso foi perdida).
IMO da forma que existem hoje cookies nao devem ser utilizados em aplicações REST.
[quote=rodrigoy]Essa linha “find” acima é bem repetitiva no meu controller. Isso não gera um overhead grande no banco?
[…] enfiava as coisas na sessão pra não gerar este overhead. […] É uma boa estratégia fazer o mesmo com o Rails?[/quote]
Eu diria que não - pras duas. Não acho que seja um overhead “grande” no banco. E mesmo que fosse, não diria pra usar a sessão como forma de contornar - acredito que gera mais problemas do que soluções. De qualquer forma, excesso de leituras não é lá um problema muito grave - seria mais “barato”, caso necessário, “escalar” o banco de dados (ou adotar um esquema de cache) sem fazer mudanças na aplicação.
