6:01 a.m.
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
To: "Allon Mureinik" <amureini(a)redhat.com>
Cc: "Michael Kublin" <mkublin(a)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(a)redhat.com>
> To: "Michael Kublin" <mkublin(a)redhat.com>
> Cc: "Yair Zaslavsky" <yzaslavs(a)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(a)redhat.com>
> > To: "Michael Kublin" <mkublin(a)redhat.com>
> > Cc: "engine-devel" <engine-devel(a)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(a)redhat.com>
> > > To: "engine-devel" <engine-devel(a)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(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>