zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baskar Duraikannu <baskar.duraika...@outlook.com>
Subject RE: Zookeeper performance
Date Wed, 31 Jul 2013 22:51:25 GMT
We cannot always resolve conflicts ourselves. For example, let us say that 
a) user1 changed the name from 'Kathy' to Katherineb) user2 changes the name from 'Kathy'
to 'Kat' 
Both read 'Kathy' as input; user1's update succeeded. If we need to let user2 know that something
has changed as this may result in the user not changing 'Kathy' to 'Kat' (as an example).
Hope this explains

> Date: Wed, 31 Jul 2013 07:49:39 -0400
> Subject: Re: Zookeeper performance
> From: camille@apache.org
> To: user@zookeeper.apache.org
> This sounds highly error prone to me regardless of whether or not zookeeper
> can handle the load-. Why not just use a standard transaction model with a
> vector clock or other timing device to detect conflicts so you don't have
> to worry about a second server to talk to (zookeeper) to do an update?
> On Jul 31, 2013 7:17 AM, "Baskar Duraikannu" <baskar.duraikannu@outlook.com>
> wrote:
> > Hello
> >
> > We are looking to use zookeeper for optimistic concurrency. Basically when
> > the user saves data on a screen, we need to lock,  read to ensure that no
> > one else has changed the row while user is editing data, persist data and
> > unlock znode.
> >
> > If the app/thread does not get a lock, we may set a watch so that polling
> > is avoided.
> >
> > Our application is write intensive certain times of the day. We may get
> > about 100k requests per second.  Can zookeeper handle this volume?
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message