Is there documentation on the multi/transaction feature added in 3.4 other
than the Javadoc?

-JZ

Not really.

On Wed, Jan 4, 2012 at 12:47 AM, Jordan Zimmerman <[EMAIL PROTECTED]>wrote:

> Is there documentation on the multi/transaction feature added in 3.4 other
> than the Javadoc?
>
> -JZ
>
>

Also there's a pending patch to improve the multi javadoc:
https://issues.apache.org/jira/browse/ZOOKEEPER-1336

Contributing docs is a great way to get started as a zk contributor
(hint hint ;-) )

Patrick

On Wed, Jan 4, 2012 at 7:30 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> Not really.
>
> On Wed, Jan 4, 2012 at 12:47 AM, Jordan Zimmerman <[EMAIL PROTECTED]>wrote:
>
>> Is there documentation on the multi/transaction feature added in 3.4 other
>> than the Javadoc?
>>
>> -JZ
>>
>>

>Contributing docs is a great way to get started as a zk contributor
>(hint hint ;-) )

Aha! I already have. I updated the recipes doc to include GUIDs in locks.

On 1/4/12 9:23 AM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:

>Also there's a pending patch to improve the multi javadoc:
>https://issues.apache.org/jira/browse/ZOOKEEPER-1336
>
>Contributing docs is a great way to get started as a zk contributor
>(hint hint ;-) )
>
>Patrick
>
>On Wed, Jan 4, 2012 at 7:30 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>> Not really.
>>
>> On Wed, Jan 4, 2012 at 12:47 AM, Jordan Zimmerman
>><[EMAIL PROTECTED]>wrote:
>>
>>> Is there documentation on the multi/transaction feature added in 3.4
>>>other
>>> than the Javadoc?
>>>
>>> -JZ
>>>
>>>
>

On Wed, Jan 4, 2012 at 9:25 AM, Jordan Zimmerman <[EMAIL PROTECTED]> wrote:
>>Contributing docs is a great way to get started as a zk contributor
>>(hint hint ;-) )
>
> Aha! I already have. I updated the recipes doc to include GUIDs in locks.

Ok, you got me on that one. ;-) Thanks!

Patrick

OK - a few questions:

* Can someone give more detail on Op.check()? I assume it generates an
error if the version of the path doesn't match, but the doc is confusing
to me. What happens if the transaction has both a setData and a check?

* Does ZooKeeper.multi() guarantee that there will be exactly 1 OpResult
for every Op in the transaction. Further, is there an ordering guarantee
for the OpResult list - i.e. the OpResults are in the same order as the
Ops argument? If this isn't so, I don't see how someone could correlate an
Op to its result.

-JZ

On 1/4/12 7:30 AM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:

>Not really.
>
>On Wed, Jan 4, 2012 at 12:47 AM, Jordan Zimmerman
><[EMAIL PROTECTED]>wrote:
>
>> Is there documentation on the multi/transaction feature added in 3.4
>>other
>> than the Javadoc?
>>
>> -JZ
>>
>>

On Wed, Jan 4, 2012 at 10:03 AM, Jordan Zimmerman
<[EMAIL PROTECTED]> wrote:
> * Can someone give more detail on Op.check()? I assume it generates an
> error if the version of the path doesn't match, but the doc is confusing
> to me. What happens if the transaction has both a setData and a check?
>

I believe processing stops as soon as a check fails. We should clarify
that in the javadocs though.

> * Does ZooKeeper.multi() guarantee that there will be exactly 1 OpResult
> for every Op in the transaction. Further, is there an ordering guarantee
> for the OpResult list - i.e. the OpResults are in the same order as the
> Ops argument? If this isn't so, I don't see how someone could correlate an
> Op to its result.

Did the patch for https://issues.apache.org/jira/browse/ZOOKEEPER-1336
not do a good enough job on that?

>
> On 1/4/12 7:30 AM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>
>>Not really.
>>
>>On Wed, Jan 4, 2012 at 12:47 AM, Jordan Zimmerman
>><[EMAIL PROTECTED]>wrote:
>>
>>> Is there documentation on the multi/transaction feature added in 3.4
>>>other
>>> than the Javadoc?
>>>
>>> -JZ
>>>
>>>
>

>Did the patch for https://issues.apache.org/jira/browse/ZOOKEEPER-1336
>not do a good enough job on that?
Missed that - thanks.

On 1/4/12 10:20 AM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:

