Unexpected rollback exception analysis and transaction propagation strategy for nested transactions

UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only

1. Problem description and recurrence

jfoa Provides Audit The function of , The target method ( For example, add users ) Transaction management exists ,
stay Audit You need to query users ( Business management ), Finally, after the target method is executed Audit Insertion of records ( Business management ).
That is, add users ( Business ) Query users in ( Business ) Will throw an exception :

org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only

Literally means : An unpredictable rollback exception occurred , Because the transaction has been flagged, it can only be rolled back , So the transaction rolled back .

Now let's reproduce and describe this problem .

  @Around("audit()")
  public Object recordLog(ProceedingJoinPoint pjp) throws Throwable {
    
    Log log = null;
    Customer principal = null;

    try {
    
      // note1:  Get the currently logged in user here ,  Note that this method can throw exceptions 
      // 1) getCurrentCustomer  In transaction management 
      // 2) catch  The method call did not continue to throw exceptions 
      principal = customerService.getCurrentCustomer();
    } catch (Exception ignore) {
    
      LOGGER.debug("Get principal error!", ignore);
    }

    // ...  Omit some intermediate code 

    Object result;

    try {
    
      // note3:  Specific objectives and methods 
      result = pjp.proceed();
    }
    catch(Throwable throwable) {
    
      if(log != null) {
    
        log.setMessage("Execute Failed: " + throwable.getMessage());
      }

      throw throwable;
    }
    finally {
    
      // ...
    }

    return result;
  }

   // note2:  The target method is transaction management 
   @Audit(ResourceEnum.Customer)
   @Transactional
   @Override
   public Integer insertCustomer(@AuditObject("getName()") Customer user) {
    
      if(isValid(user)) {
    
         user.setPassword(
            SecurityUtil.generatorPassword(user.getAccount(), user.getPassword()));

         return customerDao.insert(user);
      }

      return null;
   }

Pay attention to the above note1 and note2, In this case, the exception of this article will appear .

2. Principle analysis

because spring Of @Transactional The default transaction propagation strategy of annotation is Propagation.REQUIRED,
PROPAGATION_REQUIRED It means , There's business at the moment , Use the current transaction , If there is no transaction at present, create a transaction . therefore , When
When the target method is called , Because the target method has transactions , When the target method is called, the transaction will be opened ,
When executed note1 when , getCurrentCustomer Methods
There is a business , According to the transaction propagation strategy , spring Will use the transaction of the target method ,
however getCurrentCustomer Yes try-catch Handle , also catch No more transactions are thrown ,
So when getCurrentCustomer When an exception is thrown , spring To execute rollback operation , however catch
Did not continue to throw exceptions , It will continue to be called until note3 Continue to execute , When the target method is called
Because it is normal, the call is completed , Therefore, it is necessary to implement commit, So this exception will be thrown .

2.0 Introduction to transaction propagation strategy

spring The following communication strategies are defined :

public enum Propagation {
    

	/** *  There's business at the moment , Use the current transaction , If there is no transaction at present, create a transaction  */
	REQUIRED(TransactionDefinition.PROPAGATION_REQUIRED),

	/** *  Support current transaction , If it doesn't exist , To execute in a non transactional manner . *  notes : For the transaction manager of transaction synchronization , It's a little different from having no business at all , *  Because it defines the transaction scope to which synchronization will be applied . *  result , Same resources (JDBC Connect 、Hibernate Conversation, etc ) *  Will be shared for the entire specified range . Be careful , It depends.  *  The actual synchronization configuration of the transaction manager . */
	SUPPORTS(TransactionDefinition.PROPAGATION_SUPPORTS),

	/** *  If the current is related to a transaction, the current transaction is used ,  If there is no transaction at present, an exception will be thrown . */
	MANDATORY(TransactionDefinition.PROPAGATION_MANDATORY),

	/** *  Create a new transaction regardless of whether there is a current transaction . *  If there is a current transaction, suspend the current transaction . */
	REQUIRES_NEW(TransactionDefinition.PROPAGATION_REQUIRES_NEW),

	/** *  Run in a non transactional manner ,  If there is currently a transaction ,  Then suspend the current transaction  */
	NOT_SUPPORTED(TransactionDefinition.PROPAGATION_NOT_SUPPORTED),

	/** *  Run in a non transactional manner ,  If there is currently a transaction ,  Throw an exception  */
	NEVER(TransactionDefinition.PROPAGATION_NEVER),

	/** *  If the current transaction exists , Then execute... In a nested transaction , Otherwise, the behavior is similar {@code REQUIRED}. *  Be careful :  The actual creation of nested transactions only applies to specific transaction managers . *  This only applies to JDBC DataSourceTransactionManager. *  some JTA The provider may also support nested transactions . */
	NESTED(TransactionDefinition.PROPAGATION_NESTED);

2.1 Default propagation policy

spring Of @Transactional The default transaction propagation strategy of annotation is Propagation.REQUIRED

public @interface Transactional {
    

    // ...
    
	/** * The transaction propagation type. * <p>Defaults to {@link Propagation#REQUIRED}. * @see org.springframework.transaction.interceptor.TransactionAttribute#getPropagationBehavior() */
	Propagation propagation() default Propagation.REQUIRED;

2.2 The problem summary

When methodA call methodB, And both parties have affairs ( Transaction nesting ),
And the communication strategies are Propagation.REQUIRED when , It will lead to two methods
Share a transaction ,methodB Mark the transaction as rollback ,methodA in commit This business ,
Then it will appear that the transaction has been marked for rollback （methodB logo ） Exception information for .

3. resolvent

Know the cause of the problem , Naturally, I know the solution , But different business scenarios may have different solutions ,
You need to choose the right solution according to your business scenarios

3.1 modify try-catch

For internal methods methodB Don't go ahead try-catch perhaps catch Continue to throw exception .

3.2 Modify the transaction propagation strategy

• If you modify an external transaction methodA Transaction propagation strategy of , be methodA Only the transaction can be cancelled ( Generally not available ).
• Modify the interior methodB Transaction propagation strategy of , Generally, it can be changed to REQUIRES_NEW, NOT_SUPPORTED, NESTED.
  NOT_SUPPORTED Convert internal transactions into non transactional operations .
  REQUIRES_NEW Will create a new transaction run .
  NESTED Run in nested transactions .

For example, the business scenario here , First is the need for transaction management , So I can use REQUIRES_NEW, NESTED,
secondly , audit Records and , getCurrentCustomer At no time should it affect the operation of core business logic , therefore ,
Finally, I choose to modify the transaction propagation strategy as REQUIRES_NEW To solve this problem . If your nested transaction is related to the main transaction ,
Then you should choose NESTED.

Last , One more thing to note : In the same class , Transaction nesting is subject to the outermost method , Nested transactions fail ; Transactions nested in different classes will take effect ;