[
https://issues.apache.org/jira/browse/KAFKA-9224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087270#comment-17087270
]
Guozhang Wang commented on KAFKA-9224:
--------------------------------------
Hi [~mjsax], I think we are talking about the same thing: in restoration, let's
say the previous committed offset is 40, we could opt to NOT make IQ available
until we've completed restoration until the state is back to RUNNING -- at this
moment we are guaranteed to be at least at offset 40 already. KIP-535 allows IQ
on RESTORING tasks (active or standby) and hence exposed the issue.
I think this JIRA is orthogonal to KIP-535, and we can put it this way: KIP-535
exposed new root causes to break monotonicity, but even before KIP-535 we still
have other root causes that can break monotonicity. This JIRA is for the "other
root causes" other than KIP-535 itself, AND here one can argue that under ALOS
the other root cause is allowed while under EOS it should not be allowed.
> State store should not see uncommitted transaction result
> ---------------------------------------------------------
>
> Key: KAFKA-9224
> URL: https://issues.apache.org/jira/browse/KAFKA-9224
> Project: Kafka
> Issue Type: Improvement
> Reporter: Boyang Chen
> Assignee: Boyang Chen
> Priority: Major
>
> Currently under EOS, the uncommitted write could be reflected in the state
> store before the ongoing transaction is finished. This means interactive
> query could see uncommitted data within state store which is not ideal for
> users relying on state stores for strong consistency. Ideally, we should have
> an option to include state store commit as part of ongoing transaction,
> however an immediate step towards a better reasoned system is to `write after
> transaction commit`, which means we always buffer data within stream cache
> for EOS until the ongoing transaction is committed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
