cancel
Showing results for 
Search instead for 
Did you mean: 

JobEntity exception

r3dge
Champ in-the-making
Champ in-the-making
Hi all,

I get an exception message in table act_ru_job : "JobEntity [id=44142329] was updated by another transaction concurrently".
Process instances are stopped in a service task without triggering the boundary error (as it does normally).

I have no idea to fix this problem. Could you help to analyse this problem ?

Regards,
6 REPLIES 6

r3dge
Champ in-the-making
Champ in-the-making
some precisions : i'm using Activiti 5.17.

Thanks for your help

martin_grofcik
Confirmed Champ
Confirmed Champ
Hi,

Can you create jUnit test for it pls?
https://forums.activiti.org/content/sticky-how-write-unit-test

Regards
Martin

r3dge
Champ in-the-making
Champ in-the-making
This problem occurs in production environment and i don't know how to reproduce it.
Asynchronous tasks seems to be involved.

r3dge
Champ in-the-making
Champ in-the-making
I have found a walkaround to retry canceled jobs :

<code>

   List<Job> jobs = pe.getManagementService().createJobQuery().withException().list();
   
   for(Job job : jobs)
   {
       try {
        if(job.getRetries()<=0){
         System.out.println(job.getId() + " - " + job.getExceptionMessage() + " - " + String.valueOf(job.getRetries()) + " - " + job.getProcessInstanceId() + " - " + job.getProcessDefinitionId());
         pe.getManagementService().executeJob(job.getId());
        }
       }
       catch(ActivitiException ae) {
          ae.printStackTrace();
      }
   }

</code>

However i don't know how to fix that problem…

r3dge
Champ in-the-making
Champ in-the-making
hi,

I guess the problem is fixed.

Two process engines are configured (activiti-explorer and activiti-rest), both working with the same database schema. Jobexecutor and asyncexecutor were enabled on both engines. This configuration generates locks on jobEntity (linked to async serviceTasks) : "JobEntity [id=44142329] was updated by another transaction concurrently".

I changed the configuration like this :

1st engine.properties :

# engine properties
engine.schema.update=false
engine.activate.jobexecutor=false
engine.asyncexecutor.enabled= false
engine.asyncexecutor.activate= false
engine.history.level=full

2nd engine.properties :

# engine properties
engine.schema.update=false
engine.activate.jobexecutor=false
engine.asyncexecutor.enabled=true
engine.asyncexecutor.activate=true
engine.history.level=full

Since this change i didn't get ActivitiOptimisticLockingException ("JobEntity [id=44142329] was updated by another transaction concurrently"). So far so good…


jbarrez
Star Contributor
Star Contributor
Optimistic locking exceptions are not a problem, in fact they are expected when running multiple async executors and are a proof of the logic working correctly.