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 diagnose. we don't want to make zookeeper harder to use by introducing mechanisms that only work with subtle assumptions. ben -----Original Message----- From: burtona...@gmail.com [mailto:burtona...@gmail.com] On Behalf Of Kevin Burton Sent: Wednesday, January 07, 2009 12:46 PM To: firstname.lastname@example.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 trouble. 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. Kevin -- Founder/CEO Spinn3r.com Location: San Francisco, CA AIM/YIM: sfburtonator Skype: burtonator Work: http://spinn3r.com