----- Original Message ----- > From: "Yair Zaslavsky" <[email protected]> > To: "Allon Mureinik" <[email protected]> > Cc: "Michael Kublin" <[email protected]> > 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" <[email protected]> > > To: "Michael Kublin" <[email protected]> > > Cc: "Yair Zaslavsky" <[email protected]> > > 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" <[email protected]> > > > To: "Michael Kublin" <[email protected]> > > > Cc: "engine-devel" <[email protected]> > > > 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" <[email protected]> > > > > To: "engine-devel" <[email protected]> > > > > 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 > > > > [email protected] > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > [email protected] > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
