Gerar url com dados dinamicos
16/09/2010 00:00
0
Olá,

Eu queria passar um parametro dinamico em todas as URIs, tipo passar no final da url alguma identificacao do usuario, pra enganar o cache, tipo o post do kico pra atualizacao do css <!-- m --><a class="postlink" href="http://www.itexto.net/devkico/?p=763">http://www.itexto.net/devkico/?p=763</a><!-- m -->.

Mas será que terei q ajustar link por link, ou tem algum esquema de fazer no UrlMappings? Porque eu tentei o UrlMappings mas nao consegui.

Obrigado
Tags: Tópicos avançados


0
Fala bruto!

Você pode usar o Caching Headers Plugin: <!-- m --><a class="postlink" href="http://www.grails.org/plugin/cache-headers">http://www.grails.org/plugin/cache-headers</a><!-- m -->

Com ele você diz como a resposta da action será cacheada (ou não).

Ahh, vale lembrar que o cache é seu AMIGO, e não o contrário. Ele está aí para evitar que sua aplicação seja sobrecarregada. Ou seja, não podemos simplesmente passar a usar isso em todos os lugares, já que a aplicação sofreria uma sobrecarga...

A palavra é: responsabilidade <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) -->

[]s,
16/09/2010 00:00


0
carlinbegale,

seguinte: neste post eu falo pra enganar o cache APENAS para um ou outro recurso ESTÁTICO (e estes são raros) em sua aplicação.
No caso do Ajax, inclusive, ele deve ser aplicado também apenas em situações nas quais os dados sejam muito dinâmicos (e na boa, só tive problema com cache ao usar requisições assíncronas com o IE). Por muito dinâmicos, eu digo mudanças que ocorram em um registro em coisa do tipo varias vezes por hora, por exemplo, o que costuma ser raro.

No caso do CSS, por exemplo, isto se aplica legal, porque há situações nas quais você altera o layout do seu site e quer evitar do seu usuário acessar uma página toda bagunçada por causa do cache. Mas repara uma coisa: eu só &quot;enganei&quot; o cache do navegador uma vez. Não foi a cada requisição. Foi uma vez a cada release da aplicação, entende?

No geral, o ideal é que seu navegador chegue o mínimo possível ao servidor. Em aplicações pequenas, com pouco tráfego, o cache não faz tanta diferença. Afinal de contas, o servidor raríssimas vezes vai ficar sobrecarregado. O bicho pega conforme sua aplicação vai crescendo. Imagine que a cada requisição você envie para o seu cliente uma nova cópia do CSS, das imagens, etc. O bichinho simplesmente vai arriar, saca?


0
olá pessoal, obrigado pela resposta.

Entao, eu tentei varias coisas (estao no outro post de troca de usuario) mas nada funcionou, e pelo ultimo teste parece q o problema é no cache, que esta mostrando a tela de 1 usuario para o outro usuário. A unica forma q solucionamos em um dos clientes foi tirando o cache do firewall de lá. Pode ser que sobrecarregue o servidor mesmo como vocês falaram, mas com o cache tava impossivel eles usarem o sistema lá. E sem funcionou. Vocês vêem alguma outra solução. Porque eles utilizam o sistema ao mesmo tempo, e no mesmo laboratório, da mesma rede.

Abraços
16/09/2010 00:00


0
Sugestão:

você verificou se sobrescreveu o método equals das suas classes de domínio? As chaves primárias das tabelas estão ok? Digo: já verificou se, por algum acaso do destino, não há o mesmo id para dois registros diferentes no BD?
Qual servidor de aplicações você está usando?

Quando um usuário se autentica no seu sistema, o nome do usuário que aparece é de outro?


0
olá kico,

Eu nao sobrescrevi o metodo equals.
As chaves primarias são o id (gerado automaticamente pelo grails), e estão ok, verifiquei o banco e está gerando corretamente, sem duplicidade.
Estou usando o Tomcat.

Agora vou tentar explicar detalhadamente o que aconteceu no teste, porque eu estava achando que todos estavam acessando uma mesma sessao, mas não, eu penso que seja o cache por isso:

- O usuario 1 acessa faz login do sistema e vai para a area inicial da empresa, lá ele tem um cabecalho com nome da sua empresa e o seu nome.
- Entao o usuario 1 navega pra outra area dentro da empresa e o cabecalho continua correto com nome dele e da empresa.

- Dai o usuário 2 faz login de outra maquina dentro do mesmo laboratorio (mesma rede) e cai na area inicial da empresa com o nome da sua empresa e seu nome corretos.
- Entao o usuario 2 vai para outra area da empresa (a mesma area que o usuario 1 entrou), e o cabecalho do usuario 2 muda, aparecendo os dados da empresa e nome do usuario 1.

- Entao fizemos um teste e atualizamos a pagina (com CTRL + F5) do usuario 2 (que estava aparecendo os dados do usuario 1) e apareceu corretamente os dados do usuario 2 (como se estivesse pegando os dados do usuario 1 do cache - penso eu, e quando atualizamos foi no servidor e carregou os dados corretos)

- Mas dai o usuario 1 que estava navegando corretamente volta pra essa mesma area ai de novo, e agora passa a ver os dados do usuario 2 (que atualizou com CTRL + F5), e só corrige se atualizar esta pagina de novo. Entao esta aparecendo os dados do ultimo que atualizou, entende.

