----- Original Message -----

From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Michael Kublin" <mkublin@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@redhat.com> To: "Michael Kublin" <mkublin@redhat.com> Cc: "Yair Zaslavsky" <yzaslavs@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@redhat.com> To: "Michael Kublin" <mkublin@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel