You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Ted Dunning (Commented) (JIRA)" <ji...@apache.org> on 2011/12/01 00:09:39 UTC

[jira] [Commented] (ZOOKEEPER-1289) Multi Op Watch Events

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13160434#comment-13160434 ] 

Ted Dunning commented on ZOOKEEPER-1289:
----------------------------------------

Yeah.  And I really don't see a good way forward.  The master knows that the changes occurred in a multi, but I don't see how to notify the clients correctly in the context of the current API.

The problems that I see are these:

a) ordinary watches have to work even if a node is updated in a multi.  Moreover, ordinary watches on one client have to work even if another client wants a multi-watch.

b) what does it mean if I set a watch on one object and it and many others are modified?  What if one object is subject to multi-watching and another is subject to normal watching and both are in a multi?

I suppose that you might imagine that the server always sends multi notifications as multi's and never as individuals unless talking to a down-rev client.  Then the client would have to understand whether to deliver the notifications one at a time (old style) or all at once (multi-style).  The client could have a magic switch that says to deliver multi's as multi's.  But that still leaves the problem of what happens in case (b).

                
> Multi Op Watch Events
> ---------------------
>
>                 Key: ZOOKEEPER-1289
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1289
>             Project: ZooKeeper
>          Issue Type: New Feature
>          Components: c client, java client, server
>            Reporter: Marc Celani
>
> Caches built on top of zookeeper clients can become inconsistent because of lack of multi op watches. Our clients receive watch notifications for paths one at a time, and in their watch handling, invalidate the path in the cache. However, the cache now has an inconsistent view of zookeeper, since it is receiving the notifications one at a time. In general, the watch handling semantics do not conform with the idea of a multi op. If changes can be made to multiple paths atomically, all clients should be notified of that change atomically.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira