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

Improve Process Application Deployment Experience

    Details

    • Type: Task
    • Status: Closed
    • Priority: L3 - Default
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 7.4.0, 7.3.3, 7.2.7, 7.4.0-alpha2
    • Component/s: engine
    • Labels:
      None

      Description

      • Check all DB Queries (SELECTs) that are executed during deployment. Do they all have indexes?
      • increase query timeout for lockDeploymentLockProperty / make configurable
      • reproduce lock timeout with mysql

      Problem: the alleged oracle deadlock could neither be reproduced nor explained up to now.

        Issue Links

          Activity

          Hide
          roman.smirnov Smirnov Roman added a comment -

          Re. > increase query timeout for selectDeploymentLock / make configurable
          MyBatis offers to set a timeout on a statement, but this cannot be done in a "dynamic" way. It must be an integer value and cannot be an expression which will be resolved before the statement will be executed during the runtime. Due to this I didn't increase the query timeout for the lockDeploymentLockProperty statement (and in conclusion it is also not configurable).

          Show
          roman.smirnov Smirnov Roman added a comment - Re. > increase query timeout for selectDeploymentLock / make configurable MyBatis offers to set a timeout on a statement, but this cannot be done in a "dynamic" way. It must be an integer value and cannot be an expression which will be resolved before the statement will be executed during the runtime. Due to this I didn't increase the query timeout for the lockDeploymentLockProperty statement (and in conclusion it is also not configurable).
          Hide
          sebastian.menski Sebastian Menski added a comment -

          The patch has to be added to the db-upgrade and instance-migration pom.xml on the 7.2 branch in the patch-new-schema execution part.

          Thats why https://app.camunda.com/jenkins/job/7.2-platform-UPGRADE-71-to-72-databases/ is currently broken.

          It also breaks the 72-to-73 upgrade but there we have to find another solution as on the 7.3. branch already a patch exists for the upcoming 7.3.3 version.

          Show
          sebastian.menski Sebastian Menski added a comment - The patch has to be added to the db-upgrade and instance-migration pom.xml on the 7.2 branch in the patch-new-schema execution part. Thats why https://app.camunda.com/jenkins/job/7.2-platform-UPGRADE-71-to-72-databases/ is currently broken. It also breaks the 72-to-73 upgrade but there we have to find another solution as on the 7.3. branch already a patch exists for the upcoming 7.3.3 version.
          Hide
          sebastian.menski Sebastian Menski added a comment -

          docs missing for patch upgrade guide. please add note that the patches on multiple branches are the same (which is currently not completly true as long as there a multiple patches in one file).

          Show
          sebastian.menski Sebastian Menski added a comment - docs missing for patch upgrade guide. please add note that the patches on multiple branches are the same (which is currently not completly true as long as there a multiple patches in one file).
          Hide
          sebastian.menski Sebastian Menski added a comment -

          Solution:

          • we split up the patches for *_engine_7.3_patch_7.3.2_to_7.3.3.sql patches into 2 separate patches *_engine_7.3_patch_7.3.2_to_7.3.3_1.sql and *_engine_7.3_patch_7.3.2_to_7.3.3_2.sql
          • we can then use them separately in the db/instance upgrade tests, which means *7.3.3_1 will be part of the 7.3 pom.xml but not 7.3.3_2 as it already exists on the 7.2 branch
          • the patches are separately documented in the http://docs.camunda.org/7.3/guides/migration-guide/#patch-level-upgrade-upgrade-your-database section with a note that *7.3.3_2 is the same as patch *_engine_7.2_patch_7.2.6_to_7.2.7.sql
          Show
          sebastian.menski Sebastian Menski added a comment - Solution: we split up the patches for *_engine_7.3_patch_7.3.2_to_7.3.3.sql patches into 2 separate patches *_engine_7.3_patch_7.3.2_to_7.3.3_1.sql and *_engine_7.3_patch_7.3.2_to_7.3.3_2.sql we can then use them separately in the db/instance upgrade tests, which means *7.3.3_1 will be part of the 7.3 pom.xml but not 7.3.3_2 as it already exists on the 7.2 branch the patches are separately documented in the http://docs.camunda.org/7.3/guides/migration-guide/#patch-level-upgrade-upgrade-your-database section with a note that *7.3.3_2 is the same as patch *_engine_7.2_patch_7.2.6_to_7.2.7.sql

            People

            • Assignee:
              thorben.lindhauer Thorben Lindhauer
              Reporter:
              roman.smirnov Smirnov Roman
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development