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

bmaehr · February 1, 2022, 3:53pm

Hello,

I’m getting the infamous “org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only” exception in my camunda process.

In general I know what the exception means and have also solved this kind of exceptions in my own code, but not with camunda and spring boot starter involved yet. From my understanding my transaction configuration looks correct.

The use case is: The user presses the “proceed” button on the UI and then the camunda process is proceeded with the next service task. This service task is using a transaction in the Java implementation and can fail with an exception. Then the exception should be displayed to the user on the UI.

What’s happening is that on the UI there is instead of the expected exception the UnexpectedRollbackException.

Has someone an idea how the transaction configuration in the process and with the annotations in Java has to be to make it work correctly?

cpbpm · February 2, 2022, 5:02am

Would you please share your service task code snippet.

Few more references:
Camunda Best Practices - Dealing With Problems and Exceptions.

https://docs.camunda.org/manual/7.12/user-guide/spring-framework-integration/transactions/

rob2universe · February 8, 2022, 11:28am

Hi @baehr,

is your delegate code using a new separate transaction?

Is this helpful?
https://docs.camunda.org/manual/7.16/user-guide/spring-framework-integration/transactions/#using-inner-spring-transactions

@Transactional(value = "transactionManager", propagation = Propagation.REQUIRES_NEW, rollbackFor = {Throwable.class})

bmaehr · February 8, 2022, 12:29pm

@rob2universe Thank you for your reply.

I don’t think that this will solve the problem because source of the problem is, that there is already a separate inner transaction running. I think the solution would be to ha NO inner transaction but I don’t know how to achive this.
The service has only a transactional annotation which means it should be take part at the outer transaction but for some reason this seams not to work.

rob2universe · February 9, 2022, 8:23am

Hi @bmaehr, I believe you know what i am explaining below, so I am not sure where the disconnect is. May you can see it.

I had a very similar situation. In my delegate I was calling Camunda API to interact with another process instance. The call could fail and then marked the transaction for rollback. As a result I could not react to the real exception of the API call and handle it in my Java Delegate code. Participation of the API call in the original outer transaction was the issue.

The annotation shared above means the method call with the API call will be executed in a separate transaction. If this inner tx is now failing and marked for rollback, it will rollback but not mark the outer tx for rollback. The original exception gets propagated to the delegate code running in the outer tx and can be handled there. In my case I also used a new ProcessEngineContext beause my API call was an interaction with Camunda, just to be safe.

See delegate with error handling here:

github.com

rob2universe/custom-incident-handler/blob/db45fbb7099a0f806bd41eec247bbc32b125e6b8/src/main/java/com/camunda/example/service/RetryDelegate.java#L28

    
      
              this.innerJobRetryService = innerJobRetryService;
            }
          
          
  @Override
            public void execute(DelegateExecution exec) throws BpmnError {
          
          
    ObjectValue efiObj = exec.getVariableTyped("errorForIncident");
              ErrorForIncident efi = efiObj.getValue(ErrorForIncident.class);
              log.info("ErrorForIncident objectValue: {}", efi);
          
          
    try {
                log.info("Retrying failed job with id: {} for process instance id {}", efi.getJobId(), efi.getProcessInstance());
                innerJobRetryService.retryJob(efi.getJobId(), efi.getProcessInstance(), (String) exec.getVariable("error"));
          
          
    } catch (RuntimeException e) {
                log.info("Retrying failed job with id {} for process instance {} failed again with error: {}", efi.getJobId(), exec.getProcessInstance().getId(), e.getMessage());
                throw new BpmnError("100", "Retry did not resolve the incident" + e.getMessage());
              }
            }
          }

and service invocation in separate tx here:

github.com

rob2universe/custom-incident-handler/blob/db45fbb7099a0f806bd41eec247bbc32b125e6b8/src/main/java/com/camunda/example/service/InnerJobRetryService.java#L22

    
      
          public class InnerJobRetryService {
          
          
  ManagementService managementService;
            RuntimeService runtimeService;
          
          
  public InnerJobRetryService(ManagementService managementService, RuntimeService runtimeService) {
              this.managementService = managementService;
              this.runtimeService = runtimeService;
            }
          
          
  @Transactional(value = "transactionManager", propagation = Propagation.REQUIRES_NEW, rollbackFor = {Throwable.class})
            public void retryJob(String jobId, String processInstanceId, String errorDataValue) {
          
          
    try {
                // use new Engine context to avoid inner transaction polluting current engine context (changes would be committed)
                ProcessEngineContext.requiresNew();
                // setting data only to stop delegate from simulating error. Real-world service would not require this
                runtimeService.setVariable(processInstanceId, "error", errorDataValue);
                managementService.executeJob(jobId);
              } finally {
                ProcessEngineContext.clear();

bmaehr · June 21, 2022, 12:14am

Hello everyone,

Thank you for your suggestions. I tried them without success untils I realized, that I have made a stupid mistake.
In the controller sending the notification to the camunda process I had added an unnecessary @Transactional annotation, which was causing the problem, because camunda did correctly (like configured by me) open a new transaction for the service task. If that service task failed then the unnecessary transaction on hold in the controller produced the UnexpectedRollbackException.

Thank you @rob2universe

Bernhard