# Pessimistic locking

**URL:** <https://www.ruby-forum.com/t/pessimistic-locking/146101>\
**Category:** Rails\
**Created:** [August 17, 2008, 9:50pm UTC](https://www.ruby-forum.com/t/pessimistic-locking/146101 "2008-08-17T21:50:41Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jturney](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e99b99/32.png) [@jturney](https://www.ruby-forum.com/u/jturney)\
**Post date:** [August 17, 2008, 9:50pm UTC](https://www.ruby-forum.com/t/pessimistic-locking/146101/1 "2008-08-17T21:50:41Z")

</div>

Hey,

I’ve been trying to figure out how to use pessimistic locking. So far  
I’ve found this:

table.transaction do  
row = table.find(:first, :lock=\>true)  
row.col = blah  
row.save!  
end

I’m not that familiar with SQL or this activerecord layer so it’s a  
little bit confusing. First of all, is that how you use it? Secondly,  
this is what I’m trying to do:

two actions:

def edit

# render my form

end

def save

# save my form

end

When a user clicks on my link\_to to go to “edit”, I want to lock 1 or  
more rows (depending on a special # that identifies groups of rows in my  
table) So if this number is 5, then I want to lock all rows with  
“special”=5. I want it to be locked from editing, not from reading.

What is the exception that gets thrown if someone is already editing it?  
So I can do something like:

if being\_edited(exception)  
flash[:notice] = “Try again later.”  
redirect\_to\_index  
end

Also, how do I unlock the rows when a user closes the browser, or  
changes to a different page, or saves the form?

Thanks for the help!

---

<div class="post-metadata">

**Author:** ![jturney](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e99b99/32.png) [@jturney](https://www.ruby-forum.com/u/jturney)\
**Post date:** [August 17, 2008, 10:55pm UTC](https://www.ruby-forum.com/t/pessimistic-locking/146101/2 "2008-08-17T22:55:09Z")

</div>

On 17 Aug 2008, at 20:50, Justin To wrote:

> end
> 
> I’m not that familiar with SQL or this activerecord layer so it’s a  
> little bit confusing. First of all, is that how you use it? Secondly,  
> this is what I’m trying to do:

Yup that’s how it’s used.

> end
> 
> When a user clicks on my link\_to to go to “edit”, I want to lock 1 or  
> more rows (depending on a special # that identifies groups of rows  
> in my  
> table) So if this number is 5, then I want to lock all rows with  
> “special”=5. I want it to be locked from editing, not from reading.

This sort of ‘locking’ is completely different from locking as the  
database understands it.  
(If a row is locked and someone else tries to lock it that process  
will block until the lock is released or the database gets bored of  
waiting).

You would usually implement this by having a locked\_by attribute on  
the rows that you set when someone starts editing a row (the place  
were database level locking and so on comes it is how you ensure that  
if two people try to start editing a rows they don’t both end up  
thinking they’ve got the lock).

> What is the exception that gets thrown if someone is already editing  
> it?

> So I can do something like:
> 
> if being\_edited(exception)  
> flash[:notice] = “Try again later.”  
> redirect\_to\_index  
> end
> 
> Also, how do I unlock the rows when a user closes the browser, or  
> changes to a different page, or saves the form?

Stick a timestamp with the lock and check for outdated locks (either  
on a timer or perhaps just whenever you need to see if the lock is set).

Fred

---

<div class="post-metadata">

**Author:** ![jturney](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e99b99/32.png) [@jturney](https://www.ruby-forum.com/u/jturney)\
**Post date:** [August 18, 2008, 9:18pm UTC](https://www.ruby-forum.com/t/pessimistic-locking/146101/3 "2008-08-18T21:18:59Z")

</div>

Justin,

It might be helpful if you explain what you’re really trying to do.  
Generally speaking, pessimistic locking makes for a really bad user  
experience. Especially when the users aren’t physically located in the  
same room.

Every web application I’m aware of either uses a “last write wins”  
scenario or at most use some form of optimistic locking. Locking a  
record on the “chance” that two users “might” update the record at the  
same time is generally not the best approach. A better approach is a  
“detect and recover” scenario. This allows any number of users to open  
and edit the record. These conflicts can be caught and dealt with on a  
case-by-case bases using optimistic locking.

I would recommend looking into ActiveRecord’s support for optimistic  
locking rather than resorting to pessimistic locking. Just something to  
think about.

Justin To wrote:

> Ok Fred, thanks for the tips. I will try to implement it tomorrow!

---

<div class="post-metadata">

**Author:** ![jturney](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e99b99/32.png) [@jturney](https://www.ruby-forum.com/u/jturney)\
**Post date:** [August 18, 2008, 4:57am UTC](https://www.ruby-forum.com/t/pessimistic-locking/146101/4 "2008-08-18T04:57:26Z")

</div>

Ok Fred, thanks for the tips. I will try to implement it tomorrow!