[CONJ-512] Concurrent modification detected error Created: 2017-08-23  Updated: 2017-08-28  Resolved: 2017-08-28

Status: Closed
Project: MariaDB Connector/J
Component/s: JDBC 4.2 compatibility
Affects Version/s: 2.1.0
Fix Version/s: N/A

Type: Bug Priority: Blocker
Reporter: paladox Assignee: Diego Dupin
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

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.



 Comments   
Comment by Diego Dupin [ 2017-08-23 ]

Can you provide some additional informations :

  • Server and gerrit version
  • connection string
  • if possible, the full stacktrace.
Comment by Diego Dupin [ 2017-08-23 ]

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

Comment by paladox [ 2017-08-23 ]

Could the new bulk be disabled by default instead please?

Comment by Diego Dupin [ 2017-08-28 ]

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.

Generated at Thu Feb 08 03:16:13 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.