>> Well, if you do the log tailing thing I suggested, then the client
>> will have access to a consistent snapshot, since they would only read
>> from the database directly once, and all client updates after that
>> would come from the log which arrive in a well defined order.
>
> OK.
>
> I'm
On Fri, Mar 11, 2016 at 5:20 PM, Ben Pfaff <b...@ovn.org> wrote:
> On Fri, Mar 11, 2016 at 05:10:15PM +0100, Ivan Kelly wrote:
>> > Just to make sure, does this means that a Zookeeper client cannot read a
>> > consistent snapshot of the entire database?
>> Yes, e
> Just to make sure, does this means that a Zookeeper client cannot read a
> consistent snapshot of the entire database?
Yes, exactly. It can only read one node at a time, so writes can occur
between the reading of two nodes.
-Ivan
___
dev mailing list
> Zookeeper transactions can be isolated depending on what level of
> isolation you need.
> A setData on a node operation can contain a version, so that it fails
> if that node has changed since the version. This means with a multi[1]
> of setData operations, you can effectively get a snapshot
> - Zookeeper. The ZK model is similar to etc so it may have
> similar issues. Also, ZK makes the transaction log available,
> for use by observer nodes to scale out reads, and this may be
> another way for the clients to track table changes.
Not quite. It does make the log
> - Zookeeper. The issues here are similar to those for etcd.
> Also, Zookeeper transactions don't seem to be isolated.
Zookeeper transactions can be isolated depending on what level of
isolation you need.
A setData on a node operation can contain a version, so that it fails
if that
