Zdravím,
Rád bych upozornil na jednu slabinu této metody: jakmile dojde k
výjimce, provede se automaticky rollback. Takže pokud v té transakci
máte více operací, tak je ztratíte všechny.
Při použití čistého JDBC můžete u některých databází chybu ignorovat
a transakci commitnout i tak, ale to nebude fungovat na všech
databázích (např. postgresql automaticky při chybě také provede
rollback).
Pokud výše uvedené nevadí, rollback se má provést a celý problém je
jen ve výjimce v logu... já bych to klidně ignoroval, pokud se to bude
stávat vzácně. Pokud je to zcela běžná situace, pak bych použil čisté
řešení: kontrolovat stav před mazáním.
Kamil Podlešák
2010/6/30 Ondra Medek <xmed...@gmail.com>:
> Ahoj,
>
> chci vymazat JPA entitu, ktera muze byt refencovana pres cizi klice. V
> takovem pripade chci uzivateli zobrazit nejake hlaseni "nelze
> vymazat". Klasicke JDBC reseni bych delal pres DELETE FROM ...,
> odchytnu SQLException a zobrazim hlaseni. V JPA/Hibernate mohu delat
> neco podobneho:
>
> try {
> em.remove(...);
> em.flush();
> } catch () {
> // nelze vymazat
> }
>
> Tady mne zarazi, ze:
>
> 1. catch chyti jakousi obecnou javax.persistence.PersistenceException
> (nested org.hibernate.exception.GenericJDBCException a dalsi nested
> java.sql.BatchUpdateException: failed batch)
> 2. Hibernate zaloguje chyby:
> 14:43:09,890 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: null
> 14:43:09,890 ERROR [JDBCExceptionReporter] failed batch
> 14:43:09,890 ERROR [AbstractFlushingEventListener] Could not
> synchronize database state with session
>
> Tak si rikam, ze to asi nebude spravne reseni, kdyz Hibernate loguje
> chyby. Navic nechci mit v logu chyby, kdyz vlastne k zadne chybe
> nedoslo. Nemohu ovsem najit, jak se ma v takovem pripade spravne
> postupovat? Manualni kontrola JPQL/HQL query pred em.remove()? Pokud
> ano, neni to trochu tezkopadne?
>
> Dik za radu
> Ondra Medek
>
