As Michael correctly said, isolation only makes sense when you allow concurrent queries. Of the four ACID properties, the multi op satisfies A, C and D while I is essentially irrelevant (or could be said to be trivially satisfied since there are no concurrent queries.
On Wed, Aug 14, 2019 at 6:45 PM Zili Chen <wander4...@gmail.com> 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 <ted.dunn...@gmail.com> 于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 <h...@apache.org> 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. > > > > > > > > > > > > >
