Repository navigation
JpaLocalTxnInterceptor incorrectly assumes that @Transactional methods never handle exceptions #1136
Description
When reading through JpaLocalTxnInterceptor#invoke we can see the following comment:
//everything was normal so commit the txn (do not move into try block above as it
// interferes with the advised method's throwing semantics)
try {
txn.commit();
} finally {
//close the em if necessary
if (null != didWeStartWork.get() ) {
didWeStartWork.remove();
unitOfWork.end();
}
}This is a patently false assumption when considering persistence methods that follow another schema. Example:
@Transactional
public NiceResponse<EntityType> create(EntityType instance) {
try{
try {
entityManager.persist(instance);
entityManager.flush();
return NiceResponse.success(instance);
} catch (PersistenceException ex) {
// unwrap to find actual cause and use that to find out what happened
entityManager.getTransaction().rollback(); // this is theoretically optional
thow ex.getCause();
}
} catch (ConstraintViolationException ex) {
return NiceResponse.failure("Some useful error message", ex);
}
// possibly further catch blocks
}
Commiting the transaction after this method will throw an Exception all error cases, simply because the transaction has been rolled back already, but there's no Exception thrown to early-exit invoke.
Activity
Vogel612 commentedon Nov 15, 2017
Assuming I'd be assigned, it seems that checking for the transaction's status before trying to commit it would be appropriate.
I'd suggest using the following alternative:
I'm not terribly experienced with the detailed semantics of JPA Transactions though, so I might be missing something.
accomodate manually initiated rollbacks
accomodate manually initiated rollbacks. Fixes #1137 & fixes #1136.