Excerpts from Doug Wiegley's message of 2014-07-30 09:48:17 -0700: > > I'd have to look at the Neutron code, but I suspect that a simple > > strategy of issuing the UPDATE SQL statement with a WHERE condition that > > I¹m assuming the locking is for serializing code, whereas for what you > describe above, is there some reason we wouldn¹t just use a transaction? >
I believe the code in question is doing something like this: 1) Check DB for initialized "SDN controller driver" 2) Not initialized -> initialize the SDN controller via its API 3) Record in DB that it is initialized Step (2) above needs serialization, not (3). Compare and update will end up working like a distributed lock anyway, because the db model will have to be changed to have an "initializing" state, and then if initializing fails, you'll have to have a timeout.. and stealing for stuck processes. Sometimes a distributed lock is actually a simpler solution. Tooz will need work, no doubt. Perhaps if we call it 'oslo.locking' it will make more sense. Anyway, my point stands: trust the experts, avoid reinventing locking. And if you don't like tooz, extract the locking code from Heat and turn it into an oslo.locking library or something. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
