Hi Ted,
Thanks a lot for your email.
I don't stick to a general atomic if-else capability. It comes
from a function in etcd community[1] and I'm curious whether ZooKeepr
has cover this capability.
Follow this thread I got the idea that a multi operation is like
a transaction, succeed or fail
So, getting back to the original problem, I think that you need to specify
it more tightly in order to solve it. Otherwise, when you find problems in
a solution you won't know whether those are problems with the solution or
the original problem statement.
As I see it, there are several possible
Thanks for your explanation Michael and Ted :-)
Best,
tison.
Ted Dunning 于2019年8月15日周四 下午1:22写道：
> 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
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
>> 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
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
OuO
Let me take a closer look...
Best,
tison.
Ted Dunning 于2019年8月15日周四 上午9:37写道：
> The multi operation *is* like a transaction. All the operations will
> succeed or none.
>
>
>
> On Wed, Aug 14, 2019 at 9:33 AM Andor Molnar wrote:
>
> > "it's said that ZooKeeper has a transaction
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.
The multi operation *is* like a transaction. All the operations will
succeed or none.
On Wed, Aug 14, 2019 at 9:33 AM Andor Molnar wrote:
> "it's said that ZooKeeper has a transaction mechanism”
>
> I’m still confused with this. ZooKeeper doesn’t support transactions to my
> best knowledge.
Hi Jordan,
Thanks for your reply. The problem is that we cannot confirm
an action is committed atomically with checking the leadership.
The thread shows that we are unable to access the latch znode.
There is another thread[1] in Curator list and we could continue
the discussion there.
Best,
FYI - that "wart" had a workaround. You can't use the same workaround?
-Jordan
> On Aug 14, 2019, at 5:19 PM, Zili Chen wrote:
>
> Actually I want something like LeaderLatch of Curator but the
> implementation in Curator has some wart[1]
> Actually I want something like LeaderLatch of Curator but the
> implementation in Curator has some wart[1] so that I need to
> reimplement it by myself.
Or we can enhance Curator :D Why not add a new recipe for what you want in
Curator. I (or one of the other committers) will help ypu.
@Enrico
The problem is that an operation should be rejected not only if
the version mismatched, but also if the mark node did not exist
even if the version matched.
@Andor
Thanks for your clarification. Let's then refer it as multi op.
Actually I want something like LeaderLatch of Curator but
>> Is there any way to do an "if-else" transaction?
No for your use case. The only remotely related conditional operation you
can express with multi-op is by using check operator (Op.check), where you
can check a zNode's version and only execute subsequent operation in multi
op when version
"it's said that ZooKeeper has a transaction mechanism”
I’m still confused with this. ZooKeeper doesn’t support transactions to my best
knowledge. It has a `multi` operation feature, but that’s more like a bulk
operation, not transaction.
"I want to tell ZooKeeper that the check and setData
Il mer 14 ago 2019, 17:55 Zili Chen ha scritto:
> FYI, etcd provides a transaction mechanism which supports if-else like
> commits.[1]
>
As we have setData with version check usually you don't need a
'transaction' with some kind of rowlevel lock.
Maybe I am missing something in your case.
FYI, etcd provides a transaction mechanism which supports if-else like
commits.[1]
Best,
tison.
[1] https://godoc.org/github.com/coreos/etcd/clientv3#OpTxn
Zili Chen 于2019年8月14日周三 下午11:52写道：
> Hi Andor,
>
> Thanks for your attention.
>
> The problem is that in concurrent scenario
Hi Andor,
Thanks for your attention.
The problem is that in concurrent scenario zk.setData() could still failed
if there is another thread delete the node. I know with proper lock strategy
and ownership separation this can be avoid but it's said that ZooKeeper has
a transaction mechanism so I'd
Hi Zili,
There’s no such functionality in ZooKeeper as far as I’m concerned. I think
your multi example (zk.multi(Op.check(path), Op.setData(path, data))) is
already a usage pattern which multi is not designed to support.
Why do you need to do this in “transactions” (there’s no transaction in
Hi Enrico,
Thanks for your reply.
>In this case usually you use conditional setData, using the 'version' of
>thr znode
what if the caller has no idea on whether the node exist?(see also
my if-else pseudo-code above.)
IIRC if we call `setData` on a non-exist path a NoNodeException
will be
Il mar 6 ago 2019, 13:47 Zili Chen ha scritto:
> Any ideas?
>
>
> Zili Chen 于2019年7月29日周一 上午11:12写道：
>
> > Hi ZooKeepers,
> >
> > Currently our transaction mechanism supports doing
> > create/setData/checkExist/delete in transaction. However, taking this
> > scenario into consideration, we want
Any ideas?
Zili Chen 于2019年7月29日周一 上午11:12写道：
> Hi ZooKeepers,
>
> Currently our transaction mechanism supports doing
> create/setData/checkExist/delete in transaction. However, taking this
> scenario into consideration, we want to put data in path "/path" but
> don't know whether the znode
22 matches
Mail list logo
