Optimistic Locking Exception thrown during parallel tasks execution


#1

Hi,

I have a parallel gateway with three async service tasks, I want them to run in parallel.

But during execution it throws the below error :
An error happened while submitting the task form :
Cannot submit task form 8190f28c-6eeb-11e8-b622-fa163e5b9340: ENGINE-03005 Execution of ‘UPDATE ExecutionEntity[818ea893-6eeb-11e8-b622-fa163e5b9340]’ failed. Entity was updated by another transaction concurrently.

It is throwing optimistic locking Exception.

I tried marking async in the join gateway as per the below post

But not succeeded. Could you provide your suggestion here.

Thanks
Senthil


#2

Hi Senthil,

Could you please share an example of your process.

Best regards,
Yana


#3

Hi Yana,

PFB the bpmn file for parallel execution.
loan-approval.bpmn (9.5 KB)

I am trying with sequential execution but still facing the same issue with MariaDB 10.
loan-approval.bpmn (3.8 KB)

Please provide your suggestions here, we are totally blocked…

Thanks
Senthil


#4

Hi Senthil,

Your process is working for me.
Could you please mark the service tasks as “async before” and “exclusive” and try again?

Best regards,
Yana


#5

Hi Yana,

Actually, this process is working fine with MariaDB 5.x. But not working with MariaDB 10.2.x.
Have you tried with MariaDB 10.2.x.

Thanks
Senthil


#6

Hi Senthil,

And what about h2, have you tried with it?
Also I did ask you which camunda version do you use?

Best regards,
Yana


#7

Hi Yana,

It seems the sequential work flow is working fine with h2 db.
I have not tested with parallel gateway.

The issue exist with both 7.8.0 and 7.9.0 release of camunda

It will be great if we can get some quick suggestions on this. Because we are totally blocked and none of the workflow is executing with MariaDB 10.2.x release.

Thanks
Senthil


#8

Hi Yana,

All workflows are getting failed with the error - Optimistic Locking exception when integrating camunda engine with MariaDB 10.x release. Any sequential / parallel execution is failing.

Error during workflow execution :

An error happened while submitting the task form :
Cannot submit task form 8190f28c-6eeb-11e8-b622-fa163e5b9340: ENGINE-03005 Execution of ‘UPDATE ExecutionEntity[818ea893-6eeb-11e8-b622-fa163e5b9340]’ failed. Entity was updated by another transaction concurrently.

It is throwing optimistic locking Exception.

The same workflow is working fine till camunda release 7.8.0-alpha5 with Maria DB 10.x
And it is working fine with camunda 7.8.0 / 7.9.0 release and h2 database.

But it is not working from camunda 7.8.0-alpha6 release and Maria DB 10.x.

I have created a bug
https://app.camunda.com/jira/browse/CAM-9145

I have done a basic debugging with Camunda 7.9.0 engine.

The below statement returns the updateCount as “-2”. The update count should be “1” for avoiding optimistic locking exception.

flushResult = persistenceSession.flushOperations();
Method – protected void flushDbOperations(List operationsToFlush)
File – org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager

Really it is a blocking issue.

Transaction Log shows there is a try to apply the lock on ACT_GE_PROPERTY twice

2 lock struct(s), heap size 1136, 1 row lock(s), undo log entries 1
MySQL thread id 3508, OS thread handle 140480266315520, query id 56760 demo cleaning up
Trx read view will not see trx with id >= 10270, sees < 10269
TABLE LOCK table db03.ACT_GE_PROPERTY trx id 10270 lock mode IX
RECORD LOCKS space id 224 page no 3 n bits 80 index PRIMARY of table db03.ACT_GE_PROPERTY trx id 10270 lock_mode X locks rec but not gap
Record lock, heap no 14 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 9; hex 6e6578742e64626964; asc next.dbid;;
1: len 6; hex 00000000281e; asc ( ;;
2: len 7; hex 4e0000021628f0; asc N ( ;;
3: len 3; hex 323031; asc 201;;
4: len 4; hex 80000003; asc ;;

—TRANSACTION 10269, ACTIVE 2328 sec
2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 3504, OS thread handle 140481065899776, query id 56744 demo cleaning up
TABLE LOCK table db03.ACT_GE_PROPERTY trx id 10269 lock mode IX
RECORD LOCKS space id 224 page no 3 n bits 80 index PRIMARY of table db03.ACT_GE_PROPERTY trx id 10269 lock_mode X locks rec but not gap
Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 15; hex 6465706c6f796d656e742e6c6f636b; asc deployment.lock;;
1: len 6; hex 000000001f17; asc ;;
2: len 7; hex f6000001dd0150; asc P;;
3: len 1; hex 30; asc 0;;
4: len 4; hex 80000001; asc ;;


#9

Hi Senthil,

If 7.8.0-alpha5 is working, this problem could be related to the batch processing.
What is your db configuration? Is it jdbcBatchProcessing disabled?
Could you please try to disable the jdbcBatchProcessing [1].

[1] https://docs.camunda.org/manual/7.8/user-guide/process-engine/database/#jdbc-batch-processing

Best regards,
Yana


#10

Hi Yana,

After disabling jdbcBatchProcessing, the workflow is executed properly.
But Why jdbcBatchProcessing (with value ‘true’) configuration is not working here ?

As per my understanding, this issue still needs to be addressed.

Thanks
Senthil


#11

Hi Senthil,

My colleague pointed me that such issue is known with some maria db driver versions:
https://app.camunda.com/jira/browse/CAM-8891
What is your driver version, could it be the same problem?

Best regards,
Yana


#12

Hi Yana,

Thanks for the update.
Yes, It is a maria db driver issue.
As you specified it is same as https://app.camunda.com/jira/browse/CAM-8891.

Camunda 7.9.0 - Maria DB 10.2.x - Maria db driver above 2.0.3 is not working (Meaning till Maria DB java client 2.0.3 no issues)

Thanks
Senthil