bbejeck commented on code in PR #23144:
URL: https://github.com/apache/kafka/pull/23144#discussion_r3799271749
##########
streams/src/main/java/org/apache/kafka/streams/state/internals/RocksDBStore.java:
##########
@@ -1251,6 +1276,23 @@ public void deleteRange(final ColumnFamilyHandle
columnFamily, final byte[] from
buffer.stageDeleteRange(columnFamily, Bytes.wrap(from),
Bytes.wrap(to));
}
+ @Override
+ public void putAll(final ColumnFamilyAccessor cfAccessor,
+ final List<KeyValue<Bytes, byte[]>> entries) {
+ // Batch writes must be staged like single-key puts. If written
directly to RocksDB
+ // (what the direct accessor does), the uncommitted data would sit
in the store rather
+ // than the buffer so would not get removed on error. Staging
under one write-lock
+ // acquisition also hides the batch from a concurrent IQ reader
until complete,
+ // matching the atomicity of the direct accessor's single
db.write(batch). Reusing
+ // cfAccessor.put() keeps the column-family layout — including the
dual-CF upgrade
+ // path — identical to a single-key put.
+ buffer.stageAll(() -> {
+ for (final KeyValue<Bytes, byte[]> entry : entries) {
+ cfAccessor.put(this, entry.key.get(), entry.value);
Review Comment:
@chia7712 - good eye - `updatePosition` stamps the current input record's
(topic, partition, offset) into the position (StoreQueryUtils.java:158-162) —
it doesn't depend on anything per-entry.
Every entry in one putAll is processed under the same record context, so
calling it per-entry is idempotent: the position ends up exactly where a single
update would leave it.
But I'm going to look at our existing tests and see if this is covered if
not, i'll update them
--
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]
