topic Re: Due date setting with Activiti 5.11 in Alfresco Archive

Due date setting with Activiti 5.11

maclab — Fri, 21 Dec 2012 12:36:29 GMT

HelloWith Activiti 5.10 change due date was possible with the following 2 linestask.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:

Re: Due date setting with Activiti 5.11

frederikherema1 — Fri, 21 Dec 2012 13:47:25 GMT

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…

Re: Due date setting with Activiti 5.11

jbarrez — Fri, 21 Dec 2012 14:22:17 GMT

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.

Re: Due date setting with Activiti 5.11

maclab — Fri, 21 Dec 2012 17:44:15 GMT

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

Re: Due date setting with Activiti 5.11

maclab — Fri, 21 Dec 2012 17:51:40 GMT

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);

Re: Due date setting with Activiti 5.11

ronald_van_kuij — Sun, 23 Dec 2012 15:06:50 GMT

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

Re: Due date setting with Activiti 5.11

jbarrez — Wed, 26 Dec 2012 08:54:33 GMT

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.

Re: Due date setting with Activiti 5.11

jbarrez — Wed, 26 Dec 2012 09:27:43 GMT

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.