OneSizeFitsQuorum commented on PR #1296: URL: https://github.com/apache/ratis/pull/1296#issuecomment-3379951174
> from the client’s perspective, if at T1 I send a balance inquiry to the bank, at T2 my account is debited by 100 yuan, and at T3 I receive a response showing that I still have 100 yuan, then the result is clearly incorrect from the client’s point of view. Such situations are typical in the presence of concurrent requests. Above thesis reveals that linearizability provides visibility guarantees only for operations that can be organized into a partial order. The model requires all operations to be arranged in a single linear extension of that order. In particular, when a request at time t2 is initiated only after the response of a request at time t1 has been received, the execution order is well defined, and t2 must occur after t1. Conversely, if both requests t1 and t2 are issued before any response is obtained, their execution order on the server side remains indeterminate. Either t1 or t2 may be executed first, and such nondeterminism does not violate the property of linearizability. Moreover, the example under discussion is independent of the Raft protocol. The same behavior may arise even in a single-machine system. If one interprets this case as a violation of linearizability, it would imply that a single-machine system could not satisfy linearizability either, which is clearly untenable. Certainly, providing an interface for stale reads is feasible. However, it is important to explicitly note that such an interface does not guarantee linearizability even others can. -- 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]
