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 <[email protected]> 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 <[email protected]>
> 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
> >
>
