[
https://issues.apache.org/jira/browse/ZOOKEEPER-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356740#comment-14356740
]
Flavio Junqueira commented on ZOOKEEPER-2136:
---------------------------------------------
Hi [~shralex], the short answer to your question is that I do think that we
should make it a regular quorum txn, it will simplify the code and our
reasoning.
About the issue you're raising from the e-mail thread, you're pointing out that
a server may receive acks for a txn but delay the processing of the acks
arbitrarily. That's correct, but the conclusion might be a bit off. Say we call
setData asynchronously followed by a sync call (let's put the read op aside for
now). Say the setData txn is delayed in the way you describe, the processing of
the acks is delayed arbitrarily. By the total ordering of txns, all txns
ordered before setData must be known to the server, otherwise it won't process
the setData. The ones that aren't known to the server are the ones that have
been ordered after the setData, but these ones are concurrent with the sync
call and the server misses those txns. But, this is fine because the sync
promise is that it will see everything that has been committed before the sync
started.
A hidden assumption there is that I'm considering that the sync+setData calls
form a joint operation, so for the purposes of this analysis, the operation of
syncing really starts when the setData is invoked. If you don't model it this
way, then not even quorum sync + read will give you linearizable reads for the
same reason you exposed above, there could be missing updates between the start
of the sync and the start of the read. To get around this, you'd need to make
reads go through quorum as well.
I was also revolving my recollection of our discussions early on around sync,
and I'm kind of thinking that it is pointless to make sync a quorum operation.
We did this cheaper version because you could easily replace a quorum sync call
with a create or a setData. Instead of calling sync + read, call setData + read
for some arbitrary znode. The advantage of the sync call is semantics, it's
cleaner while the second option is somewhat hacky.
> Sync() should get quorum acks.
> ------------------------------
>
> Key: ZOOKEEPER-2136
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2136
> Project: ZooKeeper
> Issue Type: Sub-task
> Reporter: Hongchao Deng
> Assignee: Hongchao Deng
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2000.patch
>
>
> Currently if the sync packet goes to leader it doesn't get quorum acks. This
> is a problem during reconfig and leader changes. testPortChange() flaky
> failure is caused by such case.
> I proposed to change sync() semantics to require quorum acks in any case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
