Org.hibernate.LazyInitializationException: could not initialize proxy - no Session

Bom dia

eu se que existe tópicos com esse problema mas não consigo resolver.

Tenho uma classe chamada UsuarioInterno como mostra abaixo:

@Entity
public class UsuarioInterno extends AbstractModelo implements Usuario {

    public static final int LENGTH_USUARIO = 30;
    public static final int LENGTH_NOME = 50;
    public static final int LENGTH_SENHA = 32;
    public static final int LENGTH_NIVEL = 50;
    public static final int LENGTH_EMAIL = 255;
    @Id
    @Column(nullable=false, length=LENGTH_USUARIO)
    private String usuario;
    @Column(nullable=false, length=LENGTH_NOME)
    private String nome;
    @Column(nullable=false, length=LENGTH_SENHA)
    private String senha;
    @ElementCollection(fetch= FetchType.EAGER, targetClass=String.class)
    @Column(length=LENGTH_NIVEL)
    private Set<String> niveis;
    @Column(nullable=false, length=LENGTH_EMAIL)
    private String email;
    private boolean ativo = true;
    //get / set
}

E o meu sistema está utlizando EJB e o meu GenericDAO está assim

public abstract class GenericDAO<M extends Modelo> implements DAO<M> {

    public static final String UNIT_NAME = "PU";
    @PersistenceContext(unitName = UNIT_NAME)
    //demais métodos
}

Todos os meus o dao UsuarioInternoDAOImpl está com Stateless, meu UsuarioInternoControllerImpl está Stateful e ViewScoped e quando tento gravar minha classe, quando o JSF tenta acessar a propriedade niveis, da o erro de LazyInitializationException.

A questão é que eu já tentei colocar o PersistenceContext como EXTENDED, já tentei colocar com @SessionScoped e não resolve o problema.

Alguém pode me dar uma luz?

ps: isso acontece também com @ManyToOne

Dá uma olhada aqui: Quatro soluções para LazyInitializationException.

Eu li seu post mas a questão é a seguinte:

A leitura da coleção já havia sido feita anteriormente, pois a tela em questão tem um selectBooleanCheckbox.

O erro acontece durante a restauração da view quando o componente selectBooleanCheckbox tenta acessar a lista para adicionar / remover os itens.

O meu UsuarioInternoBean está em em Viewscoped também, além UsuarioInternoControllerImpl. O UsuarioInternoDAOImpl é Stateless mas já tentei colocar Stateful.

Alguma luz?

Eu não consigo fazer essa ideia funcionar, pois sempre que tento trabalhar com o jpa eu caio nesse problema.

Vou acabar voltando para JDBC puro.

Bom dia

Alguém já conseguiu montar essa minha estrutura?

EJB + JPA + DAO (stateful) + controller(stateful) + webbean (viewscoped) e não ter esse problema de LazyInitializationException?

[quote=tebosoftware]Bom dia

Alguém já conseguiu montar essa minha estrutura?

EJB + JPA + DAO (stateful) + controller(stateful) + webbean (viewscoped) e não ter esse problema de LazyInitializationException?[/quote]

Não entendi, o que você chama de Controller é a sua classe de serviço? que é um EJB Stateful, correto?

Agora se o seu DAO for Stateless, não tem como você deixar o PersistenceContext estendido, pois nada garante que será ele que irá atender todas as suas requisições.

O controller é o serviço que você chama.
O DAO não está stateless está stateful e extended mas não funciona.
Não sei se a junção que dá essa falha.
Pois o webbean não tem @Named e sim @ManagedBean (com @ViewScoped).

[quote=tebosoftware]O controller é o serviço que você chama.
O DAO não está stateless está stateful e extended mas não funciona.
Não sei se a junção que dá essa falha.
Pois o webbean não tem @Named e sim @ManagedBean (com @ViewScoped).[/quote]
Bom, realmente ficou estranho então. Aparentemente deveria funcionar.

Por isso que prefiro fazer meus joins na mão e carregar somente o que preciso :slight_smile:

É bem por ai que eu estou pensando em largar mão do JPA e usar JDBC puro mesmo, ou não usar ViewScoped…

[quote=tebosoftware]É bem por ai que eu estou pensando em largar mão do JPA e usar JDBC puro mesmo, ou não usar ViewScoped…[/quote]O que o viewscoped tem haver com isso?

Eu penso que está tendo algum tipo de conflito com o ViewScoped e o EJB. Pois nunca funciona o ciclo de vida correto dos componentes Stateful

[quote=tebosoftware]Eu penso que está tendo algum tipo de conflito com o ViewScoped e o EJB. Pois nunca funciona o ciclo de vida correto dos componentes Stateful[/quote]Eu tenho aplicações que funcionam sem nenhum conflito, e outra, sem nenhum EJB Stateful. Você verificou se após selecionar um checkbox uma nova consulta não é feita e isso faz com que o erro aconteça de novo?

Esse erro sempre acontece pq algum valor não foi carregado cara. Não é problema de EJB, JPA ou JSF…

Como disse em resposta anterior, o meu sistema é composto por um xhtml com pesquisa e registro do crud. E quando é exibido o registro é feito a busca e é exibido o list. Quando vai fazer uma restauração da view no servidor é que dá a falha.

