[
https://issues.apache.org/jira/browse/ZOOKEEPER-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144610#comment-13144610
]
Marc Celani commented on ZOOKEEPER-1289:
----------------------------------------
Ted,
We'd need two changes. On the server side, we need a WatchedEvent with a new
EventType Multi. Its comprised more watched events, much like multi response
looks. After committing a multi op, the watch manager would calculate the set
of clients that should receive notifications, and for each client, the list of
events that it is interested in. This multi watch event is sent to the client.
That's the easy part.
On the client side, we know we received all of the watches together and can
fire the individual watch handlers in the order they are listed. This is
probably the best way of doing it without breaking backwards compatibility. For
more interesting watch scenarios, we could add an API to add a multi watch
function, which handles multi op watches either before or after the
corresponding individual watches (could be an option in the API).
Going from my issue of cache consistency, receiving all of the watches in one
packet prevents a partition from causing inconsistency, which is our main
concern. In order to atomically invalidate the entries in my cache, I could add
a multi op watch function that locks all of the affected cache entries and
invalidates them. I would specify that my multi op watch function is fired
before the corresponding individual watches, so that if my watch handling fails
in any manner, I don't commit only some of the invalidates but not all of them
(our cache is a persisted cache, so the possibility of failure is very
possible). Maybe as an additional "nice to have", I could specify in the multi
op watch handler registration API that multi ops should be handled by the multi
op handler only, and all other watchers should not be notified.
> 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
