Activerecord concurrency

Rails
1

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!!

2

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?

Is one way. -philip

3

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/
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)
  • 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

4

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

#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

5

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