Myasuka commented on a change in pull request #17945:
URL: https://github.com/apache/flink/pull/17945#discussion_r761683066
##########
File path:
flink-runtime/src/main/java/org/apache/flink/runtime/state/KeyedStateBackend.java
##########
@@ -137,10 +137,25 @@
*/
boolean deregisterKeySelectionListener(KeySelectionListener<K> listener);
+ @Deprecated
default boolean isStateImmutableInStateBackend(CheckpointType
checkpointOptions) {
return false;
}
+ /**
+ * Whether it's safe to reuse key-value from the state-backend, e.g for
the purpose of
+ * optimization.
+ *
+ * <p>NOTE: this method should not be used to check for {@link
InternalPriorityQueue}, as the
+ * priority queue could be stored on different locations, e.g RocksDB
state-backend could store
+ * that on JVM heap if configuring HEAP as the time-service factory.
+ *
+ * @return returns ture if safe to reuse the key-value from the
state-backend.
+ */
+ default boolean isSafeToReuseState() {
Review comment:
I think these two methods serveing for different purposes. The method of
`isSafeToReuseState` is used to hint for SQL like operators to decide whether
they need to copy the state data from the state-backend. This actually focus on
the normal state access and has no relationship with checkpoint or timers.
On the other hand, `requiresLegacySynchronousTimerSnapshots` is only used to
represent that whether we should use raw checkpoint stream to backup the
timers. As you can see, this method serves for checkpoint and timers. If we
could drop the support HEAP timers in RocksDB, we could remove
`requiresLegacySynchronousTimerSnapshots` but not the `isSafeToReuseState`
method.
Maybe we could rename the method `KeyedStateBackend.isSafeToReuseState` to
`KeyedStateBackend.isSafeToReuseKVState`, however, I don't think
`KeyedStateBackend.isSafeToReusePQState` could meet the purpose of current
`AbstractKeyedStateBackend.requiresLegacySynchronousTimerSnapshots
`.
--
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: issues-unsubscr...@flink.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
