nao posso ajudar, mas voce pode me ajudar 
eu ia tirar esse fim de semana pra dar uma olhada exatamente nesses conceitos, se voce pudesser compartilhar este seu projetinho :roll:
Re:EJB3 + JPA - Propagando Transação
H
33 Respostas
M
Olhando seu código da para perceber que você está controlando a gerência do EntityManager manualmente:
public static EntityManager currentEntityManager() {
[b]EntityManager manager = (EntityManager) SESSION.get();[/b]
if (manager == null) {
loadInstance();
manager = FACTORY.createEntityManager();
SESSION.set(manager);
}
return manager;
}
@Override
public void salvar(Cliente cliente) throws DAOException {
logger.debug("Entrou ClienteDAOJPA");
EntityManager manager = null;
try{
[b]manager = PersistenceUtil.currentEntityManager();[/b]
manager.persist(cliente);
manager.flush();
}catch(Exception e){
throw new DAOException("Erro salvar Cliente");
}
}
Eu ainda não dei uma olhada profunda na especificação do EJB3, mas acho que não mudou neste aspecto para a especificação do EJB 2.1. Ou seja, se deseja que o Transaction Manager controle toda a transação, tem que garantir que todos os seus provedores de serviços podem ser anexados ao JTA. Pode ser que a definição manual possa estar atrapalhando a mesma.
Uma pergunta, não conheço seu projeto mas haveria algum problema se alterrase seu DAO para um Session Bean Stataless e ussase a atribuição do PersistenteContexte por injeção de dependência pelo container assim:
@PersistenceContext
private EntityManager em;
Dai chamaria seu DAO também por Injecção de dependência assim:
@EJB
private UtilDao utilDao;
Espero que lhe ajude em algo!
A
A questão é: pq vc precisa dessa situação específica, se o AS já injeta o EntityManager para vc!? Ou seja, qual a vantagem dessa abordagem!?
A
Sim, e qual a vantagem dessa abordagem?
Não é mais fácil injetar o EntityManager?
A
Mas é isso mesmo, dê uma olhada…
M
Boa noite Maracuja,
estou participando de um projeto onde desenhamos essa mesma arquitetura de camadas e estamos enfrentando o mesmo problema em relacao a transacao gerenciada pelo container. Voce chegou a alguma conclusao sobre isso? Como propagar a transacao a partir de um session bean(delegate) ate a camada DAO(POJO)?
Obrigado,
Marco.
M
Maracuja,
obrigado pelo pronta resposta. Isso e decepcionante, mas vou dar uma olhada com calma no site indicado.
Abracos,
Marco.
T
Olá a todos…
Tenho uma aplicação EJB3 rodando dentro do Jboss4.0.5GA, onde estou numa situação assim: minha aplicação tem uma rotina que salva um registro numa tabela de um outro banco através de um DBLINK, e nessa tabela tem um trigger que que ao cair registro lê o mesmo. Mas o problema é que quando eu do um flush() na aplicação para salvar o registro é ativada a trigger onde da um erro na trigger e acaba retornando uma excessão para o jboss quebrando toda a sessão dele, assim não cosigo remover esse registro que está dando erro e a aplicação entra num loop infinito. Como faço para capturar essa excessão sem quebrar as transações do jboss? Alguém poderia me ajudar? Lembrando que a trigger nós aqui não mexemos, e o cliente não quer alterar para corrigir esse erro.
T
Bom, cheguei a conclusão que não tem jeito… se vc quiser utilizar uma transação CMT com esta arquitetura vc teria que utilizar um EntityManager injetado pelo container e seta-lo na ThreadLocal de um PersistenceUtil (sic) !!!Só fazendo gambiarra!!! :?
na real… só … como sugerido pelo Taz
http://www.hibernate.org/328.html
Writing DAOs as managed EJB 3.0 components
Exato. Estamos usando uma arquitetura parecida aqui… utilizando DAOS como EJBs. Fica estranho mesmo a arquitetura. E até chego a perguntar: Até aonde vale a pena utilizar DAO numa arquitetura dessas?
L
Galera, olhando este post vejo que tem algo a ver com a questão que estou enfrentando.
No meu caso, todos os objetos envolvidos são EJBs… Tenho um EJB Statefull que chama vários EJBs Stateless, e gostaria que as transações fossem iniciadas e finalizadas no Stateful… ou seja, as transações deveriam ser propagadas para os Stateless.
Estava fazendo com injeção de dependência e tudo estava beleza, mas um requisito da aplicação me força a mudar parâmetros do EntityManager em tempo de execução, para pegar conexões de acordo com o usuário logado (cada usuário do sistema tem um usuário paralelo no banco).
Desta forma, preciso pegar minhas referências de EntityManager da seguinte forma:
Persistence.createEntityManagerFactory("NomePU").createEntityManager(props);
onde props é um Map com as propriedades que tenho que passar para o EntityManager.
dessa forma, preciso criar a transação com entityManager.getTransaction().begin;
a questão é como propagá-la para os demais EJB sem estado.
alguma sugestão?
[]'s
C
Bom, cheguei a conclusão que não tem jeito… se vc quiser utilizar uma transação CMT com esta arquitetura vc teria que utilizar um EntityManager injetado pelo container e seta-lo na ThreadLocal de um PersistenceUtil (sic) !!!Só fazendo gambiarra!!! :?
na real… só … como sugerido pelo Taz
http://www.hibernate.org/328.html
Writing DAOs as managed EJB 3.0 components
Exato. Estamos usando uma arquitetura parecida aqui… utilizando DAOS como EJBs. Fica estranho mesmo a arquitetura. E até chego a perguntar: Até aonde vale a pena utilizar DAO numa arquitetura dessas?
Permitam-me discordar, existe solução sem gambiarra!
1 - Usar o DAO como EJB é ruim pq quebra a componentização. (Qualquer cliente pode conseguir pular a camada de negócio e ir direto pro DAO)
2 - Não usar DAO implica em aumentar consideravelmente o acoplamento entre negócio e persistência.
Solução:
De dentro do Dao, é só pegar via JNDI o EntityManager do Container, a transação assim, ao que tudo indica, fica sendo ainda controlada pelo Container (Ainda não tive nenhum problema com a transação).
Em termos de arquitetura fica perfeito, não faço a besteira de fazer o DAO como EJB e nem faço tudo direto dentro do meu EJB de fato!
A
Certo, então vc faz um lookup para cada acesso ao BD!!!
Quantas vezes por dia/hora/minuto vc faz lookup para pegar o Entity Manager? Já fez um teste para ver se sua aplicação escala?
J
De dentro do Dao, é só pegar via JNDI o EntityManager do Container, a transação assim, ao que tudo indica, fica sendo ainda controlada pelo Container (Ainda não tive nenhum problema com a transação).
Certo, então vc faz um lookup para cada acesso ao BD!!!
Quantas vezes por dia/hora/minuto vc faz lookup para pegar o Entity Manager? Já fez um teste para ver se sua aplicação escala? ;)
nunca usei a arquitetura em questão, mas nesse caso um locator+cache não resolveria esse problema?
[]´s
A
Voltamos ao DAO com @EJB
J
nunca usei a arquitetura em questão, mas nesse caso um locator+cache não resolveria esse problema?
Voltamos ao DAO com @EJB ;)
não necessariamente, posso ter um DAO que vai fazer lookup(JNDI) do EntityManager.
[]'s
C
Caro Taz,
Pode ser realmente que o JNDI seja o gargalo da aplicação, mas daí neste caso, a injeção do DAO no EJB usando @EJB também teria o mesmo problema.
Por que?
Oras, por baixo dos panos, como é que vc acha que o container injeta o DAO dentro do EJB ?
É via JNDI !
Fazer o Dao como EJB, é abrir mão do encapsulamento e/ou componentização da sua aplicação! Mas funciona! pra coisas pequenas não tem problema, como não tem problema fazer tudo dentro do jsp !
A
Caro Taz,Oras, por baixo dos panos, como é que vc acha que o container injeta o DAO dentro do EJB ?
Sim, ele injeta por JNDI UMA VEZ SÓ …
Eu acho o contrário. Faça um teste utilizando @EJB e compare os resultados.
C
O Container injeta uma vez só, só se for Statefull !
Se for Stateless, vai injetar sempre que tiver uma nova requisição!
Como na minha app só tem stateless, dá na mesma!
A
Não. Dê uma estudada na espec.
F
Pessoal,
Como fazer o lookup do EntityManager e TransactionManager via JNDI?
Qual o JNDI (o nome) destes objetos registrados no container (estou usando jboss)?
Att,
Fábio Viana
J
Maracujá,
Tenho uma dúvida e gostaria de saber se você pode me ajudar estou fazendo uma aplicação mto parecida com o seu exemplo, porém estou utilizando NetBeans 6 e GlassFish para fazer minha aplicação, meu problema é que quando tento obter o EntityManagerFactory eu recebo uma exception do hibernate [HibernateException: Could not find datasource.]. Verifiquei no servidor e meu JDBC está lá aparentemente certo, tentei mudar de ORM, mas o TopLink me retornou um erro bem parecido. Acredito que seja pelo fato de que meu persistence.xml está configurado para JTA, porém tentei mudá-lo e não consegue pois caso eu coloque como resource_local eu não consigo compilar a aplicação.
L
Pessoal,Como fazer o lookup do EntityManager e TransactionManager via JNDI?
Qual o JNDI (o nome) destes objetos registrados no container (estou usando jboss)?Att,
Fábio Viana
Eu faço assim:
private CustomerRemote customer;
InitialContext ic = new InitialContext();
customer = (CustomerRemote) ic.lookup(CustomerRemote.class.getName());
Funciona bem!
T
Nao sei se é o mesmo caso, mas eu tenho um projeto parecido e ele esta dando problema com o os relacionamentos fetch=lazy. Como o container esta gerenciando a transacao ele encerra a sessao e eu recebo uma exception quando tento acessar o relacionamento. Seria isso? da forma que esta implementada esta arquitetura resolve o problema com a solucao “gambiarra” utilizando threadlocal resolve?
F
Nao sei se é o mesmo caso, mas eu tenho um projeto parecido e ele esta dando problema com o os relacionamentos fetch=lazy. Como o container esta gerenciando a transacao ele encerra a sessao e eu recebo uma exception quando tento acessar o relacionamento. Seria isso? da forma que esta implementada esta arquitetura resolve o problema com a solucao “gambiarra” utilizando threadlocal resolve?
Hibernate.initialize?
Não é isso que vc precisa fazer para carregar seu relacionamento?
T
eu estou usando toplink essentials. Ele funciona, porem nos selects quando tento acessar colecoes que estao no objeto ocorre o erro. Verifiquei na net que eh um problema da implementacao da jpa. E tem algumas solucoes paliativas como o Open Session In View ou Spring. Gostaria apenas de saber se esta eh uma delas. Se eu usar a seguinte arquitetura:
(JSF - Controle - Banco) funciona perfeitamente sem as “pogs”. Mas gostaria de utilizar isso desacoplado entao preciso de Solucoes alternativas. Minha arquitetura esta assim:
(JSF - Controle - Ejb3 - Banco).
Na parte de EJB3 tenho uma Interface Generica e uma implementacao da interface generica.
DaoGenerico e DaoGenericoImpl e os EJBs herdam essa interface na Remote e a implementacao no @Stateless. Seria isso o problema?
F
eu estou usando toplink essentials. Ele funciona, porem nos selects quando tento acessar colecoes que estao no objeto ocorre o erro. Verifiquei na net que eh um problema da implementacao da jpa. E tem algumas solucoes paliativas como o Open Session In View ou Spring. Gostaria apenas de saber se esta eh uma delas. Se eu usar a seguinte arquitetura:(JSF - Controle - Banco) funciona perfeitamente sem as "pogs". Mas gostaria de utilizar isso desacoplado entao preciso de Solucoes alternativas. Minha arquitetura esta assim:
(JSF - Controle - Ejb3 - Banco).
Na parte de EJB3 tenho uma Interface Generica e uma implementacao da interface generica.
DaoGenerico e DaoGenericoImpl e os EJBs herdam essa interface na Remote e a implementacao no @Stateless. Seria isso o problema?
1º - Qual o tipo de relacionamento?
2º - O carregamento das suas coleções tem que ser preguiçoso?
3º - Open Session In View Usando EJB? Não faz sentido, certo?
4º - A implemenetação dos seus DAOs não é a questão.
Só para exemplificar o que eu tinha dito anteriormente.
Digamos que vc tem duas classes:@Entity
public class Pessoa implements Serializable {
private Set<MenuSistema> menus = new HashSet<MenuSistema>();
@ManyToMany
//Ou @OneToMany, sei lá...
public Set<MenuSistema> getMenus() {
Hibernate.initialize(menus);
return menus;
}
//método set apropriado
}
T
Eu entendo perfeitamente. Mas seu exemplo se aplica apenas usando Hibernate. Eu nao estou usando Hibernate.
Eu tenho a seguinte situacao:
@Entity
public class Pedido {
@Id
private Integer id;
@Temporal
private Date dataPedido;
@OneToMany(cascade = CascadeType.ALL, mappedBy = "pedidoID")
private Collection<Pedidoproduto> itens;
quando eu seleciono o pedido acesso normalmente os dados da entidade como id, data e outro que seja. Mas quando eu tento acessar seus itens me retorna uma exception
avax.faces.FacesException: Exception [TOPLINK-7242] (Oracle TopLink Essentials - 2.0 (Build b41-beta2 (03/30/2007))): oracle.toplink.essentials.exceptions.ValidationException Exception Description: An attempt was made to traverse a relationship using indirection that had a null Session. This often occurs when an entity with an uninstantiated LAZY relationship is serialized and that lazy relationship is traversed after serialization. To avoid this issue, instantiate the LAZY relationship prior to serialization.
F
Qual o equivalente daquele método no TOPLINK? Eis a questão!
Outra coisa, o que importa é a especificação, quem implementa não deveria ser o problema…finalmente, Pedidoproduto não pode ter o carregamento preguiçoso, uma alternativa é montar uma HQL usando JOIN.
T
Pelo arquivo que li no site do hibernate teoricamente eu posso fazer assim:
Session session = (Session) entityManager.getDelegate();
onde o Session faz parte do pacote do toplink. Porem os metodos dessa camada Session nao sao muito intuitivos e estou sem a api. Tenho que testar. Mas vou procurar no site da oracle. Pelos testes que fiz a unica forma de deixar funcionando sem problema nenhum eh utilizar apenas duas camadas. A aprentacao que no meu caso eh JSF e o ManagedBean fazendo a persistencia e o controle de transacao. Assim da 100% certo.
J
Olá meus jovens amigos, já é tarde e estou com um problema, gostaria de vossas opiniões! ahIUAHuiahIUAHuiahIUAh
Bom, vamos lá estou brincando aqui; construindo um brinquedo com as seguintes camadas Action -> BusinessDelegate -> SessionFacade(EJB3) -> ApplicationService -> BusinessObject -> DAO (JPA)
Porém não estou conseguindo persistir dados com um bean CMT e esta arquitetura… consigo apenas se estiver persistindo no proprio CMT!!!
Bean
@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
public class ClienteSessionFacade extends AbstractSessionFacade implements ClienteSessionFacadeRemote {
...
@TransactionAttribute(REQUIRES_NEW)
public void salvarCMT() throws SessionFacadeException {
Cliente cliente = new Cliente();
cliente.setNome("teste cmt");
try {
logger.debug("Inicio " + this.getClass().getName() + ".salvar()");
ClienteAS.getInstance().salvarCMT(cliente);
logger.debug("Fim " + this.getClass().getName() + ".salvar()");
} catch (ApplicationServiceException e) {
logger.error(this.getClass().getName() + ".salvar()");
throw new SessionFacadeException("Erro salvando Cliente");
}
}
}
o AS
public class ClienteAS extends AbstractApplicationService {
...
/**
* Salvar
* @throws ApplicationServiceException
*/
public void salvarCMT(Cliente cliente) throws ApplicationServiceException{
try {
logger.debug("Inicio " + this.getClass().getName() + ".salvar()");
ClienteBO.getInstance().salvar(cliente);
logger.debug("Fim " + this.getClass().getName() + ".salvar()");
} catch (BusinessObjectException e) {
logger.error(this.getClass().getName() + ".salvar()");
throw new ApplicationServiceException("Ocorreu um erro ao salvar Cliente.", e);
}
}
ai vem o BO somente efetuando as chamadas e no DAO esta assim
@Override
public void salvar(Cliente cliente) throws DAOException {
logger.debug("Entrou ClienteDAOJPA");
EntityManager manager = null;
try{
manager = PersistenceUtil.currentEntityManager();
manager.persist(cliente);
manager.flush();
}catch(Exception e){
throw new DAOException("Erro salvar Cliente");
}
}
so que no flush recebo um
Viram???
Somente estou conseguindo persistir por enquanto da seguinte forma
Outro método do mesmo Bean
@TransactionAttribute(NEVER)
public void salvar() throws SessionFacadeException {
Cliente cliente = new Cliente();
cliente.setNome("teste 3333");
cliente.setSobrenome("333333");
try {
logger.debug("Inicio " + this.getClass().getName() + ".salvar()");
ClienteAS.getInstance().salvar(cliente);
logger.debug("Fim " + this.getClass().getName() + ".salvar()");
} catch (ApplicationServiceException e) {
logger.error(this.getClass().getName() + ".salvar()");
throw new SessionFacadeException("Erro salvando Cliente");
}
}
poderia fazer o metodo com a anotação @TransactionManagement(TransactionManagementType.CONTAINER)
mas não importa…
Agora vejam o AS como ficou
/**
* Salvar
* @throws ApplicationServiceException
*/
public void salvar(Cliente cliente) throws ApplicationServiceException{
try {
this.beginTransaction();
logger.debug("Inicio " + this.getClass().getName() + ".salvar()");
ClienteBO.getInstance().salvar(cliente);
logger.debug("Fim " + this.getClass().getName() + ".salvar()");
this.commitTransaction();
} catch (BusinessObjectException e) {
this.rollbackTransaction(this.getClass() + ".salvar()");
logger.error(this.getClass().getName() + ".salvar()");
throw new ApplicationServiceException("Ocorreu um erro ao salvar Cliente.", e);
} finally{
this.closeSession();
}
}
onde AbstractApplicationService é
public abstract class AbstractApplicationService {
private static Logger logger = Logger.getLogger(AbstractApplicationService.class);
/**
* Atributo <code>manager</code> utilizado para gerenciar o EntityManager
* para transação.
*/
private EntityManager manager;
/**
* Atributo <code>transaction</code> utilizado para gerenciar a transação
*/
private EntityTransaction transaction;
protected final void beginEntityManager() {
logger.debug("Inicio " + this.getClass().getName() + ".beginEntityManager()");
manager = PersistenceUtil.currentEntityManager();
logger.debug("Fim " + this.getClass().getName() + ".beginEntityManager()");
}
/**
* Iniciar uma Transação.
*/
protected final void beginTransaction() {
logger.debug("Inicio " + this.getClass().getName() + ".beginTransaction()");
transaction = PersistenceUtil.currentEntityManager().getTransaction();
transaction.begin();
logger.debug("Fim " + this.getClass().getName() + ".beginTransaction()");
}
/**
* Commit de uma Transação.
*/
protected final void commitTransaction() {
logger.debug("Inicio " + this.getClass().getName() + ".commitTransaction()");
if (transaction.isActive()) {
transaction.commit();
} else {
logger.debug(this.getClass().getName() + "Transaction não Ativa");
}
logger.debug("Fim " + this.getClass().getName() + ".commitTransaction()");
}
/**
* Realizar rollback de uma Transação.
*
* @param nomeMetodo
*
*/
protected final void rollbackTransaction(final String nomeMetodo) {
try {
if (transaction.isActive()) {
logger.debug(this.getClass().getName() + "." + nomeMetodo + "() - rollbackTransaction");
transaction.rollback();
}
} catch (final Throwable e) {
logger.error(this.getClass().getName() + ".rollbackTransaction()");
}
}
protected final void closeSession() {
logger.debug("Inicio " + this.getClass().getName() + ".closeSession()");
try {
PersistenceUtil.closeEntityManager();
} catch (Exception e) {
logger.error(this.getClass().getName() + ".closeSession()");
} catch (Throwable e) {
logger.error(this.getClass().getName() + ".closeSession()");
} finally {
logger.debug("Fim " + this.getClass().getName() + ".closeSession()");
}
}
}
e a PersistenceUtil é
public final class PersistenceUtil {
private static final String UNIT_NAME = "trip";
private static EntityManagerFactory FACTORY;
public static final ThreadLocal<EntityManager> SESSION = new ThreadLocal<EntityManager>();
public static EntityManager currentEntityManager() {
EntityManager manager = (EntityManager) SESSION.get();
if (manager == null) {
loadInstance();
manager = FACTORY.createEntityManager();
SESSION.set(manager);
}
return manager;
}
public static void closeEntityManager() {
EntityManager manager = (EntityManager) SESSION.get();
if (manager != null) {
manager.close();
}
SESSION.set(null);
}
private static synchronized void loadInstance() {
if (FACTORY == null) {
FACTORY = Persistence.createEntityManagerFactory(UNIT_NAME);
}
}
}
no meu dao agora tenho a mesma coisa de antes
@Override
public void salvar(Cliente cliente) throws DAOException {
logger.debug("Entrou ClienteDAOJPA");
EntityManager manager = null;
try{
manager = PersistenceUtil.currentEntityManager();
manager.persist(cliente);
manager.flush();
}catch(Exception e){
throw new DAOException("Erro salvar Cliente");
}
}
pra completar a minha entity
@Entity
@Table(name="CLIENTE")
public class Cliente extends AbstractEntity {
private Integer codigo;
private String nome;
private String sobrenome;
private String rg;
private String email;
private String telefone;
private String sexo;
private Date data;
@Id
@GeneratedValue
@Column(name="CODIGO")
public Integer getCodigo() {
return codigo;
}
public void setCodigo(Integer codigo) {
this.codigo = codigo;
}
public String getNome() {
return nome;
}
public void setNome(String nome) {
this.nome = nome;
}
public String getSobrenome() {
return sobrenome;
}
public void setSobrenome(String sobrenome) {
this.sobrenome = sobrenome;
}
public String getRg() {
return rg;
}
public void setRg(String rg) {
this.rg = rg;
}
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
public String getTelefone() {
return telefone;
}
public void setTelefone(String telefone) {
this.telefone = telefone;
}
public String getSexo() {
return sexo;
}
public void setSexo(String sexo) {
this.sexo = sexo;
}
@Temporal(TemporalType.TIME)
public Date getData() {
return data;
}
public void setData(Date data) {
this.data = data;
}
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((codigo == null) ? 0 : codigo.hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
final Cliente other = (Cliente) obj;
if (codigo == null) {
if (other.codigo != null)
return false;
} else if (!codigo.equals(other.codigo))
return false;
return true;
}
Deu pra entender?
Parece que a transação não é propagada no bean CMT, somente funciona com o BMT, porém assim preciso garantir a Atomicidade da transação na “mão”.
Aindo to estudando e brincando com isso, amanhã continua, mas se alguem puder me ajudar… hehehehehehe
Fico grato pela ajuda.
J
Então, é justamente o que estou dizendo, controlando a transação na “mão” em um bean BMT funciona numa boa, o problema é mesmo com o CMT.
Existem dois casos.
Bean BMT com controle de transação feito na mão que eu ja fiz e funciona numa boa.
Bean CMT, sem fazer o controle transacional na mão, ao tentar pesistir, ocorre o erro.
javax.persistence.TransactionRequiredException: no transaction is in progress
Concerteza, entre minhas brincadeiras ja fiz e funciona perfeitamente se eu injtar o EntityManager no meu Bean, ou até usar no meu DAO um outro
bean… a questão é que queria entender melhor esta situação específica!!!
Mesmo que eu fizesse isso
public void salvar(Cliente cliente) throws DAOException {
logger.debug("Entrou ClienteDAOJPA");
EntityManager manager = null;
try{
manager = Persistence.createEntityManagerFactory(UNIT_NAME).createEntityManager();
manager.persist(cliente);
manager.flush();
}catch(Exception e){
throw new DAOException("Erro salvar Cliente");
}
}
ocorre o mesmo erro… pq neste momento parece não haver uma transação em andamento…
J
Eu queria que o Container gerencia-se a transação para mim; porém mantendo esta arquitetura…
J
Talvez, se conseguisse injetar aí o EntityManager, mas só consigo injetar isso no meu EJB!!!
Tentei injetar no DAO, mas recebi um null. Injetando no EJB funciona na boa.
Porém acredito que mesmo que eu injetasse o entity manager, perigava eu ainda receber um
javax.persistence.TransactionRequiredException: no transaction is in progress
Acho que vou tranformar meus DAO’s em EJB’s tb e td será resolvido. eu não queria… bom ainda to avaliando novas abordagens…
:roll:
J
Bom, cheguei a conclusão que não tem jeito… se vc quiser utilizar uma transação CMT com esta arquitetura vc teria que utilizar um EntityManager injetado pelo container e seta-lo na ThreadLocal de um PersistenceUtil (sic) !!!
Só fazendo gambiarra!!! :?
na real… só … como sugerido pelo Taz
http://www.hibernate.org/328.html
Writing DAOs as managed EJB 3.0 components
Criado 1 de junho de 2007
Ultima resposta 5 de ago. de 2007
Respostas 33
Participantes 15
Alura POO: o que é programação orientada a objetos? Aprenda os conceitos básicos da programação orientada a objetos, como classes, objetos, herança, encapsulamento e polimorfismo, com exemplos.
Casa do Codigo Inteligencia Artificial e ChatGPT: Da revolucao dos... Por Fabricio Carraro — Casa do Codigo
Fiap Pos-Tech: Arquitetura e Desenvolvimento Java Uma jornada especialmente pensada para profissionais que desejam dar os próximos passos na área...