nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

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

Find more posts tagged with

Comments

frederikherema1

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

<br>Task task = taskService.createTaskQuery()&hellip;.singleResult();<br>task.setPriority(1);<br>taskService.saveTask(task);<br><br>task.setDueDate(..)<br>ProcessEngines.getDefaultProcessEngine().getTaskService().save(task)<br>

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:

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

Which runs OK.