[Engine-devel] Requirement for Locking Mechanism

[Michael Kublin]

----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, November 29, 2011 12:18:15 PM
> Subject: Re: [Engine-devel] Requirement for Locking Mechanism
> 
> On 11/29/2011 12:13 PM, Michael Kublin wrote:
> > Hi All,
> >
> > We are introducing a new short term locking mechanism at engine.
> > The motivation is races which are occurring between different
> > flows, the main problem is :
> > we did not update status of some entity and other flow was started
> > , which is a main cause for different collisions and situation
> > which
> > can not be fixed in appropriate way by engine or vdsm.
> > The current status is a workaround which is trying to reduce a race
> > : in many places in the code, there is additional query to DB in
> > order to check the appropriate status of entity.
> > The proposed solution is internal locking mechanism - which will
> > lock an appropriate entity until its status will not be updated in
> > DB, after that
> > an internal short term lock will be released.
> >
> > The design for locking mechanism can be found here:
> > http://www.ovirt.org/wiki/Features/DetailedLockMechanism
> 
> The page still has many remains of the template.
> 
> > The patch which is introduce an implementation for mechanism can be
> > found here: http://gerrit.ovirt.org/#change,403
> > (Using of new mechanism all around a code and integration with bll
> > will be sent in the future, including cleaning of workaround)
> >
> > Regards Michael
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> There's an implicit assumption that there's only going to be a single
> active backend working against the database?
> Y.
> 
Yes, the backend will lock some entity, until its status will not be updated in db, after that the lock will be released.
So, it will solve a race between canDoAction and beginning of execute of the command