This project is archived and is in readonly mode.
Caching of Exclusive Row Lock Requests by ActiveRecord
Reported by groe | February 25th, 2011 @ 11:17 AM
Hello,
I guess this is an unexpected behaviour or even a bug.
Calling
Model1.find(1, :lock => true)
Model1.find(1, :lock => true)
results in
Model1 Load (0.2ms) SELECT model1
. FROM
model1
WHERE model
.id
= 1
LIMIT 1 FOR UPDATE
CACHE (0.0ms) SELECT model1
. FROM
model1
WHERE model
.id
= 1
LIMIT 1 FOR UPDATE
and calling
foo = Model1.find(1)
foo.lock!
foo.lock!
results in
Model1 Load (0.2ms) SELECT model1
. FROM
model1
WHERE model
.id
= 1
LIMIT 1
Model1 Load (0.3ms) SELECT model1
. FROM
model1
WHERE model
.id
= 1
LIMIT 1 FOR UPDATE
CACHE (0.0ms) SELECT model1
.* FROM model1
WHERE model
.id
= 1 LIMIT 1 FOR UPDATE
IMO queries containing "FOR UPDATE" should never get cached by the ActiveRecord query cache, because that way the database doesn´t even notice the row lock request.
Can be fixed manually by wrapping calls of "lock!" in Model1.uncached-blocks. But IMO this should be automatically handled by ActiveRecord, am I wrong?
Regards
Comments and changes to this ticket
-
groe February 25th, 2011 @ 12:01 PM
My temporary fix:
config/lock_caching.rb
class ActiveRecord::Base def lock!(lock=true) self.class.uncached do self.reload(:lock => lock) unless new_record? end self end end
This disables caching of lock requests when calling "lock!" but does not handle arguments like {:lock => true} or {:lock => "FOR UPDATE"}. So is there a better way to fix this?
-
groe February 25th, 2011 @ 12:10 PM
- no changes were found...
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>