Paginação por demanda no Richfaces 4 para o Tomcat 7
3 respostas
C
Charles
Boa tarde.
Tenho uma aplicação desenvolvida em RichFaces 4.0.0 + JPA 2.0 + Spring 3 + Hibernate 3 q deverá ser implantada no Tomcat 7.0.20 mas ela está com problema de desempenho.
Ela faz consulta a uma tabela com quase 100.000 registros tendo um relacionado n-1 com outra tabela com uns 30 registros no MySQL para rich:dataTable q está com tempo de resposta ruim.
O problema do desempenho é pq o rich:dataTable faz paginação na memória do servidor assim, deverei fazer uma paginação sobre demanda.
A questão é que vi o exemplo do Showcase do Richfaces e tb o exemplo de paginação por demanda do brazuca Marcus mas ambos utilização Hibernate Criteria que esta presente JEE 6, não suportado pelo Tomcat.
Alguns outros exemplos q consegui entender tb fazem uso do JEE 6, assim, alguém tem alguma solução suportada pelo Tomcat 7 para me indicar?
Seu problema é arquitetural e não tem anda haver com tomcat, jpa etc…
Subir tudo isso na memoria é totalmente impraticável e sem sentido…um ser humano normal quer porções pequenas do banco de dados para que possa ser visualizada…
Imagina 100 pessoas fazendo isso? Não existe escalabilidade que suporte tal operação…
Simplesmente não faça -
3. Consultas Gigantescas ? Sistemas que permitem o usuário consultar e trazer do banco de dados um alto número de registros.
Problema: Algumas situações comumente ocorrentes em sistemas no modelo desktop ou mais conhecido como ?FAT CLIENT? não se encaixam em aplicativos web. Um destes casos é situação em que sistemas permitem os usuários filtrar e trazer do banco de dados consultas com um alto numero de registros complemente desnecessário. Em casos em que o modelo era desktop, isso não acarretava problemas devido a própria natureza da solução. Entretanto em sistemas web, aonde recursos de execução são limitados e o numero de acesso simultâneos é ilimitado, o sistema estará gastando um alto e precioso numero relevante de memória. Praticamente dizendo, eu já peguei sistemas na redondezas aonde os programadores juniores estavam replicando a arquitetura que continha uma camada de persistencia CRUD. A questão problemática era que o framework replicava um método que sempre retornava todos os registros existente. Isto estava sendo propagado para todo o sistema e seus processos relacionados. Se fomos parar e analisar, mecanismos de busca são disponibilizados ao usuário para que ele tenha autonomia de buscar registros individuais ou grupos lógicos deles. Qual seria o motivo, razão ou o que poderia fazer um usuário com 500 linhas de resultados de uma consulta ? Que ser humano na face da terra gostaria de visualizar 500 registros em uma olhada ? Mesmo que a regra de negócio ainda apoiasse o caso, o usuário final, sendo um humano comum não teria tamanha visibilidade para isso.
Solução: Os processos do sistema em questão deve ser analisado e assim implementado corretas validações lógicas que não permitisse executar consultas que retornasse uma alto numero de registros no banco de dados. Duas práticas neste tópico são bem comuns ? o uso sistemático de paginação e o outro seria implementar filtros inteligentes, baseados em regra do próprio negócio que não deixassem a ocorrência de grandes intervalos. Como tudo na vida, existe exceções aonde podemos sim encontrar situações em sistemas que teria a necessidade consultar grandes volumes de registros, mas isso já esta mais que comprovado que é uma porcentagem pequena e restrita do total da automação.
Pela tua resposta acho q ñ fui claro no meu questionamento ou vc ñ entendeu oq escrevi. Oq acaba sendo um falha minha.
De qq forma vou observar o que vc disse, toda sugestão é bem-vinda.
[]'s
t++
fabim
Implementar Paginacao de Registros no Braço = BESTEIRA
Ao inves de fazer seu usuario “navegar” num conjunto imenso de registros (ja te adianto: ele NAO vai fazer isso) restrinja o universo a um numero pequeno, caso esse universo seja ultrapassado exiba mensagem de que ele precisa refinar mais a consulta (so dar um count antes).
Caso seja requisito exibir MESMO uns 200, 500 registros, a paginacao natural (que nao é real, ele nao busca de pouco em pouco) da maioria dos frameworks ja resolve.
