Hi Mikael, Very good question. You are correct about the desired semantics.
The semantic of case (a) depends on the local store as you mention. For case (b), the final check is always performed again on get(), and if the store has disappeared between the lookup and get, the user will get an exception and will have to retry. The state store in A does become invalid when the state is re-assigned. There isn't any other way to detect the change, since we wanted to hide the system details (e.g., rebalance) from the user. Does this make sense? Thanks Eno > On 26 Aug 2016, at 16:26, Mikael Högqvist <hoegqv...@gmail.com> wrote: > > Hi, > > I've tried to understand the implementation and APIs from KIP-67 and would > like to know the possible semantics for read requests from a client > perspective. As a developer of a queryable state client, the access > semantics I would like to have (I think...) is one where subsequent reads > always return the value from the last read or a newer value (if the state > store is available). This should be independent of the current system > configuration, e.g. re-balancing, failures etc. . > > A client-side get(k) can be implemented by starting with a lookup for the > instances that store k followed by a retrieve of the value associated with > k from the instances returned by the lookup. In the worst case we can > always do scatter+gather over all instances. > > We can start by considering a get(k) under two failure-free cases: a) > single instance and b) a system going from one instance to two instances. In > case a) the lookup will always return the same instance and the following > get will read from a local store. The semantics in this case depends on the > local store. > > For case b) the lookup returns instance A, but in between the lookup and > the get, a new instance B is introduced to which k is transferred? Does the > state store on A become invalid when the state is re-assigned? Is there > another way for the client to detect the change? > > Best Regards, > Mikael
