Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-9169

Successful return code "-2" has to be handled to avoid optimistic locking exception

    XMLWordPrintable

    Details

    • Type: Bug Report
    • Status: Closed
    • Priority: L2 - Critical
    • Resolution: Duplicate
    • Affects Version/s: 7.8.0-alpha6
    • Fix Version/s: None
    • Component/s: engine
    • Labels:
      None

      Description

      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

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              senthil Senthil kumar
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: