I expect any of these proposals will be relatively simple to implement. My understanding is that ZK serialises *all* accesses to the data tree, so there's no need to worry about acquiring individual locks for each znode. This should be a cautionary note on performance, however: as there is no parallelism in the execution of updates (although there is plenty in the serialisation process) we should build a mechanism to constrain how much work this operation can perform, otherwise there's a danger of hurting throughput for all clients of a cluster. ZK could do with namespaces, or a cleverer locking mechanism like traditional databases use, to mitigate this issue but that's a much larger undertaking.
Figuring out a good API for the ensemble to implement can be slightly decoupled from the API that a client application sees. Therefore I prefer the list parameters API, which can be wrapped in a builder API in Java if that makes sense (these kinds of API are less natural in C, for example). cheers, Henry On 16 December 2010 10:39, Jared Cantwell <[email protected]> wrote: > I think that syntactic sugar can be very limiting. What if you have X > children you would like to update, but don't know X until runtime? I like > the idea of lists that don't have to be subsets of each other, giving more > flexibility. I also think it would be interesting to discuss what > additional recipes could be developed with this api. > > ~Jared > > On Thu, Dec 16, 2010 at 1:06 PM, Dave Wright <[email protected]> wrote: > > > I'm not sure why (other than your syntax) you would require the second > > list (to update) to be a subset of the first (to test). There are > > plenty of situations where you may want to update one node based on > > the value of another (and test that the value hasn't changed before > > updating) but don't really care about the second node, and it would > > just be extra overhead to check it's current value. In fact, I think > > that was the OP's situation. > > > > -Dave > > > > On Thu, Dec 16, 2010 at 1:01 PM, Ted Dunning <[email protected]> > > wrote: > > > Yes. This is isomorphic to my suggestion to allow null data. We > should > > > toss around many options to figure out which is the most congenial > idiom. > > > Yours is nice since it has two sets of parallel lists. > > > > > > In java with optional arguments it would be possible to use a builder > > style > > > with optional arguments: > > > > > > zk.testVersions(node1, version1, node2, version2, ...) > > > .updateData(node1, data1, node3, data3, ...) > > > > > > I would tend to make it part of the contract that the nodes in the > second > > > part be a subset of of the nodes in the first part. The first method > > would > > > create an object packaging up the first set of args and the second > method > > > would do the work. Of course, this is just syntactic sugar for the > more > > > list oriented version. > > > > > > On Thu, Dec 16, 2010 at 8:16 AM, Dave Wright <[email protected]> > wrote: > > > > > >> My recommendation would actually be a combination of the two which > > >> offers the most flexibility: > > >> > > >> zoo_multi_test_and_set(List<string> znodesToTest, List<int> versions, > > >> List<string> znodesToSet, List<byte[]> data） > > >> > > >> ...this specifies a list of nodes & versions to check, and if the > > >> versions match, a list of nodes to set and the associated data. > > >> This allows multiple scenarios, including setting nodes other than the > > >> ones you are version checking, setting more nodes than you version > > >> check, checking more nodes than you set, etc. > > >> I don't think the implementation would be any harder than either of > the > > >> others. > > >> > > >> -Dave > > >> > > >> > > >> On Wed, Dec 15, 2010 at 10:50 AM, Ted Dunning <[email protected]> > > >> wrote: > > >> > Well, I would just call the first method set. > > >> > > > >> > And I think that the second method is no easier to implement and > > probably > > >> a > > >> > bit less useful. > > >> > > > >> > The idea that the second might be almost as useful as the first is > > >> > interesting however. It probably > > >> > means that we should allow some of the data elements to be null or > > >> something > > >> > to allow for testing > > >> > versions but not setting data. > > >> > > > >> > On Tue, Dec 14, 2010 at 11:21 PM, Qian Ye <[email protected]> > > wrote: > > >> > > > >> >> zoo_multi_test_and_set(List<int> versions, List<string> znodes, > > >> >> List<byte[]> data） > > >> >> > > >> >> can solve the problem I mentioned before, and some relavant issues, > > like > > >> >> hard for programmers to use, as mentioned in mail-archive, should > be > > >> paid > > >> >> attention to. I think we can move small step first, that is, > provide > > >> >> interface like > > >> >> > > >> >> zoo_multi_test_and_set(List<int> versions, List<string> znodes, > > byte[] > > >> >> data, string znode） > > >> >> > > >> >> > > >> >> The API test versions of several different znodes before set one > > znode, > > >> and > > >> >> if the client want to set other znode, it can call this API > > repeatedly. > > >> >> Because we only set one node by this API, the result will be > > straight, > > >> >> success or failure. We need not take care of the half-success > result. > > >> >> > > >> >> How do ur guys think about this API? > > >> >> > > >> > > > >> > > > > > > -- Henry Robinson Software Engineer Cloudera 415-994-6679
