[CONJ-1038] Regression - Prepared Statement executeBatch returns SUCCESS_NO_INFO Created: 2023-01-09  Updated: 2023-01-10  Resolved: 2023-01-10

Status: Closed
Project: MariaDB Connector/J
Component/s: 2.7 compatibility
Affects Version/s: 3.0.0, 3.0.3, 3.0.5, 3.1.0
Fix Version/s: 3.2.0

Type: Bug Priority: Major
Reporter: Arthur Borsboom Assignee: Diego Dupin
Resolution: Duplicate Votes: 0
Labels: regression
Environment:

Arch Linux, OpenJDK 18

Attachments: Java Source File TestExecuteBatch.java    
Issue Links:
Duplicate
duplicates CONJ-920 MariaDB Java Client 3.0.3 - Java batc... Closed

 Description   

After upgrading the MariaDB Java connector in a web application from v2.7.5 to v3.1.0 one of the JUnit tests started failing. When the method 'executeBatch()' is called on a PreparedStatement, then it returns "SUCCESS_NO_INFO".

I have created a reproducible Java application, see attachment.

If this application is run with v2.7.7, then it returns an array of update counts.
If this application is run with v3.0.0 or newer (for example v3.1.0), then it returns "SUCCESS_NO_INFO".

To me this looks like a regression where v3.1.0 breaks backwards compatibility.
Please correct me if I am wrong.

 Comments   
Comment by Diego Dupin [ 2023-01-10 ]

JDBC permit that, but yes this is a change of behavior that is discussed on https://jira.mariadb.org/browse/CONJ-920.

These behavior can be disable setting option 'useBulkStmts' to false.

Current behavior permit way better performance, but at this cost.
This will be correct by 2 things :

  • when server will implement MDEV-30366
  • until then in 3.2:
    • option useBulkStmts will be disable
    • a new option useBulkStmtsForInserts will be created enable by default to permit bulk insert
Comment by Arthur Borsboom [ 2023-01-10 ]

Hi Diego,

I agree that the behavior is according to the JDBC specification. I understand that this is a choice between functionality (the row counts) and performance (faster inserts / updates).

Nevertheless, the behavior has changed in a way that it breaks the application I am maintaining. So from that perspective, I still believe this is a regression, since it breaks backwards compatibility.

I confirm that adding "?useBulkStmts=false" to the jdbcUrl restores the functionality for v3.1.0

Once v3.2.0 is released I will retest and might come back to see how the application can keep its functionality (at the cost of performance).

Thanks for the quick response.

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