ActivitiOptimisticLockingException Retry

[thane]

Hi,

sometimes ActivitiOptimisticLockingException's like

VariableInstanceEntity[id=99, name=nrOfCompletedInstances, type=integer, longValue=1, textValue=1] was updated by another transaction concurrently
‍‍‍

occur and the hole process is stalled until the job ist executed again. Reducing lockTimeInMillis isn't an option, so is it safe to extend the ExecuteJobsRunnable class to allow an immediate second attempt ?

final List<String> failedJobs = new ArrayList<String>();
…
while (!currentProcessorJobQueue.isEmpty()) {
       String job = currentProcessorJobQueue.remove(0);
        try {
          commandExecutor.execute(new ExecuteJobsCmd(job));
        }
        catch( ActivitiOptimisticLockingException ex)
        {
           if( ! failedJobs.contains(job)){
              if (!currentProcessorJobQueue.isEmpty()) {
           currentProcessorJobQueue.add(0, job);
         } else {
           currentProcessorJobQueue.add(job);
         }
              log.info("ActivitiOptimisticLockingException job:" +job+ ", retry");
              failedJobs.add(job);
           } 
        }
        catch (Throwable e) {
…
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Thanks

-
kai

[jbarrez]

Are you running multiple nodes? Or are different threads/users are accessing the same process?

If so - the exception is expected when the same variable is updated by two threads - one shall be rollbacked, the other wins. So it is safe to retry the failing one (but it will now change the variable value to that particular value)

[thane]

Hi,

indeed the exception is not suprising. I'm just wondering about the behaviour after the exception occured.
[img]http://s7.directupload.net/images/140831/2tfu36ha.png[/img]

Two users A,B complete their User Task concurrently. One transaction looses and we get something like:
org.activiti.engine.ActivitiOptimisticLockingException: VariableInstanceEntity[id=12513, name=nrOfCompletedInstances,…

Let's say user A won, the job (execute the Service Task and end instance), triggered by user B, remains in the database until LOCK_EXP_TIME_ is reached and is executed again afterwards. So the hole process could be stalled for lockTimeInMillis (^= 5 minutes), which is not necessary in this context. (single node, multiple users)

ciao,

kai

[jbarrez]

Indeed - in such a setup it is indeed not helpful.  However, this case is different because it's a user task, there is no job involved.

In this case, you could catch the exception and retry yourself, without delay.