Community
Participate
Working Groups
Build Identifier: 1.1.2.v20090612-r4475 It seems that if JDBC batch writing is enabled invoking flush() won't trigger the execution of "batched" native queries. Although I only tested this against 1.1.2 it seems that the bug does still exist in 2.1 when looking at the responsible source code lines. Reproducible: Always Steps to Reproduce: Steps to reproduce this: 0. enable batch writing in mode "JDBC" 1. create an EntityManager 2. create and execute a native query which consists of a simple insert 3. call flush() on the entity manager. => Nothing will be written to the database. It seems that the changes will only be persisted when commiting the transaction.
Response on mailing list from James Sutherland: It seems the batch is not being flushed because there were no changes, the native query was thought to have already been executed. Please log a bug for this, the batch should always get flushed on flush, even with no changes. It is also odd that the native query is batched at all. This seems to be our default when batching, but can be set on the ModifyQuery using setForceBatchStatementExecution(true). There does not seem to be a query hint for this though, so please add this to the bug.
See bug 266151. I need a way to get the correct number of rows processed from Query.executeUpdate(). I would either like a way to turn off batch writing for the session or for the statement, so that I can get the actual number of rows processed. If flush() is changed to execute the batched statement, it would give me a way to execute the batch immediately, however, I still wouldn't be able to get the count of rows processed.
Created attachment 180808 [details] proposed fix uploaded patch corrects the flush to also flush the BatchWritingMechanism. bug 266151 (allowing executeUpdate to return an accurate row count when batch writing is used) will require new api to allow update statements to be included or excluded from batches, and likely make this fix unneccessary. Please vote for it to have its priority adjusted.
Created attachment 181128 [details] proposed fix and test caes
Fix checked into 2.2 revision 8372 -RepeatableWriteUnitOfWork now calls writesCompleted() on flush even when no changes in the changeset have been detected.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
