Uploaded image for project: 'MariaDB Connector/J'
  1. MariaDB Connector/J
  2. CONJ-512

Concurrent modification detected error

Details

    • Bug
    • Status: Closed (View Workflow)
    • Blocker
    • Resolution: Not a Bug
    • 2.1.0
    • N/A
    • JDBC 4.2 compatibility
    • None
    • mac osx 10.12.5

    Description

      Hi, since updating to mariadb 2.1.0 connector, i have experienced this "Concurrent modification detected" error in the gerrit project https://www.gerritcodereview.com

      Downgrading back to 2.0.3 fixes the problem. Seems that a bug may have been introduced into 2.1.0.

      Im using mariadb server 10.2 from homebrew.

      Attachments

        Activity

          paladox paladox created issue -
          paladox paladox made changes -
          Field Original Value New Value
          Priority Major [ 3 ] Blocker [ 1 ]
          paladox paladox made changes -
          Description Hi, since updating to mariadb 2.1.0 connector, i have experienced this "Concurrent modification detected" error in the gerrit project https://www.gerritcodereview.com

          Downgrading back to 2.0.3 fixes the problem. Seems that a bug may have been introduced into 2.1.0.
          Hi, since updating to mariadb 2.1.0 connector, i have experienced this "Concurrent modification detected" error in the gerrit project https://www.gerritcodereview.com

          Downgrading back to 2.0.3 fixes the problem. Seems that a bug may have been introduced into 2.1.0.

          Im using mariadb server 10.2 from homebrew.
          diego dupin Diego Dupin added a comment - - edited

          Can you provide some additional informations :

          • Server and gerrit version
          • connection string
          • if possible, the full stacktrace.
          diego dupin Diego Dupin added a comment - - edited Can you provide some additional informations : Server and gerrit version connection string if possible, the full stacktrace.
          diego dupin Diego Dupin added a comment - - edited

          No need to other informations, i found the issue.
          Gerrit use https://gerrit.googlesource.com/gwtorm internally.
          When executing batch, gerrit verify if update result is has expected : https://gerrit.googlesource.com/gwtorm/+/a89d98dbcc1ac117ef0f6fb4c2a3ec875d325b1b/src/main/java/com/google/gwtorm/jdbc/JdbcAccess.java#456
          update results is set by https://gerrit.googlesource.com/gwtorm/+/a89d98dbcc1ac117ef0f6fb4c2a3ec875d325b1b/src/main/java/com/google/gwtorm/schema/sql/SqlDialect.java#435

          Has JDBC executeBatch required, the int[] result can contain :

          • A number greater than or equal to zero – indicates that the command was processed successfully and is an update count giving the number of rows in the database that were affected by the command's execution
          • A value of SUCCESS_NO_INFO – indicates that the command was processed successfully but that the number of rows affected is unknown
          • A value of EXECUTE_FAILED – indicates that the command failed to execute successfully and occurs only if a driver continues to process commands after a command fails

          in 2.1.0 version, driver will use a new protocol with server bulk protocol for batch insert when possible. (batch without Statement.RETURN_GENERATED_KEYS and streams) to have much faster batch when server MariaDB >= 10.2.7. According to environment, this can be 10 times faster.
          When used, all inserts / updates are handled by bulk, driver then doesn't know individual row change, and return array of SUCCESS_NO_INFO ( =-2).

          Hibernate do that sort of check too : https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/jdbc/Expectations.java#L58 but check -2 (SUCCESS_NO_INFO) and -3 (EXECUTE_FAILED) values.

          This new "bulk" functionality can be disabled setting option "useBulkStmts" to false.
          And issue has to be created on gerrit/gwtorm

          diego dupin Diego Dupin added a comment - - edited No need to other informations, i found the issue. Gerrit use https://gerrit.googlesource.com/gwtorm internally. When executing batch, gerrit verify if update result is has expected : https://gerrit.googlesource.com/gwtorm/+/a89d98dbcc1ac117ef0f6fb4c2a3ec875d325b1b/src/main/java/com/google/gwtorm/jdbc/JdbcAccess.java#456 update results is set by https://gerrit.googlesource.com/gwtorm/+/a89d98dbcc1ac117ef0f6fb4c2a3ec875d325b1b/src/main/java/com/google/gwtorm/schema/sql/SqlDialect.java#435 Has JDBC executeBatch required, the int[] result can contain : A number greater than or equal to zero – indicates that the command was processed successfully and is an update count giving the number of rows in the database that were affected by the command's execution A value of SUCCESS_NO_INFO – indicates that the command was processed successfully but that the number of rows affected is unknown A value of EXECUTE_FAILED – indicates that the command failed to execute successfully and occurs only if a driver continues to process commands after a command fails in 2.1.0 version, driver will use a new protocol with server bulk protocol for batch insert when possible. (batch without Statement.RETURN_GENERATED_KEYS and streams) to have much faster batch when server MariaDB >= 10.2.7. According to environment, this can be 10 times faster. When used, all inserts / updates are handled by bulk, driver then doesn't know individual row change, and return array of SUCCESS_NO_INFO ( =-2). Hibernate do that sort of check too : https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/jdbc/Expectations.java#L58 but check -2 (SUCCESS_NO_INFO) and -3 (EXECUTE_FAILED) values. This new "bulk" functionality can be disabled setting option "useBulkStmts" to false. And issue has to be created on gerrit/gwtorm
          paladox paladox added a comment -

          Could the new bulk be disabled by default instead please?

          paladox paladox added a comment - Could the new bulk be disabled by default instead please?
          diego dupin Diego Dupin added a comment -

          This is an efficient way to handle batch that correspond to standard.
          The best is to correct error in gerrit.

          I've submit a gerrit issue : https://bugs.chromium.org/p/gerrit/issues/detail?id=7105
          During this time, behaviour can be corrected setting option "useBulkStmts" to false.

          diego dupin Diego Dupin added a comment - This is an efficient way to handle batch that correspond to standard. The best is to correct error in gerrit. I've submit a gerrit issue : https://bugs.chromium.org/p/gerrit/issues/detail?id=7105 During this time, behaviour can be corrected setting option "useBulkStmts" to false.
          diego dupin Diego Dupin made changes -
          Component/s JDBC 4.2 compatibility [ 14001 ]
          Fix Version/s N/A [ 22125 ]
          Resolution Not a Bug [ 6 ]
          Status Open [ 1 ] Closed [ 6 ]
          serg Sergei Golubchik made changes -
          Workflow MariaDB v3 [ 82231 ] MariaDB v4 [ 135007 ]

          People

            diego dupin Diego Dupin
            paladox paladox
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.