Right, you probably mean
public RuntimeException convert(HibernateException e, LockOptions
lockOptions) {
if ( e instanceof StaleStateException ) {
PersistenceException converted =
wrapStaleStateException( (
StaleStateException ) e );
handlePersistenceException( converted );
return converted;
}
else if ( e instanceof org.hibernate.OptimisticLockException ) {
PersistenceException converted = wrapLockException( e,
lockOptions );
handlePersistenceException( converted );
return converted;
}
else if ( e instanceof org.hibernate.PessimisticLockException )
{
PersistenceException converted = wrapLockException( e,
lockOptions );
handlePersistenceException( converted );
return converted;
}
else if ( e instanceof ObjectNotFoundException ) {
EntityNotFoundException converted = new
EntityNotFoundException(
e.getMessage() );
handlePersistenceException( converted );
return converted;
}
else if ( e instanceof org.hibernate.NonUniqueResultException )
{
NonUniqueResultException converted = new
NonUniqueResultException(
e.getMessage() );
handlePersistenceException( converted );
return converted;
}
else if ( e instanceof UnresolvableObjectException ) {
EntityNotFoundException converted = new
EntityNotFoundException(
e.getMessage() );
handlePersistenceException( converted );
return converted;
}
else if ( e instanceof QueryException ) {
return new IllegalArgumentException( e );
}
else if ( e instanceof TransientObjectException ) {
try {
markAsRollback();
}
catch ( Exception ne ) {
//we do not want the subsequent exception to
swallow the original one
log.error( "Unable to mark for rollback on
TransientObjectException:
", ne );
}
return new IllegalStateException( e ); //Spec 3.2.3
Synchronization
rules
}
else {
PersistenceException converted = new
PersistenceException( e );
handlePersistenceException( converted );
return converted;
}
}
Funny enough in all this cases handlePersistenceException() will be called
which in its turn will try to mark the
transaction for rollback. So really only QueryException will not mark the
transaction for a rollback.
That said, it seems that the handling of ConstraintViolationException
should actually be moved into the above methods as
well. This case all exception handling is done in one place.
--Hardy
On Mon, 22 Feb 2010 14:53:35 -0300, Emmanuel Bernard
<[email protected]> wrote:
> Yes I think that's the correct behavior with a small twist.
> Every non HibernateException and PersistenceException should mark for
> rollback.
> HibernateException and PersistenceException have different rules that
> are implemented somewhere nearby.
>
> On 22 févr. 2010, at 18:47, Hardy Ferentschik wrote:
>
>> Hi,
>>
>> I was just looking at HHH-4676 - "Any interceptor exception (RTE) should
>> mark the tx for rollback"
>> and was wondering whether we can generally say that in JPA any
>> RuntimeException will mark the current
>> transaction for a rollback.
>>
>> Currently we have this in AbstractEntityManagerImpl:
>>
>>
>> public RuntimeException convert(RuntimeException e) {
>> RuntimeException result = e;
>> if ( e instanceof HibernateException ) {
>> result = convert( (HibernateException) e );
>> }
>> else if (e instanceof ConstraintViolationException) {
>> markAsRollback();
>> }
>> //if any RT exception should mark the tx for rollback, convert
>> the
>> last
>> else if into a else
>> return result;
>> }
>>
>>
>>
>> Should this be changed to:
>>
>>
>> public RuntimeException convert(RuntimeException e) {
>> RuntimeException result = e;
>> if ( e instanceof HibernateException ) {
>> result = convert( ( HibernateException ) e, null );
>> }
>> else {
>> markAsRollback();
>> }
>> return result;
>> }
>>
>> Meaning all RuntimeExceptions will mark the current transaction for
>> rollback? Any comments?
>>
>> --Hardy
>> _______________________________________________
>> hibernate-dev mailing list
>> [email protected]
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/hibernate-dev
