Should JavaDelegate classes for Camunda BPM be thread safe?

Question

The main question is about static fields and singleton instances (for configs, etc.) - are instances of one process running in different threads, as usual servlet requests?

If look deeper - do different @ProcessApplication run in one JVM and will see the same singletons? I don't think so. I know exactly that their classes don't see each other and can have equal names (because of different classLoaders?)

Haven't found any meaningful info on these important themes about Camunda, will appreciate your answers.

Answer 1

I had this same question for one of our scenario while back, and read their Javadoc as mentioned here for a servlet container. Extracting Javadoc,

Invocation Semantics

When the {@link #execute(java.util.concurrent.Callable)} method is invoked, the servlet process application modifies the context classloader of the current Thread to the classloader that loaded the application-provided subclass of this class. This allows,

• the process engine to resolve {@link JavaDelegate} implementations using the classloader of the process application

This pretty much explain everything you want to know, since the behavior is very similar to how a web container operates. If you want to know how other container implementations behaves, you can check the respective Javadocs of classes in this package.

---

To answer your question:

Yes. Thread-safety is required for the shared-resources accessed by JavaDelegate in the same process application. According to the documentation (see below) they create a new instance of delegate each time a task is going to be executed.

Note!

Each time a delegation class referencing activity is executed, a separate instance of this class will be created. This means that each time an activity is executed there will be used another instance of the class to call execute(DelegateExecution).

Therefore, at any time there can be many delegate instances actively running due to the multiple invocation of Process Definitions. So, if they are accessing a shared resource, then they need to be synchronized (thread-safe), because, that shared resources (static or singleton) is local to the process application and loaded by respective application classloader according to above Invocation Semantics Javadoc.

Hope this helps.