rzo1 commented on code in PR #216:
URL: https://github.com/apache/openjpa/pull/216#discussion_r4308047840
##########
openjpa-kernel/src/main/java/org/apache/openjpa/kernel/QueryImpl.java:
##########
@@ -1163,6 +1163,34 @@ public Number updateInMemory(StoreQuery q,
StoreQuery.Executor executor,
}
}
+ /**
+ * Flush the persistence context after a bulk operation that had to be
+ * executed in memory, so that the row count the operation returns has
+ * reached the database. The whole context is flushed, because the kernel
+ * does not flush single instances; an application that relies on the
+ * former timing can turn the flush off with the compatibility option
+ * <code>FlushAfterInMemoryBulkOperation</code>.
+ *<p>
+ * The flush is also skipped when the context cannot be flushed at all -
+ * see {@link Broker#isFlushSupported} - rather than letting
+ * {@link Broker#flush} reject the operation. The bulk operation is legal
+ * and the specification does not ask for a flush, so a store manager
+ * without incremental flushing or a savepoint that cannot be flushed
+ * incrementally leaves the operation pending in the context instead of
+ * failing it, which is the behaviour of the option turned off.
+ */
+ private void flushAfterInMemoryBulkOperation() {
+ if (!_broker.getConfiguration().getCompatibilityInstance()
Review Comment:
Done.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
