[Ovirt-devel] ovirt-server patch for error 'Attempted to update a stale object'

[Ian Main]

On Fri, 16 Jan 2009 09:52:29 -0600
Steve Linabery <slinabery at redhat.com> wrote:

> On Fri, Jan 16, 2009 at 08:55:34AM +0100, Chris Lalancette wrote:
> > Ian Main wrote:
> > > On Thu, 15 Jan 2009 18:15:10 +0300 Василец Дмитрий <d.vasilets at peterhost.ru>
> > > wrote:
> > > 
> > >> patch for  error 'Attempted to update a stale object'
> > >> 
> > >> diff --git a/src/task-omatic/task_vm.rb b/src/task-omatic/task_vm.rb index
> > >> c187287..fddc594 100644 --- a/src/task-omatic/task_vm.rb +++
> > >> b/src/task-omatic/task_vm.rb @@ -196,8 +196,18 @@ def create_vm_xml(name,
> > >> uuid, memAllocated, memUsed, vcpus, bootDevice, end
> > >> 
> > >> def setVmState(vm, state) -  vm.state = state -  vm.save! +  attempts = 0 +
> > >> begin +    vm.state = state +    vm.save! +  rescue
> > >> ActiveRecord::StaleObjectError +     puts "error with stale object" +    if
> > >> attempts < 3 +      attempts += 1 +      vm.reload +    retry +    end +
> > >> end end
> > > 
> > > Interesting.  I know when doing certain long operations it can fail; never
> > > considered catching that and doing a retry.  I'll push a similar patch
> > > shortly.  I may just remove the puts and I'm not sure how many attempts we
> > > want to make?  Anyway I'll play with it.  Thanks!
> > 
> > This doesn't actually make sense to me, though; isn't a StaleObject exception
> > actually a sign of some deeper problem?  The last time I started getting these,
> > it was indeed a problem; I was removing an object (with object.delete), and then
> > later modifying the object, which was throwing these exceptions.  I think we
> > need to understand why we are getting a StaleObject first (or am I completely
> > missing what's going on here?).
> > 
> > -- 
> > Chris Lalancette
> 
> This is coming from Rails Transactions' optimistic locking support...
> 
> http://api.rubyonrails.com/classes/ActiveRecord/Locking/Optimistic.html

Thanks Steve,

It's very likely coming from db-omatic updating the state before
taskomatic completes.  I was seeing this in the qpid taskomatic as well
and fixed it in a few places.  I should go through and make sure the
rest are good.  Really we should be grabbing a fresh db object every
time we intend to write, not just at the top of a method/function.

	Ian