[quote=tebosoftware]Quando vai fazer uma restauração da view no servidor é que dá a falha.[/quote]Algum cara aqui não está fetch. tem alguma consulta aqui que não está trazendo a lista que deveria trazer…

Bom Hebert, teria como você dar olhar no meu projeto? ele está bem no começo,

Nao tem erro se usar consulta com fetch join em casos importantes e de qualquer maneira tambem manter a session do hibernate aberta durante todo request para atender a casos simples/leves como CRUDs administrativos, em que multiplas querys nao vao matar ninguem.

Faz uma aplicacao do zero sem usar nenhum framework alem do Hibernate, sem essas tralhas de EJB e JSF, no maximo use um framework action based se achar que vai ajudar, para entao voce ter mais controle e isolar o problema. Entao faz esse teste focando só no Hibernate e depois voce vai encaixando o que quiser ate achar o motivo do problema e resolver pontualmente, pois testar o todo fica complicado mesmo.

Vamos entender assim:

1- Se eu pegar as mesmas classes e colocar num projeto desktop e só ter uma instância do entityManager, nunca da esse erro;
2- No ambiente web, com controle manual do entityManager, não da erro, pois controlo um entityManager por sessão;
3- No ambiente web, com controle EJB, da o erro sempre que a view do JSF tem que ser restaurada, ou seja, não na leitura para montagem da tela e sim ao tentar passar os novos valores.
4- Já fiz um projeto só com JDBC e esse problema de LazyInitializationException não ocorre, pois sou eu que busco as dependências. Só que num ambiente mais profissional, eu preciso usar o EJB com JPA.

[quote=tebosoftware]Vamos entender assim:

1- Se eu pegar as mesmas classes e colocar num projeto desktop e só ter uma instância do entityManager, nunca da esse erro;
2- No ambiente web, com controle manual do entityManager, não da erro, pois controlo um entityManager por sessão;
3- No ambiente web, com controle EJB, da o erro sempre que a view do JSF tem que ser restaurada, ou seja, não na leitura para montagem da tela e sim ao tentar passar os novos valores.
4- Já fiz um projeto só com JDBC e esse problema de LazyInitializationException não ocorre, pois sou eu que busco as dependências. Só que num ambiente mais profissional, eu preciso usar o EJB com JPA.[/quote]
1 - Deixa de lado comparar com desktop, pois no desktop existe estado.

2 - Eu não uso EntityManager pois só uso mesmo Hibernate original puro sem JPA, então não tem esses intermediadores que parecem complicar o controle da situação. Mas olhando seu caso de JPA qual seria o problema real de usar o controle manual já que você falou que funciona? É um trabalho manual que teria que fazer várias vezes ou uma vez só? Uma vez só não seria um problema. Controle de recursos de Session no Hibernate é uma coisa que se faz uma vez só na Infra e depois só se usa, não tem complicadores no Hibernate puro.

3 - Se o problema é com EJB então já pode refinar sua pesquisa: https://www.google.com.br/search?q=entitymanager+lazyinitializationexception+ejb+guj

4 - Sem Hibernate logicamente não existe erro de hibernate. EJB não é a única opção em “ambiente profissional”, Spring é muito bem defendido também.

Você me entendeu mal.

Comparei com o desktop pela razão dele não ter múltiplos entitymanagers.

Hibernate puro acho errado usar, pois a especificação veio para normalizar o uso do padrão de persistência.

já li diversos post sobre a questão e nenhum me ajudou inclusive o blog do Herbert.

Ambiente profissional é a ideia de utilizar a especificação.

Eu li até o EJB 3 em ação para tentar entender o modelo por completo.

mas vou realmente partir para o controle manual do entityManager.

obrigado.

[quote=tebosoftware]Você me entendeu mal.
Comparei com o desktop pela razão dele não ter múltiplos entitymanagers.
[/quote]
Beleza, o que quis dizer é que desktop tem estado e web não.

[quote=tebosoftware]
Hibernate puro acho errado usar, pois a especificação veio para normalizar o uso do padrão de persistência.

já li diversos post sobre a questão e nenhum me ajudou inclusive o blog do Herbert.

Ambiente profissional é a ideia de utilizar a especificação.[/quote]
Especificação e padrões da Oracle-Sun não fazem significar que outra solução seja escolha “errada” ou deixar de ser uma “solução profissional”, ainda mais o Hibernate em que a especificação JPA se baseou na importância do Hibernate. Vai da decisão de cada equipe usar os frameworks que avaliar melhor para atender as necessidade reais, onde essa “normalizacao” muitas vezes nao faz sentido na realidade de um projeto. Assim como escolher Spring pode ser muito melhor do que EJB dependendo da decisão da equipe.

Beleza, não sou usuário de JPA e achei que isso seria sua saída no momento mesmo pra tentar te ajudar, depois refatora se conseguir o que queria, mas e aqueles tópicos via pesquisa do google que te passei não tem uma solução 100% do que você queria? E o que tem no blog Herbert para os casos mais usados é garantido, quando não funciona é por causa de algo feito interferindo ou alguma interferência de frameworks.