Então, eu estou usando um DAO genérico e quando vou fazer dar o persist(), se ela já existir, bastaria somente capturar a exceção e continuar, mas ele não captura.
Tentei dar o catch em cima do persist() mas ele não captura e nem nada.
public void save(T t) {
logger.info("salvando: " + t);
try{
em.persist(t);
}catch(org.hibernate.exception.ConstraintViolationException ex){
ex.printStackTrace();
}
}
//Também tentei dar throws na exception, mas ela também não é lançada
30502 [SwingWorker-pool-1-thread-1] WARN org.hibernate.engine.jdbc.spi.SqlExceptionHelper - SQL Error: 1062, SQLState: 23000
30503 [SwingWorker-pool-1-thread-1] ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper - Duplicate entry '079981' for key 'empenho_UNIQUE
Obrigado!
Tente por uma exception Generica e veja se entra no catch:
public void save(T t) {
logger.info("salvando: " + t);
try{
em.persist(t);
}catch(Exception ex){
ex.printStackTrace();
}
}
Então, tentando capturar Exception ele capturou e printou a stackTrace, mas quando ele retorna pra outra classe da camada de persistência, a qual possui o
em.getTransaction.begin();
//salvar
em.getTransaction.commit();
No commit() gera outra exceção, estranho não?
Agora ponha um try-catch no commit e trate-o, verifique se resolveu seu problema.
O commit é diferente do save, ou persist, pois ele termina o fluxo de trabalho, e como deu erro no save, teoricamente o commit ira gerar uma exception.
http://www.hibernate.org/hib_docs/v3/api/org/hibernate/FlushMode.html
[quote=rof20004]Agora ponha um try-catch no commit e trate-o, verifique se resolveu seu problema.
O commit é diferente do save, ou persist, pois ele termina o fluxo de trabalho, e como deu erro no save, teoricamente o commit ira gerar uma exception.
http://www.hibernate.org/hib_docs/v3/api/org/hibernate/FlushMode.html[/quote]Link quebrado. =P
desculpe, esse link que te passei nem existe mais, tenho alguns links antigos aqui, hehehe, ta na nora de me atualizar ‘-’.
Correto. Mas se eu for tratar o commit dentro do catch, como a transaction vai ser “encerrada”?
E eu estou usando entitymanager
*http://docs.jboss.org/hibernate/orm/4.1/javadocs/
[quote=bobleujr]Correto. Mas se eu for tratar o commit dentro do catch, como a transaction vai ser “encerrada”?[/quote]no catch você manda um rollback e fecha a transação.
Acredito que se nao der erro ela vai ser encerrada normalmente, caso de algum erro, voce pode fechar manualmente =D
Sim, esse é o ponto, eu dei o rollback no catch, ele apontou “Transaction marked as rollBackOnly”, não há um meio de parar a transaction no braço, há?
Eu testei fechando a entity manager com EntityManager.close(), mas o desempenho vai lá em baixo
[quote=bobleujr]Sim, esse é o ponto, eu dei o rollback no catch, ele apontou “Transaction marked as rollBackOnly”, não há um meio de parar a transaction no braço, há?
Eu testei fechando a entity manager com EntityManager.close(), mas o desempenho vai lá em baixo[/quote]Se já deu isso, os dados já não serão inseridos.
Agora, uma dúvida… Você está usando EJB ou Spring para gerenciar a transação?
Ainda não, mas acho melhor me informar sobre, haha!
[quote=bobleujr]Ainda não, mas acho melhor me informar sobre, haha! [/quote]Só não entendi pq você perde performance ao fechar um entitymanager. O que acontece?
Por causa do delay de criação de um novo objeto. Seria como se a cada transação errada ele tivesse que criar uma nova entitymanager, a qual tem um custo alto de tempo, pelo menos pelo que pude observar até agora !
[quote=bobleujr]Por causa do delay de criação de um novo objeto. Seria como se a cada transação errada ele tivesse que criar uma nova entitymanager, a qual tem um custo alto de tempo, pelo menos pelo que pude observar até agora ![/quote]Até hoje só vi esse problema quando o EntityManagerFactory é criado o tempo todo e não EntityManager… bizarro…
Yeah, muito estranho, nunca tive esse problema de delay ou coisa parecida.
Bom, mas valeu pela ajuda.