Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JpaLocalTxnInterceptor incorrectly assumes that @Transactional methods never handle exceptions #1136

Closed
Vogel612 opened this issue Nov 15, 2017 · 1 comment

Comments

@Vogel612
Copy link
Contributor

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.

@Vogel612
Copy link
Contributor Author

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:

try {
  if (txn.isRollbackOnly()) {
    txn.rollback();
  } else {
    txn.commit();
  }
}

I'm not terribly experienced with the detailed semantics of JPA Transactions though, so I might be missing something.

Vogel612 added a commit to Vogel612/guice that referenced this issue Nov 16, 2017
When methods marked @transactional initiated a rollback without
throwing an exception, the Interceptor threw an exception with
either "Transaction not active" or "Transaction marked for rollback only"..

Fixes google#1136
copybara-service bot pushed a commit that referenced this issue Apr 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant