You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by Whitney Sorenson <ws...@hubspot.com> on 2016/02/01 19:41:57 UTC
ZooKeeper transaction properties (partial read)
Hi,
In searching through the ZK documentation, this list,
https://issues.apache.org/jira/browse/ZOOKEEPER-965, and curator
documentation (which we're using to talk to ZK) I can't find anything
definitive explaining the guarantees around using transactions.
I am now beginning to wonder if I wrongly assumed that partial reads were
not possible during transactions, because I have now observed this behavior
twice.
I'd just like to confirm that this is the expected behavior:
ZK 3.4.6
Curator 2.8.0
I write 2 nodes in a transaction, however, I am able to see one of the
nodes without seeing the other in 2 subsequent reads.
Eventually, I am able to see both nodes. When I am talking about seeing the
nodes I am talking about reads from the same client which issued the
transaction talking to the same ZK server.
- Whitney
Re: ZooKeeper transaction properties (partial read)
Posted by Whitney Sorenson <ws...@hubspot.com>.
I filed:
https://issues.apache.org/jira/browse/ZOOKEEPER-2362
On Tue, Feb 2, 2016 at 10:18 PM, Alexander Shraer <sh...@gmail.com> wrote:
> Hi,
>
> I think this situation shouldn't happen - the result of step 3 implies that
> the multi happened, so 4 should see it (multi should be atomic). Could you
> please open a high priority bug for this ?
>
> Thanks,
> Alex
>
> On Mon, Feb 1, 2016 at 2:40 PM, Whitney Sorenson <ws...@hubspot.com>
> wrote:
>
> > 1. Starting state : { /foo = <does not exist>, /bar = <does not exist> }
> > 2. In a multi, write: { /foo = A, /bar = B}
> > 3. Read /foo as A
> > 4. Read /bar as <does not exist>
> >
> > #3 and #4 are issued 100% sequentially.
> >
> > It is not known at what point during #2, #3 starts.
> >
> > - Whitney
> >
> >
> > On Mon, Feb 1, 2016 at 5:08 PM, Jared Cantwell <jared.cantwell@gmail.com
> >
> > wrote:
> >
> > > Am I understanding you correctly that you are observing the following?
> > >
> > > 1. Starting state {/foo = A , /bar = B}
> > > 2. In a multi, write {/foo->A', /bar = B'}
> > > 3. Read /foo as A'
> > > 4. Read /bar as B
> > >
> > > #3 & #4 start after #2 completes entirely, right? And #3 & #4 are
> issued
> > > 100% sequentially?
> > >
> > > ~Jared
> > >
> > > On Mon, Feb 1, 2016 at 2:54 PM, Alexander Shraer <sh...@gmail.com>
> > > wrote:
> > >
> > > > Reading the 965 JIRA what you're describing sounds like a bug.
> > > >
> > > > Alex
> > > >
> > > > On Mon, Feb 1, 2016 at 10:41 AM, Whitney Sorenson <
> > wsorenson@hubspot.com
> > > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > In searching through the ZK documentation, this list,
> > > > > https://issues.apache.org/jira/browse/ZOOKEEPER-965, and curator
> > > > > documentation (which we're using to talk to ZK) I can't find
> anything
> > > > > definitive explaining the guarantees around using transactions.
> > > > >
> > > > > I am now beginning to wonder if I wrongly assumed that partial
> reads
> > > were
> > > > > not possible during transactions, because I have now observed this
> > > > behavior
> > > > > twice.
> > > > >
> > > > > I'd just like to confirm that this is the expected behavior:
> > > > >
> > > > > ZK 3.4.6
> > > > > Curator 2.8.0
> > > > >
> > > > > I write 2 nodes in a transaction, however, I am able to see one of
> > the
> > > > > nodes without seeing the other in 2 subsequent reads.
> > > > >
> > > > > Eventually, I am able to see both nodes. When I am talking about
> > seeing
> > > > the
> > > > > nodes I am talking about reads from the same client which issued
> the
> > > > > transaction talking to the same ZK server.
> > > > >
> > > > > - Whitney
> > > > >
> > > >
> > >
> >
>
Re: ZooKeeper transaction properties (partial read)
Posted by Alexander Shraer <sh...@gmail.com>.
Hi,
I think this situation shouldn't happen - the result of step 3 implies that
the multi happened, so 4 should see it (multi should be atomic). Could you
please open a high priority bug for this ?
Thanks,
Alex
On Mon, Feb 1, 2016 at 2:40 PM, Whitney Sorenson <ws...@hubspot.com>
wrote:
> 1. Starting state : { /foo = <does not exist>, /bar = <does not exist> }
> 2. In a multi, write: { /foo = A, /bar = B}
> 3. Read /foo as A
> 4. Read /bar as <does not exist>
>
> #3 and #4 are issued 100% sequentially.
>
> It is not known at what point during #2, #3 starts.
>
> - Whitney
>
>
> On Mon, Feb 1, 2016 at 5:08 PM, Jared Cantwell <ja...@gmail.com>
> wrote:
>
> > Am I understanding you correctly that you are observing the following?
> >
> > 1. Starting state {/foo = A , /bar = B}
> > 2. In a multi, write {/foo->A', /bar = B'}
> > 3. Read /foo as A'
> > 4. Read /bar as B
> >
> > #3 & #4 start after #2 completes entirely, right? And #3 & #4 are issued
> > 100% sequentially?
> >
> > ~Jared
> >
> > On Mon, Feb 1, 2016 at 2:54 PM, Alexander Shraer <sh...@gmail.com>
> > wrote:
> >
> > > Reading the 965 JIRA what you're describing sounds like a bug.
> > >
> > > Alex
> > >
> > > On Mon, Feb 1, 2016 at 10:41 AM, Whitney Sorenson <
> wsorenson@hubspot.com
> > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > In searching through the ZK documentation, this list,
> > > > https://issues.apache.org/jira/browse/ZOOKEEPER-965, and curator
> > > > documentation (which we're using to talk to ZK) I can't find anything
> > > > definitive explaining the guarantees around using transactions.
> > > >
> > > > I am now beginning to wonder if I wrongly assumed that partial reads
> > were
> > > > not possible during transactions, because I have now observed this
> > > behavior
> > > > twice.
> > > >
> > > > I'd just like to confirm that this is the expected behavior:
> > > >
> > > > ZK 3.4.6
> > > > Curator 2.8.0
> > > >
> > > > I write 2 nodes in a transaction, however, I am able to see one of
> the
> > > > nodes without seeing the other in 2 subsequent reads.
> > > >
> > > > Eventually, I am able to see both nodes. When I am talking about
> seeing
> > > the
> > > > nodes I am talking about reads from the same client which issued the
> > > > transaction talking to the same ZK server.
> > > >
> > > > - Whitney
> > > >
> > >
> >
>
Re: ZooKeeper transaction properties (partial read)
Posted by Whitney Sorenson <ws...@hubspot.com>.
1. Starting state : { /foo = <does not exist>, /bar = <does not exist> }
2. In a multi, write: { /foo = A, /bar = B}
3. Read /foo as A
4. Read /bar as <does not exist>
#3 and #4 are issued 100% sequentially.
It is not known at what point during #2, #3 starts.
- Whitney
On Mon, Feb 1, 2016 at 5:08 PM, Jared Cantwell <ja...@gmail.com>
wrote:
> Am I understanding you correctly that you are observing the following?
>
> 1. Starting state {/foo = A , /bar = B}
> 2. In a multi, write {/foo->A', /bar = B'}
> 3. Read /foo as A'
> 4. Read /bar as B
>
> #3 & #4 start after #2 completes entirely, right? And #3 & #4 are issued
> 100% sequentially?
>
> ~Jared
>
> On Mon, Feb 1, 2016 at 2:54 PM, Alexander Shraer <sh...@gmail.com>
> wrote:
>
> > Reading the 965 JIRA what you're describing sounds like a bug.
> >
> > Alex
> >
> > On Mon, Feb 1, 2016 at 10:41 AM, Whitney Sorenson <wsorenson@hubspot.com
> >
> > wrote:
> >
> > > Hi,
> > >
> > > In searching through the ZK documentation, this list,
> > > https://issues.apache.org/jira/browse/ZOOKEEPER-965, and curator
> > > documentation (which we're using to talk to ZK) I can't find anything
> > > definitive explaining the guarantees around using transactions.
> > >
> > > I am now beginning to wonder if I wrongly assumed that partial reads
> were
> > > not possible during transactions, because I have now observed this
> > behavior
> > > twice.
> > >
> > > I'd just like to confirm that this is the expected behavior:
> > >
> > > ZK 3.4.6
> > > Curator 2.8.0
> > >
> > > I write 2 nodes in a transaction, however, I am able to see one of the
> > > nodes without seeing the other in 2 subsequent reads.
> > >
> > > Eventually, I am able to see both nodes. When I am talking about seeing
> > the
> > > nodes I am talking about reads from the same client which issued the
> > > transaction talking to the same ZK server.
> > >
> > > - Whitney
> > >
> >
>
Re: ZooKeeper transaction properties (partial read)
Posted by Jared Cantwell <ja...@gmail.com>.
Am I understanding you correctly that you are observing the following?
1. Starting state {/foo = A , /bar = B}
2. In a multi, write {/foo->A', /bar = B'}
3. Read /foo as A'
4. Read /bar as B
#3 & #4 start after #2 completes entirely, right? And #3 & #4 are issued
100% sequentially?
~Jared
On Mon, Feb 1, 2016 at 2:54 PM, Alexander Shraer <sh...@gmail.com> wrote:
> Reading the 965 JIRA what you're describing sounds like a bug.
>
> Alex
>
> On Mon, Feb 1, 2016 at 10:41 AM, Whitney Sorenson <ws...@hubspot.com>
> wrote:
>
> > Hi,
> >
> > In searching through the ZK documentation, this list,
> > https://issues.apache.org/jira/browse/ZOOKEEPER-965, and curator
> > documentation (which we're using to talk to ZK) I can't find anything
> > definitive explaining the guarantees around using transactions.
> >
> > I am now beginning to wonder if I wrongly assumed that partial reads were
> > not possible during transactions, because I have now observed this
> behavior
> > twice.
> >
> > I'd just like to confirm that this is the expected behavior:
> >
> > ZK 3.4.6
> > Curator 2.8.0
> >
> > I write 2 nodes in a transaction, however, I am able to see one of the
> > nodes without seeing the other in 2 subsequent reads.
> >
> > Eventually, I am able to see both nodes. When I am talking about seeing
> the
> > nodes I am talking about reads from the same client which issued the
> > transaction talking to the same ZK server.
> >
> > - Whitney
> >
>
Re: ZooKeeper transaction properties (partial read)
Posted by Alexander Shraer <sh...@gmail.com>.
Reading the 965 JIRA what you're describing sounds like a bug.
Alex
On Mon, Feb 1, 2016 at 10:41 AM, Whitney Sorenson <ws...@hubspot.com>
wrote:
> Hi,
>
> In searching through the ZK documentation, this list,
> https://issues.apache.org/jira/browse/ZOOKEEPER-965, and curator
> documentation (which we're using to talk to ZK) I can't find anything
> definitive explaining the guarantees around using transactions.
>
> I am now beginning to wonder if I wrongly assumed that partial reads were
> not possible during transactions, because I have now observed this behavior
> twice.
>
> I'd just like to confirm that this is the expected behavior:
>
> ZK 3.4.6
> Curator 2.8.0
>
> I write 2 nodes in a transaction, however, I am able to see one of the
> nodes without seeing the other in 2 subsequent reads.
>
> Eventually, I am able to see both nodes. When I am talking about seeing the
> nodes I am talking about reads from the same client which issued the
> transaction talking to the same ZK server.
>
> - Whitney
>