Rails vs Component Based

O Rails permite que se grave a session[] no banco. Se eu tiver uma layer/cache entre app->db posso usar a session despreocupadamente?

[comentário paralelo (que não tem haver com a pergunta anterior, não estou dizendo que Seam é melhor)]
Só postando aqui, no Seam não é diretamente a session que usamos, mas sim o conteiner de inject/outject... um Seam Component é cacheable, então, não lidamos com a session diretamente.
[/comentário paralelo]

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

Maurício Linhares wrote:

cmoscoso wrote:E o que é httpSession senao estado do cliente armazenado no cache do servidor?

Não é tão simples assim.

Estado mantido em um cache de verdade (como o cache de segundo nível do Hibernate) está seguro de levar diversos updates e também de mostrar sempre a última versão, um cache em HttpSession não tem isso (a não ser que você mesmo implemente), as informações que estão lá podem perder a validade rápido e você vai ter que dar um jeito de estar sempre "consertando" isso.

Voce esta sugerindo salvar no banco a sessao do usuario ?

cmoscoso wrote:Voce esta sugerindo salvar no banco a sessao do usuario ?

Eu estou sugerindo não ter nada em um lugar que é difícil de escalar e a sessão do usuário em uma aplicação web comum (na memória de um único servdor) não é uma boa idéia. 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), usar memcached também é uma boa idéia, enfim, só não se deve colocar os dados na "sessão http", porque essa não escala de jeito nenhum.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

Maurício Linhares wrote:

cmoscoso wrote:Voce esta sugerindo salvar no banco a sessao do usuario ?

Eu estou sugerindo não ter nada em um lugar que é difícil de escalar e a sessão do usuário em uma aplicação web comum (na memória de um único servdor) não é uma boa idéia. 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), usar memcached também é uma boa idéia, enfim, só não se deve colocar os dados na "sessão http", porque essa não escala de jeito nenhum.

Mas a ideia inicial nao era evitar acesso ao banco?

memcached seria uma estratégia maais "faca vc mesmo" de algo que deveria ser transparente e que envolve questoes de seguranca.

Se escalabilidade for mesmo importante eu consideraria usar REST. Neste caso a sessao se tornaria parte da aplicacao com um resource identificado por uma url; aí é irrelevante se fica cachedo ou nao.

cmoscoso wrote:Mas a ideia inicial nao era evitar acesso ao banco?

Não a minha. Pra mim a idéia inicial é não manter estado num lugar que vai lhe dar trabalho.

cmoscoso wrote:memcached seria uma estratégia maais "faca vc mesmo" de algo que deveria ser transparente e que envolve questoes de seguranca.

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.

cmoscoso wrote:Se escalabilidade for mesmo importante eu consideraria usar REST. Neste caso a sessao se tornaria parte da aplicacao com um resource identificado por uma url; aí é irrelevante se fica cachedo ou nao.

Não sei o que REST traria de diferente, você vai ter que colocar esses dados em algum lugar não vai? Os dados não podem ir na URL, o que vai estar na URL é simplesmente informação pra você ir buscar os dados em algum lugar (um banco de dados, por exemplo).

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

Maurício Linhares wrote: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.

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.

Maurício Linhares wrote:Não sei o que REST traria de diferente, você vai ter que colocar esses dados em algum lugar não vai? Os dados não podem ir na URL, o que vai estar na URL é simplesmente informação pra você ir buscar os dados em algum lugar (um banco de dados, por exemplo).

REST seria completamente diferente porque nao ha sessao de usuario. Curioso que dizem que a web foi construida seguindo os principios do REST!

Maurício Linhares wrote:
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)

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?

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

Rubem Azenha wrote:

Maurício Linhares wrote:
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)

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?

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.

cmoscoso wrote:REST seria completamente diferente porque nao ha sessao de usuario. Curioso que dizem que a web foi construida seguindo os principios do REST!

Não é tão simples assim

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".

This message was edited 2 times. Last update was at 14/06/2008 22:11:14

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.

Java Ninja Membro desde: 18/05/2006 20:04:34 Mensagens: 256 Offline

rodrigoy wrote: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?

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.

Entusiasta Java Membro desde: 07/07/2007 15:26:14 Mensagens: 15 Offline

Tudo bem pessoal?

Achei muito interessante os comentários de vocês e resolvi falar do tema "Escalabilidade =! Performance" no blog:

http://manifestonaweb.wordpress.com/2008/06/18/escalabilidade-performance/

Suas ótimas opiniões foram relevantes para escrever o post, obrigado!

Notícias, artigos e o maior fórum brasileiro sobre Java