All the workflows are getting failed when integrating Maria DB 10.2.x and Maria DB connector >=2.1. The batchUpdate implementation is having some reasonable changes in MairaDB Connector >=2.1 which returns "-2" as successful result while updating in batch.

But Camunda bpm engine is checking the updateCount value whether it is 1 or not. If it is "1" then engine considers it is a successful result other wise, an optimistic locking exception is thrown.

We have received the following from MariaDB engineers:

The “Entity was updated by another transaction concurrently” error message is internal to Camunda.
I might be wrong, but my guess would be the new batching implementation introduced in connector 2.1.0 when the maria db server is >=10.2.

Example :to simplify, executing 2 updates in batch :
Implementation before connector 2.1.0 : Query was send one after the other :
• => send query “UPDATE myTable SET someField = ‘newValue’, optimisticField = optimisticField +1 WHERE id = 1 and optimisticField = 100”
• => send query “UPDATE myTable SET someField = ‘newValue2’, optimisticField = optimisticField +1 WHERE id = 2 and optimisticField = 50”
• <= server send back data (one row changed, and other infos)
• <= server send back data (one row changed, and other infos)

Implementation by default since connector 2.1.0 :
• => send query “UPDATE myTable SET someField = ?, optimisticField = optimisticField +1 WHERE id = ? and optimisticField = ?” and parameters : ‘newValue’, 1, 100 / ‘newValue2’, 2, 50
• <= server send back data (2 row changed, and other infos)

Speed in new implementation is largely better, BUT there is one limitation: connector doesn’t know the row changed unitary.
So in the previous example, statement.executeBatch in the previous implementation would be [1, 1]. In the new implementation, the result will be [-2,-2] (-2 stands for Statement.SUCCESS_NO_INFO) meaning that batch succeeded, but without knowing the result of each execution. (if an exception is thrown, no change has been done)

That kind of result follows the JDBC standard.

The problem here must be that optimistic updates probably check that value to ensure that update has been successful.

So the conclusion is, to avoid such kind of optimistic locking exception, camunda should handle such updateCount result (-2 - Statement.SUCCESS_NO_INFO) as well. As of now, it is verifying whether the updateCount result is “1” or not, if 1 it is success otherwise it will throw Optimistic locking exception.

For more info, please refer the below thread
https://forum.camunda.org/t/optimistic-locking-exception-thrown-during-parallel-tasks-execution/7687/7