chia7712 commented on code in PR #23144:
URL: https://github.com/apache/kafka/pull/23144#discussion_r3789647611
##########
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:
`DualColumnFamilyAccessor#put` calls `StoreQueryUtils.updatePosition` for
each put, so is it legal to update the position before the whole batch is
completed?
--
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]
