>> where is the "hard" comes from? Isolation levels is only meaningful when concurrent transactions are allowed. For zookeeper, there is no concurrent transactions, as every transaction (and write operations in general) is serialized.
On Wed, Aug 14, 2019 at 6:45 PM Zili Chen <[email protected]> wrote: > Thanks for your reply Ted. > > I cannot understand the statement "That leaves isolated which is kind of > hard to talk about with ZK since all operations are fast and sequential." > well. Could you explain a bit? What is "that" means and where is the "hard" > comes from? > > Best, > tison. > > > Ted Dunning <[email protected]> 于2019年8月15日周四 上午9:40写道： > > > The multi op is atomic (all other operations will be before or after teh > > multi), consistent (all viewers will see all the effects or none, and > > durable (because ZK is linearized anyway). > > > > That leaves isolated which is kind of hard to talk about with ZK since > all > > operations are fast and sequential. > > > > On Wed, Aug 14, 2019 at 3:12 PM Michael Han <[email protected]> wrote: > > > > > ... > > > Ted can correct me if I am wrong, since he added the multi op feature, > > but > > > my understanding is "multi op" is branded from day one as the > transaction > > > support for zookeeper (we even provide an API with exact name: > > > Transaction). If we use the traditional semantic for transaction in > > > database context, the ACID properties multi-op satisfies at least > > atomicity > > > and durability. So saying zookeeper does not support transaction seems > a > > > strong argument that against the properties of multi-op and existing > > > literatures related to zookeeper. On the other side, typically bulk > > > operations does not support atomicity, which will not take care of > > rolling > > > back failed operations. > > > > > > > > > > > > >
