OBS: Na verdade não resolvi, mas fazer o OSIV com PhaseListener foi bem melhor diminui os erros estranho, descobri que alguns realmente vieram de funções feitas nos objetos q acabam buscando mais itens no banco. E realmente listas (mas essas contornadas com batch size)
Eu tenho uma aplicação “legada”, que faz uso do “Open Session In View” utilizando o seguinte filtro no web.xml
e eu tenho outros filtros no meu web.xml e por algum erro q eu não sei qual seja são 8 filtros e algumas atualizações de tela geram 8 selects no banco…
Se eu deixar 1 filtro (hipoteticamente alguns não podem ser retirados pois o sistema não funciona) mas pra cada um q eu tiro diminui as query geradas e sim como o fabiozanardi disse com ou sem lazy é o mesmo resultado
e eu tenho outros filtros no meu web.xml e por algum erro q eu não sei qual seja são 8 filtros e algumas atualizações de tela geram 8 selects no banco…
Ok vou tentar explicar melhor, quando eu entro em uma pagina que faz buscas pelo bean de alguns argumentos e gera selects ao invez do select ser executado uma vez como se espera ele executa n vezes, sendo n o numero de filtros no web.xml… vou mandar meu web.xml pode ser q eu tenha feito algo de errado.
realmente estou com problemas não é de hoje mas esta muito dificil entneder do porque.
se alguem puder dar uma analizada eu ja coloquei o web.xml com os famigerados filtros, não sei necessáriamente porque esse comportamento na aplicação.
OK mexendo feito um desesperado literalmente falando cheguei a conclusão que não são os filtros que fazer executar n vezes os selects deve ser outra coisa.
fiz umas mudanças e tirei uns filtros que pareceram desnecessários segue meu web.xml pra conferir
Retirei o OpenSessionInView dos filtros e implementei com base em PhaseListener, ficou mais preciso porem o problema dos multiplos selects continuam, ele é “aleatorio” há consultas que executam as 8 vezes e consultas q fazem menos… antes que alguem pergunte não essas consultas não tem coleções envolvidas.
esses selects estão tornando meu sistema extremamente lento eu gostaria de saber se existe algum modo de não executar tantas vezes quanto executa hoje.
Se alguem passa por esse problema e encontrou soluções elas seriam muito bem vindas.
Cara,certeza que não são os filtros que estão ocasionando esse comportamento,isso é um ‘bug’ conhecido do JSF,o que vc pode fazer é implementar algo do tipo:
public List getLista(){
if(lista==null)carregaLista():
}
[quote=raf4ever]Cara,certeza que não são os filtros que estão ocasionando esse comportamento,isso é um ‘bug’ conhecido do JSF,o que vc pode fazer é implementar algo do tipo:
[code]
public List getLista(){
if(lista==null)carregaLista():
}
[/code][/quote]Eu só prefiro não falar ‘bug’. Eu vejo mais pau de utilização mesmo, infelizmente o JSF é muito mau visto por muitas pessoas, pessoas essas que nunca pararam para estudar sobre JSF.
Mas já que você está utilizando spring, porque não delega a ele a tarefa de criação e gerenciamento de transações? Isso livra sua camada web (Managed Beans/Filters) de ter que lidar com session/entitymanager. Mas para isso você precisa de uma camada ‘service’ em seu sistema, algo assim:
web (managed beans)
service (classes que contem a logica de negócio, gerenciada pelo spring)
dao
dominio
Sua classe service seria assim, por exemplo:
@Service
@Scope("prototype")
public class UsuarioService {
@PersistenceContext
private EntityManager em;
private List<Usuario> all = new ArrayList<Usuario>();
@Transactional
public void loadAll() {
all = new UsuarioDAO(em).findAll();
}
//getters e setters
}
E então em seus managed beans, não instancie a classe service, mas chame-a através do container do spring, para que ela venha com as devidas dependencias (injeção do entitymanager/session e o controle de transação) resolvidas:
@ManagedBean
@RequestScoped
public class UsuarioMB {
private UsuarioService service;
@PostConstruct
public void init(){
service = (UsuarioService)SpringContainer.getService(UsuarioService.class);
service.loadAll();
}
//getters e setters
}
Classe utilitária:
public class SpringContainer {
public static Object getService(Class clazz){
return FacesContextUtils.getWebApplicationContext(FacesContext.getCurrentInstance()).getBean(clazz);
}
}
E então de seus .xhtml, você pode acessar diretamente os atributos de service, por exemplo uma tabela do primefaces contendo os usuários: