Description of problem:

We have a process definition as the attached file "proc_encendido_v1.bpmn2". When the execution process arrives to "Subproceso de encendido de dispositivo", it receives a list of "dispositivos" and by using each element of the list, it triggers a process. That reusable subprocess calls a process which contains a Timer event that we can see in the attached file "task_encender_timer_v1.bpmn2".

When we try to execute the process instance with 'SINGLETON' strategy, it works fine. However, when we try to execute process instance with 'PER_PROCESS_INSTANCE' strategy it fails with below exception:

~~~
(jBPMClusteredScheduler_Worker-2) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffff0a509d7f:-de9c94a:56def4b3:14b, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@782df646 >: javax.persistence.OptimisticLockException: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): org.jbpm.persistence.processinstance.ProcessInstanceInfo#1
~~~

We discussed this issue with our engineering team and they told us this works as expected as the process is built with explicit race condition on single process instance - the parent process instance. So the reason why it throws exceptions (optimistic lock exception) is because the parent process has a sub-process with characteristic multiple-instances and creates 10 instances of each child process. Then each child process triggers after 1 second and completes. When it completes, it sends a signal to parent process telling that it has been completed. All child instances do the same at pretty much concurrently which obviously leads to optimistic lock exceptions.

However, this is not the case for singleton as there is a single instance of ksession which is synchronized and thus disallows concurrent updates on same ksession.

Then we received some options to avoid this isue:

1. Use pessimistic locking.

Pros: no modifications on process design.
Cons: it's recommended only if we are performing only read operations on DB tables. We perform read and write operations in BRMS so its not good idea to use.

2. Change process design to minimize or eliminate concurrent notifications to the parent process.

Pros: avoid the problem.
Cons: need to modify the process design.

3. Change call activity to not wait for child so there won’t be any need for notifying parent

Pros: avoid the problem.
Cons: need to modify the process design and the execution logic.

4. Use alternative way of notifying parent process as described here [1]. The idea is to skip the regular notification mechanism that directly calls the parent process instance to avoid concurrent updates and instead use signal events (catch in main process instance and throw in sub-process instance).

Pros: avoid the problem for this case and other processes with the same problem.
Cons: modify the process design although the modifications wouldn't be too costly.

In spite of these arguments and options, we should modify the process design for working. However it is a correct BPMN2 design so it should work without issues.

Version-Release number of selected component (if applicable):

BPMS 6.2.0 + EAP 6.4.5 + PostgreSQL/Oracle

How reproducible:

You should import the attached processes to the project in the business-central. The process can be started from a java script through REST API (RESTTriggerExample.java). We can check the results configuring the project as SINGLETON and PER_PROCESS_INSTANCE.

Steps to Reproduce:
1. EAP 6.4.5 + BPMS 6.2 + PostgreSQL/Oracle
2. Processes are imported to the default project
3. Process is started from a java script through REST API.

Actual results:

• if we configure the project as SINGLETON, it works
• if we configure the project as PER_PROCESS_INSTANCE, we have the same "errors"

Expected results:

• if we configure the project as SINGLETON or PER_PROCESS_INSTANCE, they should work