Problem in multi-instances and subprocess.

Showing results for 
Search instead for 
Did you mean: 
Member II

Problem in multi-instances and subprocess.

For a customer i have to create a multi instancied call-activiti that call a subprocess witch call an other subprocess and echange with an asynchronous webservice.

When the webservice responds a lot of optimistic locking exceptions occure because the exclusive flag does not apply for child processes.

When I see the source-code, indeed, the exclusive flag operate only for the current process instance not for childs :

 AcquiredJobs acquiredJobs = new AcquiredJobs();
    List<JobEntity> jobs = commandContext
      .findNextJobsToExecute(new Page(0, maxNonExclusiveJobsPerAcquisition));
    for (JobEntity job: jobs) {
      List<String> jobIds = new ArrayList<String>();
      if (job != null && !acquiredJobs.contains(job.getId())) {
        if (job instanceof MessageEntity && job.isExclusive() && job.getProcessInstanceId() != null) {
          // wait to get exclusive jobs within 100ms
          try {
          } catch (InterruptedException e) {}
          // acquire all exclusive jobs in the same process instance
          // (includes the current job)
          List<JobEntity> exclusiveJobs = commandContext.getJobEntityManager()
          for (JobEntity exclusiveJob : exclusiveJobs) {
            if (exclusiveJob != null) {
              lockJob(commandContext, exclusiveJob, lockOwner, lockTimeInMillis);
        } else {
          lockJob(commandContext, job, lockOwner, lockTimeInMillis);
If i see the request it's seems ok :
  public List<JobEntity> findExclusiveJobsToExecute(String processInstanceId) {
    Map<String,Object> params = new HashMap<String, Object>();
    params.put("pid", processInstanceId);
    params.put("now", Context.getProcessEngineConfiguration().getClock().getCurrentTime());
    return getDbSqlSession().selectList("selectExclusiveJobsToExecute", params);
But according to BPMN 2.0 specifications i don't think that is a correct behaviour.
Do you think correct it in next v 5.xx versions ?
2 Replies
Established Member II

Re: Problem in multi-instances and subprocess.

Hi Olivier,

Per Activiti documentation on exclusive jobs, Activiti User Guide, all jobs that are marked 'exclusive' won't be executed concurrently. Also per documentation, all BPMN nodes including sub process, services are set to be 'exclusive' by default. This is a feature of Activiti since version 5.9 to solve issues discussed here Activiti User Guide 

So in short, you should not have locking problem using multi-instance sub process with async web service. 

I have tried with a simple model such as below (sub process is set to be multi-instance by 4) and with the asynchronous web service call inside.

My unit test completed successfully. There were 4 instances of the sub process created. The async web service jobs were all executed without any locking exception and the instance was completed.

Here's a snippet of the logs.

Running org.activiti.designer.test.MultiInstanceTest
INFO: Instance started, id 5 multiInstanceProcess:1:4
INFO: Initiate service id 16
INFO: Initiate service id 14
INFO: Initiate service id 18
INFO: Initiate service id 20
INFO: Running processes: 0
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 45.552 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 47.921s
[INFO] Finished at: Mon Jan 09 13:48:17 ICT 2017
[INFO] Final Memory: 10M/166M
[INFO] ------------------------------------------------------------------------

If you still have issue, could you share a simple unit test to demonstrate your problem? 

Hope this helps you a bit,


Thong Huynh


Re: Problem in multi-instances and subprocess.

Hello Olivier,

I opened up your project and I believe the root cause of the optimistic locking exceptions is the following setVariable() call in your callWebServie class:

((ExecutionEntity)execution).setVariable("reservation", postForLocation);

Considering this is a parallel multi-instance loop, it is possible that this setVariable call will trigger the optimistic locking exceptions. Try testing without the setVariable call to determine if this really is the cause.