From user-return-12071-archive-asf-public=cust-asf.ponee.io@zookeeper.apache.org Thu Aug 15 04:28:05 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 9A4E21802C7 for ; Thu, 15 Aug 2019 06:28:05 +0200 (CEST) Received: (qmail 83595 invoked by uid 500); 15 Aug 2019 04:28:03 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 83581 invoked by uid 99); 15 Aug 2019 04:28:03 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2019 04:28:03 +0000 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 059F08535 for ; Thu, 15 Aug 2019 04:28:03 +0000 (UTC) Received: by mail-ed1-f43.google.com with SMTP id w5so1079431edl.8 for ; Wed, 14 Aug 2019 21:28:02 -0700 (PDT) X-Gm-Message-State: APjAAAUY2n4gK1COa3W99M9LEYg9P0V/itTCgaB91IQLc0MzaEQYc/XA /MdLNczjnvuOTuMA1BqcgHzJkoBEAdPNKh5+hMM= X-Google-Smtp-Source: APXvYqxAzO/fay5pDKP/hTVQ3Fgu+lK5XxcNHLBSFck0IMxiV4u59/jQeSMx7TVzv7gwsUsrE7wrOb1mAnCYsGZEesM= X-Received: by 2002:a17:906:229b:: with SMTP id p27mr2673652eja.266.1565843282200; Wed, 14 Aug 2019 21:28:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Han Date: Wed, 14 Aug 2019 21:27:50 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: create or setData in transaction? To: user@zookeeper.apache.org Content-Type: multipart/alternative; boundary="0000000000009c104c0590204c34" --0000000000009c104c0590204c34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >> 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 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 "har= d" > comes from? > > Best, > tison. > > > Ted Dunning =E4=BA=8E2019=E5=B9=B48=E6=9C=8815=E6= =97=A5=E5=91=A8=E5=9B=9B =E4=B8=8A=E5=8D=889:40=E5=86=99=E9=81=93=EF=BC=9A > > > The multi op is atomic (all other operations will be before or after te= h > > 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 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 seem= s > 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. > > > > > > > > > > > > > --0000000000009c104c0590204c34--