I think you are looking at the race condition backwards. (and this btw is where 
the users had many of their bugs.) remember watches are one time triggers. so 
if you get a watch event it means a change has happened, so if /a is changed to 
1 and then changed to 2. the data that will come back in the watch event will 
be 1, but the latest data will be 2.

if the application uses 1 from the watch event and runs with that, it will not 
be using the latest value. it will not even know that it isn't using the latest 
value since it will never get another watch event when /a is set to 2.

generally, applications use watches to monitor a value. in that case you never 
would want to use the value you get from the watch. instead, you use the value 
you get from the read that reregisters the watch.

while the case in which a value only changes once, can be made slightly more 
optimal by passing the value in the watch event. it is not worth the risk. in 
our experience we had a application that was able to make that assumption 
initially and then later when the assumption became invalid it was very hard to 

we don't want to make zookeeper harder to use by introducing mechanisms that 
only work with subtle assumptions.


-----Original Message-----
From: burtona...@gmail.com [mailto:burtona...@gmail.com] On Behalf Of Kevin 
Sent: Wednesday, January 07, 2009 12:46 PM
To: zookeeper-user@hadoop.apache.org
Subject: Re: Sending data during NodeDataChanged or NodeCreated

On Wed, Jan 7, 2009 at 9:25 AM, Benjamin Reed <br...@yahoo-inc.com> wrote:

> This is the behavior we had when we first implemented the API, and in every
> case where people used the information there was a bug. it is virtually
> impossible to use correctly. In general I'm all for giving people rope, but
> if it always results in death, you should stop handing it out.

I think this is excessive rope...

Most people want to read the data and having a race here is just asking for

I'm not sure it is as much about excessive rope is it is about making it
easy for users to stumble on the correct use case and reduce bugs.

Ignorance is a wonderful gift you can give to your users :)

> In your example, if the ACL changed and then the data changed, we would
> have a security hole if we sent the data with the watch.

I thought you might mention that. :) Technically there wouldn't be a
security hole if the operation was this:
- set foo to 'asdf'
- set ACL to foo blocking everyone reading it...

If you needed to prevent a read of 'asdf' you need to do this:

- set ACL to foo blocking everyone reading it...
- set foo to 'asdf'

When they are 1ms apart it's hard to understand but imagine if they were 10
hours apart.

Technically, there would be a 1ms window where clients could do a getData()
on the file and read the value.


Founder/CEO Spinn3r.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Work: http://spinn3r.com

Reply via email to