[Engine-devel] Improving of exist memory lock infrastructure in ovirt-engine

[Michael Kublin]

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Allon Mureinik" <amureini at redhat.com>
> Cc: "Michael Kublin" <mkublin at redhat.com>
> Sent: Sunday, February 3, 2013 10:01:31 AM
> Subject: Re: [Engine-devel] Improving of exist memory lock infrastructure	in	ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Allon Mureinik" <amureini at redhat.com>
> > To: "Michael Kublin" <mkublin at redhat.com>
> > Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > Sent: Sunday, February 3, 2013 9:58:58 AM
> > Subject: Re: [Engine-devel] Improving of exist memory lock
> > infrastructure	in	ovirt-engine
> > 
> > Basically, looks good to me.
> > 
> > My only consideration is the coupling of locks with async tasks.
> > We have flows (LSM, and much more to come) that are a series of
> > async
> > tasks, and we want to persist the lock throughout the logical flow.
> > As long as we have a way to do this (override endAction()?), the
> > design seems fine.
> > 
> > -Allon
You can persist a status of object (locked, shared lock, etc...) for presentation purpose, it is your internal logic.
But, canDoAction, races will be prevent by lock infrastructure, your responsibility is to choose a lock correctly (according to your use case)
and clean them when you need

> We would like to keep the lock until endAction.
> Regarding override - It will be the responsibility of all groups
> (currently virt and storage) to use the mechanism properly.

> 
> > 
> > ----- Original Message -----
> > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > To: "Michael Kublin" <mkublin at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, January 29, 2013 7:15:51 PM
> > > Subject: Re: [Engine-devel] Improving of exist memory lock
> > > infrastructure	in	ovirt-engine
> > > 
> > > Hi,
> > > I fixed some minor typos + have some comments on things need to
> > > be
> > > clarified.
> > > My comments are based on the sections + numbers inside the
> > > sections
> > > 
> > > Detailed Description
> > > 
> > > 3.  I think you should add:
> > > However, this behavior can be controlled as explained later on
> > > and
> > > a
> > > lock may be released after the end of "endAction".
> > > 
> > > 
> > > User-work-flows
> > > 
> > > 2. "If needed additional treatment the appropriate command will
> > > override getReadLocks() and getWriteLocks() methods of
> > > CommandBase
> > > <BR>"
> > > 
> > > 
> > > Don't you mean here the exclusive and shared locks?
> > > 
> > > 
> > > Failures -
> > > 4. In case task is found at DB, but not in SPM - will we want to
> > > clean it immediately at the first detection this issue occurs?
> > > (We
> > > talked about it today, and we think we should do that, giving
> > > other
> > > people a chance to comment)
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Tuesday, January 29, 2013 12:01:33 PM
> > > > Subject: [Engine-devel] Improving of exist memory lock
> > > > infrastructure in	ovirt-engine
> > > > 
> > > > The following link
> > > > http://www.ovirt.org/Features/DetailedLockMechanism contains
> > > > description and design of in memory lock infrastructure.
> > > > The design is describing already existing infrastructure with
> > > > additional changes that should be done in order to improve it.
> > > > The idea is to allow using of in memory locks with commands
> > > > that
> > > > can
> > > > create asynchronous tasks.
> > > > 
> > > > Regards Michael
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
>