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" <[email protected]> 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?
