I have configured my BPMN with timer events and have deployed the designs in platform. During the process instances execution the token reaches the timer events and once timer fires then there is a flow consists of service tasks which internally calls third party APIs (service task - Create Unscheduled at origin ticket ).
The issue here is we found 1558 number of calls to this third party API. In HI_JOB_LOG table we found that there are 1558 entries made against the process instance id and eventId = Event_048rn4i with JOB_EXCEPTION_MSG = “ENGINE-03005 Execution of ‘DELETE TimerEntity[d048352b-c602-11ec-b13b-00ff8136e8e3]’ failed. Entity was updated by another transaction concurrently.”
We are not sure what is causing the issue with timer event ending up in executing post timer flow 1558 times.
It looks like you have something else reaching in and setting ${duration} , since that’s not being set in the process.
That’s very likely to cause an Optimistic Locking Exception (which is what the error message highlighted is saying). You cannot have two different things update the same row of the database with overlapping times. Once one of methods picks up the row, the other one cannot touch it until the first one finished writing. If “other” writes to the row after “first” picks it up, then you get the error above. That will often cause a roll-back and retry, which cause your timer to run again, which might be causing your “update timer” function to happen again, which then causes it all over again.
13:15:00 to 13:58:00 – in the span of 50 min, we have 1558 records in the HI_JOB_LOG and service-task (http connector)
We believe. if the timer had issue, it should retry at that timer activity only instead of going to next activities in the timer flow.
As Camunda commits the transaction at the end…
In the process flow, instance picked up the timer event, successfully executed and wants to delete the timer event from job log. But failed to do so
Origin BPD flow - Logs analysis to find out the cause for optimistic locking
At 13.04:00, timer was fired on time, taken up the job log and went ahead to persists entry in the job log.
Thread went to sleep state
Pod was unable to make the DB connection for sometime and then DB connection was restored after sometime.
This has caused the optimistic locking for all the transactions
We think Camunda transaction should not leave anything uncommitted before going to thread sleep.
Destination BPD flow - Logs analysis
At 13:09:00 - POD was not able to make the DB connection
DB connection was restored at 13:14:00.
This did not cause any locking and job log update happened successfully
We do see errors while committing the transaction and locking is one step down the commit.
During end event, camunda is committing… if exception occurs then it will rollback the transactions til the timer activity.
Workaround provided - Use Async before configuration in the service task Create Unscheduled at origin ticket -->This makes sure to commit the transactions before and go with the next steps.
We need to understand what could cause the error and how to fix in this case?
Due to the error, timer event was triggered multiple time till finally it was able to delete it from job log table.
Can you please refer to some documentation which could clarify this issue or its fix.
Error: Execution of DELETE TimerEntity failed
[ ENGINE-03005 Execution of ‘DELETE TimerEntity[d048352b-c602-11ec-b13b-00ff8136e8e3]’ failed. Entity was updated by another transaction concurrently.”]
As mentioned before, that is an Optimistic Lock Exception, meaning that something else wrote to the record while that particular thread was expecting to have an exclusive lock.
This sometimes happens if you have parallel paths AFTER the timer, since Camunda 7 tries to avoid committing to the DB (an expensive operation) until necessary.
If you have things that are going to hit the records concurrently, put an Async Before on the first task after the timer. This will help you narrow down exactly where the OLE is actually happening.