>On Wed, Jan 4, 2012 at 10:03 AM, Jordan Zimmerman
><[EMAIL PROTECTED]> wrote:
>> * Can someone give more detail on Op.check()? I assume it generates an
>> error if the version of the path doesn't match, but the doc is confusing
>> to me. What happens if the transaction has both a setData and a check?
>>
>
>I believe processing stops as soon as a check fails. We should clarify
>that in the javadocs though.
>
>> * Does ZooKeeper.multi() guarantee that there will be exactly 1 OpResult
>> for every Op in the transaction. Further, is there an ordering guarantee
>> for the OpResult list - i.e. the OpResults are in the same order as the
>> Ops argument? If this isn't so, I don't see how someone could correlate
>>an
>> Op to its result.
>
>Did the patch for https://issues.apache.org/jira/browse/ZOOKEEPER-1336
>not do a good enough job on that?
>
>>
>> On 1/4/12 7:30 AM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>
>>>Not really.
>>>
>>>On Wed, Jan 4, 2012 at 12:47 AM, Jordan Zimmerman
>>><[EMAIL PROTECTED]>wrote:
>>>
>>>> Is there documentation on the multi/transaction feature added in 3.4
>>>>other
>>>> than the Javadoc?
>>>>
>>>> -JZ
>>>>
>>>>
>>
>

If any of this needs more detail please do update the patch. Thanks.

On Wed, Jan 4, 2012 at 10:25 AM, Jordan Zimmerman
<[EMAIL PROTECTED]> wrote:
>>Did the patch for https://issues.apache.org/jira/browse/ZOOKEEPER-1336
>>not do a good enough job on that?
> Missed that - thanks.
>
>
>
> On 1/4/12 10:20 AM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
>
>>On Wed, Jan 4, 2012 at 10:03 AM, Jordan Zimmerman
>><[EMAIL PROTECTED]> wrote:
>>> * Can someone give more detail on Op.check()? I assume it generates an
>>> error if the version of the path doesn't match, but the doc is confusing
>>> to me. What happens if the transaction has both a setData and a check?
>>>
>>
>>I believe processing stops as soon as a check fails. We should clarify
>>that in the javadocs though.
>>
>>> * Does ZooKeeper.multi() guarantee that there will be exactly 1 OpResult
>>> for every Op in the transaction. Further, is there an ordering guarantee
>>> for the OpResult list - i.e. the OpResults are in the same order as the
>>> Ops argument? If this isn't so, I don't see how someone could correlate
>>>an
>>> Op to its result.
>>
>>Did the patch for https://issues.apache.org/jira/browse/ZOOKEEPER-1336
>>not do a good enough job on that?
>>
>>>
>>> On 1/4/12 7:30 AM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>>
>>>>Not really.
>>>>
>>>>On Wed, Jan 4, 2012 at 12:47 AM, Jordan Zimmerman
>>>><[EMAIL PROTECTED]>wrote:
>>>>
>>>>> Is there documentation on the multi/transaction feature added in 3.4
>>>>>other
>>>>> than the Javadoc?
>>>>>
>>>>> -JZ
>>>>>
>>>>>
>>>
>>
>

On Wed, Jan 4, 2012 at 10:03 AM, Jordan Zimmerman <[EMAIL PROTECTED]>wrote:

> OK - a few questions:
>
> * Can someone give more detail on Op.check()? I assume it generates an
> error if the version of the path doesn't match, but the doc is confusing
> to me.
Correct.
> What happens if the transaction has both a setData and a check?
>

They happen in sequence, but I couldn't say exactly which version the check
will see.  I suspect that it will see the version before the setData is
done.
> * Does ZooKeeper.multi() guarantee that there will be exactly 1 OpResult
> for every Op in the transaction. Further, is there an ordering guarantee
> for the OpResult list - i.e. the OpResults are in the same order as the
> Ops argument? If this isn't so, I don't see how someone could correlate an
> Op to its result.
>

Right.  One to one correspondence is the contract.

On Wed, Jan 4, 2012 at 3:21 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:

>
> > What happens if the transaction has both a setData and a check?
> >
>
> They happen in sequence, but I couldn't say exactly which version the check
> will see.  I suspect that it will see the version before the setData is
> done.
>
>
It actually depends on the placement of the check in relation to the set
inside the multi-op. If the check is before the set, the check will see the
version before the set, but if the check is after the set, then it will see
the updated version after the set increments it.

Keep in mind two things here:

(1) You may not need the check call at all as the Set() call will fail if
the version number doesn't match the specified version in the Set() call.
(2) Operations inside a multi-op update the state of any zknodes in the
multi-op and all subsequent operations in the multi-op will see that new
state.
(3) If the multi-op fails, all changes are discarded and we roll back to
the prior state.