I have two user tasks that I am trying to complete using the rest api. I complete the first one, get the task id of the second from the process instance id, and then attempt to complete the second and it fails with a concurrency exception.
500 - {“type”:“RestException”,“message”:“Cannot complete task ae1712e1-a517-11ea-8c42-a08869faabe1: ENGINE-03005 Execution of ‘DELETE TimerEntity[ae1712df-a517-11ea-8c42-a08869faabe1]’ failed. Entity was updated by another transaction concurrently.”
I’ve been reading the forum and the documentation and tried two different approaches to fix this. I changed the job executor lock duration which worked but I had to set it very low and put a wait in my code because in this particular instance I am sort of fast forwarding through these user steps. It also concerned me that I was changing the lock duration for the entire process, and I assume for our other processes also.
So I tried adding the asyncBefore and asyncAfter boundaries to my bpmn. That also worked, but it doesn’t seem like I should need it because they are both user tasks.
Also, my users tend to work pretty fast sometimes and I’m concerned that if the 5 minute lock duration applies to these user tasks, maybe I need to add the async boundaries around all of my user steps.
Thanks so much. Here is my whole bpmn.
We tag our processes with business keys. So the sequence of events that is causing this is as follows.
I have a process already in the unclaimed user step tagged with a business key.
get the process instance using the business key.
modify the variables setting as follows : {
assignee: “someemailaddress”,
notCME: true
}
get the task using the process instance
complete the task
get the task using the process instance
complete the task
that final step should send it down the ‘discard’ route and eventually end the process, but instead it throws that timer entity exception.
As you probably noticed, we have boudary events on most of our user tasks that call a script to notify the app server and update sockets so our users get an updated list. Also, once an item is claimed in the first step, it stays with that person unless they reassign it to another, so we aren’t too concerned about two people grabbing the same task at the same time.
Any thoughts you have would be appreciated. This model started out fairly simple and grew more complex over time, so I am sure there are lots of ways it could be improved. It is mostly working for us right now though.
they call the app server, which then notifies the users via a socket, to tell them that something changed.
They need a real time update of which processes are in each user step.