zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Fines <scottfi...@gmail.com>
Subject Re: Understanding event interleaving
Date Thu, 23 May 2013 16:16:55 GMT
Thanks Flavio,Bahman, that was a great help. Turned out to be pretty straightforward, after
all.

Scott 

-- 
Scott Fines
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Thursday, May 23, 2013 at 9:04 AM, Flavio Junqueira wrote:

> Hi Scott,
> 
> The R client could receive either version 1 or version 2. In the case it receives version
1, it will receive the notification for the version 2 change once the server the client is
connected to receives the update. If the getData returns version 2 instead, it won't get the
watch triggered by the setData of steps 2 and 3 below. It should get it triggered by a future
update, though, assuming there is one.
> 
> -Flavio
> 
> -----Original Message-----
> From: Scott Fines [mailto:scottfines@gmail.com] 
> Sent: 23 May 2013 14:48
> To: user@zookeeper.apache.org (mailto:user@zookeeper.apache.org)
> Subject: Understanding event interleaving
> 
> Hello all, 
> 
> This is perhaps a silly question, but one I'm not clear on.
> 
> Suppose you have two clients (R and W), and they are interacting through znode Z. Now
consider the following situation:
> 
> 0. Z at version 1
> 1. R begins getData(Z) (attach Watcher)
> 2. W begins setData(Z) 
> 3. W completed setData(Z) successfully --e.g. the client call returns with no errors

> 4. R completes getData(Z) successfully -- e.g. the client call returns with no errors
> 
> My questions are then:
> 
> 1. What version of data will R receive? Version 1, or Version 2? My assumption here is
that R would receive version 1 of the data--is that correct?
> 
> 2. Does R's watch fire with the changes made by W? If so, is a WatchEvent delivered all
the way to the caller? A comment made on ZOOKEEPER-1505 (https://issues.apache.org/jira/browse/ZOOKEEPER-1505)
implies that it would not, but I'm unclear if that is in reference to the proposed changes
or not.
> 
> Thanks for your help!
> 
> Scott Fines 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message