AR Stale object on SQL Server w/ lock_version

Rails
1

Hello all,

I’m getting stale-object-error from AR on objects that have lock_version
defined in MS SQL Server 2000.
The problem is not repeatable as of yet, and is happening on something
as
simple as the User table from LoginGenerator, to which I’ve added:

lock_version int default(0) not null

Has anyone experienced this problem?

Here’s some script/console output (this is actually from James A.'s
LoginEngine). Notice that nothing is different between the User.find
calls.

user = User.find(:first, :conditions=>“login = ‘admin’”)
=> #<User:0x372ebb0
@attributes={“salt”=>“ad71f490168ce50858feb1ebec0ec208b316d130”,
“delete_after”=>nil, “updated_at”=>
“2005/11/28 12:40:32”, “lock_version”=>2, “security_token”=>nil,
“role”=>nil, “lastname”=>nil, “firstname”=>nil, “id”=>4
8, “deleted”=>0, “token_expiry”=>nil, “verified”=>1,
“password_orig”=>“tmp”,
“logged_in_at”=>nil, “salted_password”=>“fd
57d7ba5818df53eb6fd2c53501d856c272a534”, “login”=>“admin”,
“created_at”=>“2004/09/01 15:53:34”, “email”=>nil}>

user.change_password(‘testing’, ‘testing’)
=> true

user.save
ActiveRecord::StaleObjectError: Attempted to update a stale object
from
C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.0/lib/active_record/locking.rb:42:in
update_without_callb acks' from C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.0/lib/active_record/callbacks.rb:274:inupdate_without_ti
mestamps’
from
C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.0/lib/active_record/timestamp.rb:39:in
update' from C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.0/lib/active_record/base.rb:1431:increate_or_update_with
out_callbacks’
from
C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.0/lib/active_record/callbacks.rb:249:in
`create_or_update’

    from

C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.0/lib/active_record/base.rb:1231:in
save_without_validati on' from C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.0/lib/active_record/validations.rb:687:insave_without_tr
ansactions’
from
C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.0/lib/active_record/transactions.rb:126:in
save' from C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.0/lib/active_record/transactions.rb:126:intransaction’
from
C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.0/lib/active_record/transactions.rb:91:in
transaction' from C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.0/lib/active_record/transactions.rb:118:intransaction’
from
C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.0/lib/active_record/transactions.rb:126:in
`save’
from (irb):4
from :0

user = User.find(:first, :conditions=>“login = ‘admin’”)
=> #<User:0x3a6ad48
@attributes={“salt”=>“ad71f490168ce50858feb1ebec0ec208b316d130”,
“delete_after”=>nil, “updated_at”=>
“2005/11/28 12:40:32”, “lock_version”=>2, “security_token”=>nil,
“role”=>nil, “lastname”=>nil, “firstname”=>nil, “id”=>4
8, “deleted”=>0, “token_expiry”=>nil, “verified”=>1,
“password_orig”=>“tmp”,
“logged_in_at”=>nil, “salted_password”=>“fd
57d7ba5818df53eb6fd2c53501d856c272a534”, “login”=>“admin”,
“created_at”=>“2004/09/01 15:53:34”, “email”=>nil}>

user.change_password(‘testing’, ‘testing’)
=> true

user.save
=> true

–

2

On 11/29/05, Peter F. [email protected] wrote:

Hello all,

I’m getting stale-object-error from AR on objects that have lock_version
defined in MS SQL Server 2000.
The problem is not repeatable as of yet, and is happening on something as
simple as the User table from LoginGenerator, to which I’ve added:

lock_version int default(0) not null

Has anyone experienced this problem?

I assume you’ve read up on ActiveRecord optimistic locking?

http://rails.rubyonrails.com/classes/ActiveRecord/Locking.html

In my limited use it’s worked exactly as expected. Can you check that
the lock_version is in fact the same when you’re saving? Look at the
logs…

–
rick
http://techno-weenie.net

3

On 11/29/05, Rick O. [email protected] wrote:

lock_version int default(0) not null

–
rick
http://techno-weenie.net

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

The lock_version in the logs match… just like the two gets from the
database in teh example above match.
Also, since I’m working in a confined space (development environment),
there
are no other objects or instances accessing the database or Rails at the
time of this test.

Further ideas ?