# Activerecord concurrency

**URL:** <https://www.ruby-forum.com/t/activerecord-concurrency/144784>\
**Category:** Rails\
**Created:** [August 2, 2008, 12:51am UTC](https://www.ruby-forum.com/t/activerecord-concurrency/144784 "2008-08-02T00:51:57Z")\
**Posts on this page:** 5\
**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 2, 2008, 12:51am UTC](https://www.ruby-forum.com/t/activerecord-concurrency/144784/1 "2008-08-02T00:51:57Z")

</div>

Hey,

I want to make sure that a user doesn’t edit a row while another user is  
editing it.

A simple solution I figured was to set session[:editing] = row.id, and  
when a user clicks to edit a certain row, I’ll just check the sessions  
for that row.id. If some user is already :editing row.id, then I’ll  
render the necessary partial (e.g. “Cannot edit”). I have a problem with  
this approach, though, because the I use a link\_to\_remote “Edit”,…,  
:id =\> row.id

Apparently, session.model.update\_attribute(:editing, “row\_id”) doesn’t  
work. When I include the update\_attribute in a link\_to :action, it works  
fine. Anyone have any suggestions?

action:

session.model.update\_attribute(:editing, “row\_id”)  
respond\_to do |format|  
format.html { redirect\_to\_index}  
format.js  
end

Also, are there any better ways to do this?

Thanks!!

---

<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 2, 2008, 1:13am UTC](https://www.ruby-forum.com/t/activerecord-concurrency/144784/2 "2008-08-02T01:13:08Z")

</div>

On Aug 1, 2008, at 3:51 PM, Justin To wrote:

> Hey,
> 
> I want to make sure that a user doesn’t edit a row while another  
> user is  
> editing it.

…

> Also, are there any better ways to do this?

> **[ActiveRecord::Locking::Optimistic](https://api.rubyonrails.org/classes/ActiveRecord/Locking/Optimistic.html)**
>
> What is Optimistic Locking Optimistic locking allows multiple users to access the same record for edits, and assumes a minimum of conflicts with the data.

Is one way. -philip

---

<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 2, 2008, 1:40am UTC](https://www.ruby-forum.com/t/activerecord-concurrency/144784/3 "2008-08-02T01:40:02Z")

</div>

On 2 Aug 2008, at 00:12, Philip H. wrote:

> > 
> 
> …
> 
> > Also, are there any better ways to do this?
> 
> [http://api.rubyonrails.org/classes/ActiveRecord/Locking/](http://api.rubyonrails.org/classes/ActiveRecord/Locking/)  
> Optimistic.html

There are two problems here that are completely distinct:

- Two web requests are processed mostly simultaneously and you don’t  
want the updates to walk all over each other. Optimistic locking is  
one way of dealing with this (I outlined some approaches here:  
[Dealing with concurrency - Space Vatican](http://www.spacevatican.org/2008/6/8/dealing-with-concurrency))
- Two users are editing something at the same time eg:  
user 1 loads up the edit form  
user 2 loads up the edit form  
user 1 saves  
user 2 saves, overwriting user 1’s changes.

In the second case one way of dealing with it is having a field on the  
edited object that stores the id of the user edited it (and probably a  
timestamp so that you can deal with expired edit attempts).

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 2, 2008, 1:54am UTC](https://www.ruby-forum.com/t/activerecord-concurrency/144784/4 "2008-08-02T01:54:04Z")

</div>

On Sat, 2008-08-02 at 00:39 +0100, Frederick C. wrote:

> > > I want to make sure that a user doesn’t edit a row while another
> 
> In the second case one way of dealing with it is having a field on the  
> edited object that stores the id of the user edited it (and probably a  
> timestamp so that you can deal with expired edit attempts).

* * *

#1 - your link has a closing paren which breaks the link…s/b  
[Dealing with concurrency - Space Vatican](http://www.spacevatican.org/2008/6/8/dealing-with-concurrency)

#2 - I have found opportunistic locking more than adequate (and safe  
from a lot of issues) but it took me a little while to figure out that I  
needed a hidden\_field ‘lock\_version’ on my form to pass back to the  
controller for saving. And yes, it does require some coding effort in  
the controller to deal with a lock\_version failure.

Craig

---

<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 2, 2008, 2:15am UTC](https://www.ruby-forum.com/t/activerecord-concurrency/144784/5 "2008-08-02T02:15:07Z")

</div>

On 2 Aug 2008, at 00:52, Craig W. wrote:

> > user 2 saves, overwriting user 1’s changes.  
> > #2 - I have found opportunistic locking more than adequate (and safe  
> > from a lot of issues) but it took me a little while to figure out  
> > that I  
> > needed a hidden\_field ‘lock\_version’ on my form to pass back to the  
> > controller for saving. And yes, it does require some coding effort in  
> > the controller to deal with a lock\_version failure.

I remember a thread on this a while back. As you point out the trick  
is what you do when you do have a conflict to minimise annoyance/  
disruption to the user.  
In the particular case of some of the stuff i’ve worked on there could  
be a good 5-10 minutes between starting to edit the form and you  
finishing it (and in general the work only needs doing once), in cases  
like that i’ve found the ‘edit in progress’ flag useful as it avoids  
two users expending essentially duplicate effort. In other cases that  
might be completely irrelevant.

Fred