[CONJ-676] Behavior of MariaDB 10.3.11 batch update processing changed from non-atomic insert to atomic insert Created: 2019-01-22  Updated: 2019-03-13  Resolved: 2019-03-13

Status: Closed
Project: MariaDB Connector/J
Component/s: batch
Affects Version/s: 2.2.3
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Yekaterina Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: Compatibility
Environment:

Linux 3.10.0-862.el7.x86_64
MariaDB server 10.3.11
Connector/J 2.2.3

Attachments: File repro2.class     Java Source File repro2.java     File repro2.log.mariadb10.1.16     File repro2.log.mariadb10.3.11     HTML File setup    

 Description   

When we switched from MariaDB 10.1.16 server to Mariadb 10.3.11, the behavior of MariaDB batch update processing changed from non-atomic insert to atomic insert. This is an upward compatibility issue for us.
In the repro2 I attached, we attempt to insert a block of 3 rows, one of which has a duplicate primary key value.
With MaraiaDB server 10.1.16, the non-duplicate rows of a block insert would be inserted up to the first error. With MariaDB server 10.3.11, no rows are inserted and we don't know which row of the block caused the error, so we cannot attempt to insert all non-error rows. This looks like a bug. Is there a setting to restore the original behavior?



 Comments   
Comment by Diego Dupin [ 2019-01-23 ]

Since 10.2, the server has a new command to permit bulk insert (MDEV-9114). Principe of bulk is that inserts are done by bunch.
That is more performant, but with some drawback, like the one you describe there.

The Java connector can use that functionality if the server has this capability, and according to connector option `useBulkStmts`.
By default, this option was enabled for driver < 2.3.0.
Changing driver to the last version will solve that (or add "&useBulkStmts=false" to the connection string)

Comment by Yekaterina [ 2019-01-24 ]

Hi,
Thank you. We installed the newest driver and it resolved our issue.
You can close this case.

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