For those who haven’t seen it, I’d like to first share Jay Pipes’ unbelievably thorough blog post on Nova update concurrency, specifically as it relates to the issue of emitting an UPDATE on a "locked” row without using SELECT..FOR UPDATE (as well as why we *can’t* keep using SELECT..FOR UPDATE). Go read it, I’ll wait here:
http://www.joinfu.com/2015/01/understanding-reservations-concurrency-locking-in-nova/ Got all that? OK. There’ve been two patches so far I’m aware of to implement this within a key area in nova. We have Jay’s and Matt Booth’s: https://review.openstack.org/109837 https://review.openstack.org/141115 So what I want to do with either of those (Matt’s seems to be a little further along) is factor out all that UPDATE stuff, and make a nice oslo.db function that will: 1. emit an UPDATE statement that matches a row on a full set of attributes present in a given object “specimen”; 2. if exactly one row matched, retrieve the primary key of that row using as efficient a means as possible given the backend database and schema design; 3. return a persistent version of the given “specimen” as though it was just SELECTed from the database. I have that ready to go, which most likely can be of use in many more scenarios than just this one. I invite folks to take a look: https://review.openstack.org/#/c/146228/ Example: specimen = MyModel( y='y9', z='z5', x=6, uuid='136254d5-3869-408f-9da7-190e0072641a' ) result = session.query(MyModel).update_on_match( specimen, 'uuid', values={'x': 9, 'z': 'z3'}) # result is now a persistent version of "specimen" (at the moment # the same object) with all the new values. the UPDATE statement guaranteed # to match all of x, y, z and uuid. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