Bom é mais ou menos isso que está acontecendo, nao sei se consegui me explicar bem.

Abraço
16/09/2010 00:00


0
Oi Carlin,

bom: é esquisito mesmo este seu problema. Então vamos pensar em como o servidor de aplicações lida com as sessões ok? Pra cada usuário, ele vai criar uma sessão única, identificada por um número normalmente chamado de sessionid.

Há duas possibilidades: o servidor pode persitir os dados da sessão em um arquivo ou então mantê-los em memória por um tempo (se não me engano da até pra configurar o Tomcat neste quesito).

Então vamos supor que chegou o usuário 1. Ele se autentica, e na autenticação, é criada uma sessão para ele. Vamos chamá-la de 1.

Em seguida, chega o usuário 2, que também se autentica da mesma forma e em seguida é criada uma sessão para ele. Vamos chamá-la de 2.

A sessão 1 é na realidade um map, cujos valores acessamos a partir de chaves. Por exemplo: session.idUsuario retornaria o id do usuário, session.usuario poderia retornar a instância do usuário, etc.

Os dois maps são internamente distintos. Então os valores associados a cada um também estão separados. Não há muito como (de maneira trivial pelo menos não) um atributo da sessão 1 estar referenciando um valor de uma sessão 2.

Bom: pela sua descrição, no momento em que os dois logam no sistema, os dois acessam os dados corretamente. Usuário 1 vê os dados do usuário 1, e usuário 2 vê os dados do usuário 2.

No entanto, quando acessam determinada área do sistema, os dados que ficam nesta área são aqueles do usuário que o acessou pela primeira vez, certo? Sendo assim, se o usuário 2 chegasse nesta área primeiro, o usuário 1 ao entrar nela em seguida veria os dados do usuário 2.

Se já sabemos que as sessões tem os dados separados, mas em determinada área da aplicação dados de uma sessão estão sendo mantidos, temos ai um &quot;vazamento&quot;, ou seja, uma referência a um dado presente em uma sessão.

Faça o seguinte: você pode verificar os seguintes aspectos.
1. Que objetos estão sendo retornados pelo model que renderizará a sua visão? Será que quando esta action é executada, ela não está guardando algum estado em algum local? Por exemplo, uma classe de serviço que tenha algum singleton ou atributo estático. Verifique isto. Há variáveis fora do corpo da sua action. Verifique se são estáticos.

2. Nas suas classes de domínio há atributos estáticos além dos usuais (constraints, oneToMany, etc)? Quais seriam estes atributos?

3. Nesta view que está repetindo os dados, há algum scriptlet que defina variáveis ou coisa similar?

4. Será que não é o flash? Você armazena dados no escopo flash? De repente a gente descobre algum comportamento doidão aqui.

5. Qual a sua versão do Grails?


0
Bruto,

O problema é no &quot;cache&quot; do firewall.
Vamos ser honestos, não é um problema, é que ele tá funcionando como um CDN na tua rede local, ou seja, está servindo conteúdo com base na URL chamada.

Quando você utiliza seus formulários via POST, a url é a mesma pq os parâmetros não passam pela URL, e então não vira chave no cache.

Se você fizer uma requisição (igualzinha está sendo feita), agora utilizando GET, vc vai conseguir o resultado correto.

Neste caso, você vai conseguir resolver adicionando os headers de non caching no response (com auqele plugin que falei), e também acertando a configuração do firewall, junto com o pessoal da infra estrutura lá, pra desconsiderar algumas URLs, ou fazer esta chave de alguma maneira diferente.

Neste caso, não tem nada ligado com a app grails, a questão é nesse appliance (teu firewall). Você pode bater o matelo acessando a mesma URL mapeando no seu hosts pra que o IP bata direto no tomcat, e não no firewall...

É um problema comum quando existe passos na frente do server java (firewall, junipers, alteons, caches, apaches, etc)...

Sabadão te ligo cedo, vamos almocar pra bater aquele papo lá?
16/09/2010 00:00


0
Olá pessoal, obrigado pela resposta...

kico,
eu verifiquei o que voce falow e é o seguinte:
1 - nas paginas que acontecem o problema eu nao retorno nada pra renderizacao, eu apenas uso o request, que pega os dados da sessao:
eu tenho um filter que faz isso sempre

if( session.participante )
request.participante = Participante.get( session.participante )
e nao tenho variaveis fora do corpo da minha action, nem outras variaveis estaticas.

2 - o unico atributo estatico que eu tenho nas classes de dominio eh esse:
static final long serialVersionUID = 1L;

3 - nao

4 - o escopo flash eu só uso pra mensagens (flash.message)

5 - Grails 1.3.4

------------------------------

lucas,

eu tb acredito q eh cache. sabadao vamu marca sim,

abraços
17/09/2010 00:00


0
Olá,

Era cache mesmo, fiz um teste gerando um numero diferente no final do link para nao puxar do cache e funcionou.

Agora vou tentar usar o pluguin q o lucas falow, e ver a questão do cache no firewall...

Obrigado a todos pela ajuda

Abraços
21/09/2010 00:00



Ainda não faz parte da comunidade???

Para se registrar, clique aqui.


Aprenda Groovy e Grails com a Formação itexto!

Newsletter Semana Groovy

Assinar

Envie seu link!


Livro de Grails


/dev/All

Os melhores blogs de TI (e em português) em um único lugar!

 
Creative Commons
RSS Grails Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.
Ver: 4.14.0
itexto