[Ovirt-devel] [PATCH server] Revised attempt at refactoring the vm_controller using the service layer.

Ian Main imain at redhat.com
Wed Apr 22 16:08:06 UTC 2009


On Tue, 21 Apr 2009 21:49:15 +0000
David Lutterkort <lutter at redhat.com> wrote:

> On Tue, 2009-04-21 at 13:14 -0700, Ian Main wrote:
> > So with this service layer.. with it being included and setting local
> > properties of the object, will that be thread safe?  Or will we have
> > to do locking around each call?
> > 
> > I'm not sure yet if the agent will be threaded.. but it certainly
> > could have a thread per method invocation..
> 
> To echo what Scott said: I would prefer if we followed the rails model
> fairly closely, with some sort of notion of a 'QMF controller', and
> instantiate one for every method call from the QMF agent.
> 
> Given that we want to minimize the amount of things we keep in memory
> (mostly to avoid cache coherency issues between memory and DB), we want
> the QMF API to be as statefree as possible.

Yeah that makes sense.. the only place where it might be a little odd is
in setting properties.  When properties are set it seems the way to do it
is to load the vm properties hash from an active record and then call
update() to have everything verified the same way as in rails?

I'm not sure if there's any other way to verify the contents of various
fields using the active record directly?  Either way it seems we need
direct acccess to it as well.. is that a problem?

    Ian




More information about the ovirt-devel mailing list