Thread-safety of process engine classes

Are camunda classes safe for read-only access in callbacks?

Let’s examine the following scenario:

class MyTaskListener extends ExecutionListener{
  private [this] val logger = getLogger
  override def notify(execution: DelegateExecution): Unit = {

     doSomethingAsync().onComplete {
         case Success(s) => logger.info(execution.getId)
         case Failure(e) => println(s"Error: ${e.getMessage}")
      }

}

In scala syntax, the lambda inside the onComplete is not executed inside the same thread as the notify function. I have two questions related to this use case:

  • Is there a risk that this code doesn’t work even if we only access the delegateExecution properties to log them, without performing operation in the callback? For example, if a part of the execution internals are fetched lazily from a database, nothing guarantees that when we access them in a separate thread they will still be there
  • Could this code log the wrong information (i.e. because the execution contains mutable fields, can these be changed between the notify call and the callback?
1 Like

Hi Edmondo,

in general, the Camunda process engine is thread-safe. In case of the DelegateExecution, most of the fields are instantiated and can be accessed from another thread (e.g. the execution id). It can be that a field (e.g. for an entity like a super execution) is not instantiated and would be loaded lazily. This would fail if you aren’t in a command context.

To deal with it:

  • store the information in a field, or
  • use the Api to get the information, or
  • open a command context via ProcessEngineConfiguration

Does this help you?

Best regards,
Philipp

1 Like