Tenho uma aplicação, relativamente grande e bastante modularizada usando JSF, EJB e JPA (hibernate provider).
o problema: não entendo o por que um conjunto determinado de transações recebe o rollback.
premissas:
-
De uma forma geral, tudo na aplicação funciona, contudo existem alguns metodos EJB que sempre que executados tem o RollBackOnly setado (Estou usando JTA na aplicação e ela é CMT).
-
Ao olhar os logs do glassfish + debugs, observo que todos os metodos são executados corretamente, nenhum lanca qualquer excessão (checked ou não).
-
conseguir isolar a chamada de persist que faz a transação dar rollback, mas essa também não lanca qualquer excessão, contudo apos a execução dela o HIBERNATE seta a transacao para rollback only.
-
a entity a ser persistida que dá o erro só difere em um aspecto das demais entities do projeto, está possui um atributo de colecao com ou sem o cascade merge. No log do glassfish aparecem os sqls relativos a inclusao, mas ainda assim ao final daquele persist o estado da transacao muda para rollback only.
Preciso saber o pq do problema. Li um comentario (http://www.netbeans.org/kb/docs/web/hibernate-jpa.html na parte: …these issues can be worked around by choosing eager as the association fetch value and java.util.Set …). Mas esse contornar eu não posso adotar na aplicação. (afetaria o JAXB e performace de uma forma geral, ainda assim não sei se adiantaria ou não)
No momento quero abordar o problema apenas de forma TEORICA com poucos códigos e sysouts, já que o meu objetivo maior é o proprio entendimento e não simplesmente fazer funcionar.
O que eu ainda não tentei, mudar o provider de Hibernate para Toplink e ver se o comportamento se repete (precisando de ajuda aqui).
Atualizar para uma biblioteca do hibernate mais nova (a última de produção GA logo faz aniversário). Quem tiver um link de um RC do subversion já estavel link ae.
Obrigado
(vou ver se faco um exemplo de testes com o mesmo problema).
[solucao]
A solução só pode ser encontrada depois que o TopLink foi colocado como provider. Os erros apontados pelo toplink são mais amigaveis mostrando a razão do problema (era uma coisa simples, um mapeamento mal resolvido. Neste caso toda a aplicação não deveria rodar ao invez desse comportamento apresentado).
Aconselho aos que começaram agora com JPA a usarem toplink ao invez do hibernate. Em tese deveriam ser a mesma coisa, mas não são (devido a problemas de ambiguidade da especificação ou lacunas como as que dizem respeito a conversores boleanos e exceptions);