ZK 3.4.x still isn't marked "stable", so I'm a little hesitant to move to requiring it just yet.
What tangible benefit do we gain from the "transactional" methods? -Todd On Wed, Apr 18, 2012 at 1:48 PM, lars hofhansl <[email protected]> wrote: > +1 > > > > ----- Original Message ----- > From: Jesse Yates <[email protected]> > To: [email protected] > Cc: > Sent: Wednesday, April 18, 2012 1:33 PM > Subject: requiring zookeeper 3.4.x in 0.96 > > Hi all, > > I was working on some patches to make ZK a bit more sane using the > transaction operations recently added (in jira: > https://issues.apache.org/jira/browse/ZOOKEEPER-965 > <http://zookeeper.apache.org/doc/r3.4.3/api/org/apache/zookeeper/ZooKeeper.html#transaction%28%29> > and in the api here: > http://zookeeper.apache.org/doc/r3.4.3/api/org/apache/zookeeper/ZooKeeper.html#transaction%28%29). > This takes care of a lot of race conditions, etc. that are inherently > present in zk. > > Currently we (afaik) are not requiring ZooKeeper v.3.4.x in production and > instead allow users to run down to at least 3.3.x with the hbase's 3.4.x > client. Adding in transaction support will break this cross-version > functionality without a way of falling back as ZK doesn't (afaik) support > client-side look up of the server's version. Further, the fallback > functionality would be very dangerous if we assume transactions but fall > back to the non-transactional method; if we don't assume transactions, then > the transactional method is just wasted effort. > > I'm proposing that in the singularity (0.96), when we move to requiring > Hadoop v1.0+ we also make it a requirement that people run ZooKeeper v3.4+ > > Thoughts? > > Thanks! > > ------------------- > Jesse Yates > 240-888-2200 > @jesse_yates > jyates.github.com > -- Todd Lipcon Software Engineer, Cloudera
