[Engine-devel] Requirement for Locking Mechanism

[Itamar Heim]

On 11/29/2011 12:41 PM, Michael Kublin wrote:
>
>
> ----- 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

so how will distributed engines for scale out later on will look like 
with this mechanism?