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?
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.
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.
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.