Due date setting with Activiti 5.11

[maclab]

Hello
With Activiti 5.10 change due date was possible with the following 2 lines

task.setDueDate(..)
ProcessEngines.getDefaultProcessEngine().getTaskService().save(task)‍‍

With Activiti 5.11 we have the following exception on the line 2 :

Caused by: org.activiti.engine.ActivitiOptimisticLockingException: TaskEntity[109811] was updated by another transaction concurrently

Any idea?

Merry Christmas

[frederikherema1]

This is a know limitation, your code is probably something like this:


Task task = taskService.createTaskQuery()….singleResult();
task.setPriority(1);
taskService.saveTask(task);

task.setDueDate(..)
ProcessEngines.getDefaultProcessEngine().getTaskService().save(task)

The issue is, after the first saveTask, the internal "revision" isn't updated. So when saving again, the Database will have a different revision than the POJO that is still in memory. Solution for this is to:

• Group your access to the setter-methods for the POJO and only save once


• Refetch (query) the task between individual saveTask() calls…

[jbarrez]

Actually, I fixed that in 5.11 Frederik. Before, we didn't properly do optimistic locking. The revision is now updated in the task object when it sucessfully updates in the database.

So the only things that can go wrong here is that for some reason you have a task object with an older revision when you call the saveTask method.

[maclab]

Ok thanks .
My pojo wasn't "refreshed".
What is difference between

task = taskService.createTaskQuery()…singleResult()
task.setPriority(1);
taskService.save(task)

and

task = taskService.createTaskQuery()…singleResult()
taskService.setPriority(taskId, 1);

Is only the task pojo which is updated in the first case and not in the second ?
Thanks

[maclab]

Sorry a little error in my request code

task = taskService.createTaskQuery()…singleResult()
task.setPriority(1);
taskService.save(task)

and

task = taskService.createTaskQuery()…singleResult()
taskService.setPriority(task.getId(), 1);

[ronald_van_kuij]

I would suspect them to have identical behaviour… Why the questuion? Don't they have the same behaviour?

[jbarrez]

They should have the same behavior if the code is executed sequentially and no other threads are doing something with the task at the same time.

The first code snippet will use the provided task, and check the revision of the task.
If the revision doesn't match (ie an 'UPDATE … WHERE ID=x AND REV_=y' is done), nothing is updated and an optimistic locking exception has happened.

The second snippet will always fetch the task from the database, thus ensuring the revision is always at the latest version.

[jbarrez]

I verified your case with the following test:


  public void testRevisionUpdatedOnSaveWhenFetchedUsingQuery() {
    Task task = taskService.newTask();
    taskService.saveTask(task);
    assertEquals(1, ((TaskEntity) task).getRevision());
   
    task.setAssignee("kermit");
    taskService.saveTask(task);
    assertEquals(2, ((TaskEntity) task).getRevision());
   
    // Now fetch the task through the query api
    task = taskService.createTaskQuery().singleResult();
    assertEquals(2, ((TaskEntity) task).getRevision());
    task.setPriority(1);
    taskService.saveTask(task);
   
    assertEquals(3, ((TaskEntity) task).getRevision());
   
    taskService.deleteTask(task.getId(), true);
  }

Which runs OK.