Externalize Transaction Management using Standalone Process EngineConfiguration with Db configuration with .conf

we are trying to externalize Transaction Management, but are facing issue with using StandaloneProcessEngineConfiguration and its db configuration will be set thru “reference.conf” file in Configuration class where we extends to StandaloneProcessEngineConfiguration. but we are new to camunda transactions and not sure how to manage external transaction management. i could figur out a flag to externalTransactionManagment,

I have tried setting externalTransactionManagment, as true and by using @EnableTransactionManagement, i have used @Transactional(propagation=Propagation.REQUIRES_NEW) but it was not working and at the same time it was not giving any exceptions.

Can any one guide us with help of this flag how to manage transaction and more over we are not using SpringTransaction, any other alternate that fits with Camunda StandaloneProcessEngineConfiguration

Help much appreciated!!

Thanks in advance !!


Any help for this issue? We are also facing a similar issue…

I also have some interest in Camunda’s transaction management - wondering if it’s along the same lines.

Within Camunda, the BPMN execution engine, we have its transaction manager responsible for insuring we properly maintain the state of the process token as it progresses along the model instance. So, from the time the instance initiates and through to completion, Camunda maintains consistency (following expectations regarding normal transaction services supporting ACID properties).

Now suppose our Camunda BPMN model instance, during the course of execution, calls upon services representing a managed resource. Do we want these external, managed resources to fall into Camunda’s execution context? Meaning, do we want the process token to reverse and go back to the beginning if the external resources (i.e. ReST service) encounters an error? Probably not.

The reason we need separate contexts is so that Camunda is able to both reasonably receive and handle the error as a business event. Therefore, we start a new context within our external service. If the external service then throws an error, the process model responds per business scenario - the exception is handled as a business event.

In supporting this view, we avoid joining external service integration via usage of Java JTA into one continuous, Camunda initiated, transaction context. Instead we use something like a try/catch/finally (or reactive/async pattern) so that our process model, and supporting implementation logic, reacts per expressed logic - avoiding the general effects of a rollback.

Thank you Gary!
like our requirement is to manage transaction on multiple Camunda calls within single api call… like
We have one call to add comments and after that we have call to complete the task.
Let say we have added comment and it got updated to DB, but Complete task call fails, the we can’t revoke comments, to avoid this can we have this both calls into single transaction?
Can you please suggest, if there is any solution to manage this scenario.

Thanks again for your kind reply… looking forward for your reply :slight_smile:


You said that you can’t revoke the comments if the “complete task” ReST API fails?


  1. create comment
  2. complete task

If “complete task” fails you can’t clear the comments?

In javadocs, there’s a method:


package: org.camunda.bpm.engine.impl.persistence.entity
class: CommentManager
method: deleteCommentsByTaskId

I haven’t tested this logic - but it seems reasonable.

So, you can then:
note: not sure if you need to claim some sort of task ownership before entering this code block. But, the java API looks like it has this feature - if ownership is required.

  1. attempt to “complete task”
    note: rather than putting code in the “catch” section…
    2a) after “complete task” (and the request doesn’t fail)
    2b) verify that the task completed (note: I’m assuming the status updates - if not, we’ll need to look for another solution to allow additional time for the Camunda system to catch up)
    3a) if task has verified as complete, then just leave the comments
    3b) if the task doesn’t verify as complete (i.e. left not-complete), then use the java API call “deleteCommentsByTaskId”

If it’s required… I’d also make sure that you’re able to get ownership of that task to avoid some other session from making changes during execution.

Before leaving the code block - recommend something like a “finally” block to release ownership.

I’m always sensitive to claiming/releasing tasks. Especially important in a high-volume system. I’d also review sync/async requirements - if this applies.

Wanted to add an additional note on this topic - specific about opening Java transactions within custom Beans (etc). The concern I’d have (and this can be mitigated with testing) is that we also have Camunda’s system infrastructure interacting with the database. And, a new custom-code transaction may gum up the infrastructure’s access to critical underlying persistence (DB).