Community
Participate
Working Groups
UPDATE batching on MySQL appears to be broken: 1) In the MySQLPlatform, the method canBatchWriteWithOptimisticLocking() does not override the method DatabasePlatform.canBatchWriteWithOptimisticLocking(DatabaseCall call). 2) The executeBatch does not seem to be able to properly determine the number of rows changed: public int executeBatch(Statement statement, boolean isStatementPrepared) throws java.sql.SQLException { int[] updateResult = statement.executeBatch(); int updateCount = 0; for (int count : updateResult){ if (count == Statement.SUCCESS_NO_INFO){ count = 1; } updateCount+=count; } return updateCount; } I assume that rows, for which the optimistic verification fails, will also yield SUCCESS_NO_INFO.
An investigation showed that while issue 1) is valid, issue 2) seems not to occur as the updateResult[] does not contain SUCCESS_NO_INFO but non-negative values.
Created attachment 174990 [details] proposed patch and regression test As a regresssion test, the patch enables JDBC-batching in the eclipselink.jpa.wdf.test testsuite. The test TestDeleteQuery had to be modified: if JDBC batching is enabled EclipseLink also batches statements generated by a JPQL delete query. Due to the batching, it is not possible any longer to determine the exact update count. Hence, checking the update count is disabled in the test. Also, the executeUpdate method of the MySQL Platform needs to be modified for Statement batches: here, the update count is just the number of statements in the batch.
Created attachment 175060 [details] proposed patch Moved the regression tests to bug 320643.
Checked in in trunk at #8217 Reviewed by Gordon Tests on MySQL (core, jpa, jpa.wdf): OK
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
