Database Exception in process containing two callActivities with multiInstanceLoopCharacteristics

cancel
Showing results for 
Search instead for 
Did you mean: 
frauke_heyl
Active Member

Database Exception in process containing two callActivities with multiInstanceLoopCharacteristics

Hi everybody,

I have a serious problem. The process contains two callActivities with a multiInstanceLoopCharacteristics, both working on the same variable as activiti:collection.

After executing the first call activity, the collection variable is cleared by some service task. Then the second call activity fails with a database exception:

org.apache.ibatis.exceptions.PersistenceException:
### Error updating database.  Cause: org.h2.jdbc.JdbcSQLException: Referentielle Integrität verletzt: "ACT_FK_VAR_EXE: PUBLIC.ACT_RU_VARIABLE FOREIGN KEY(EXECUTION_ID_) REFERENCES PUBLIC.ACT_RU_EXECUTION(ID_) ('8')"
Referential integrity constraint violation: "ACT_FK_VAR_EXE: PUBLIC.ACT_RU_VARIABLE FOREIGN KEY(EXECUTION_ID_) REFERENCES PUBLIC.ACT_RU_EXECUTION(ID_) ('8')"; SQL statement:
INSERT INTO ACT_RU_VARIABLE (ID_, REV_,
          TYPE_, NAME_, PROC_INST_ID_, EXECUTION_ID_, TASK_ID_, BYTEARRAY_ID_,
          DOUBLE_, LONG_ , TEXT_, TEXT2_) VALUES

Everything works fine if the collection for the second call activiti is not empty.

The worst thing about it is, that it worked with an older version (Activiti 5.11) and many of our cusomers have processes designed like that, which now will fail when we update to Activiti 5.22.

Please help me to find some kind of workaround for that problem.

Thanks

Frauke

1 Reply
frauke_heyl
Active Member

Re: Database Exception in process containing two callActivities with multiInstanceLoopCharacteristics

Thanks to my colleague Roger we found a workaround for this problem by adding a check

 if (nrOfActiveInstances < 0) {
      return;
 }

to the leave method of ParallelMultiInstanceBehavior

and

if (loopCounter > nrOfInstances && nrOfInstances > 0) {
            return;
}

to the leave method SequentialMultiInstanceBehavior.

Maybe not the most elegant thing to do, but it solved our problem.