[
https://issues.apache.org/jira/browse/ZOOKEEPER-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14064261#comment-14064261
]
Hongchao Deng commented on ZOOKEEPER-1967:
------------------------------------------
So my motivation is that when I am working with ZK-1549, I feel the tentative
state is a dangerous assumption. Collaboration with assumption.. Instead of
fixing the assumption in different places, I am trying to think of a way to
eliminate the problem from the root -- a stronger guarantee that no committed
txns can be applied.
The tradeoff is appending twice while the second append could be very small.
> Eliminate the temp dynamic config file, find last proposed config in
> transaction log.
> -------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-1967
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1967
> Project: ZooKeeper
> Issue Type: Improvement
> Components: quorum, server
> Reporter: Alexander Shraer
>
> The .next temporary config file is created when a server acks a reconfig
> proposal.
> During reconfig commit this file becomes the permanent dynamic config file.
> This temp file is read (if exists) during server boot to determine whether
> there is a reconfig potentially in progress.
> This info is also available in the transaction log, since reconfig is a
> transaction. Initially I chose not to take this information from the
> transaction log, mainly for simplicity, since I believed that we need the
> last proposed reconfig info before we're processing the transaction log (for
> example, if we'd like to contact new config servers during FLE - this is
> discussed in ZOOKEEPER-1807).
> It would be useful to revisit this issue and check whether we could eliminate
> the temporary dynamic config file, finding the last proposed reconfig in the
> the transaction log.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
