On Mar 29, 10:15 pm, Lille <lille.pengu...@gmail.com> wrote: > Thanks gents. > > The nice thing about pessimistic locking for me could be that it would > help avoid the user problem to which Walter refers and I wouldn't have > to add columns to all my models, as I would for optimistic locking. > I think you are misusing terminology slightly - pessimistic locking usually refers to database level locks (ie select ... for update) which is definitely not appropriate for this sort of scenario.
> @Fred - I see you've written pretty often on the topic of optimistic > locking. What, to your reckoning, are the minimum changes I'd need to > make to my models & forms to ensure the following: > > + user 1 fails to make any updates to the resource they have obtained > from find > + user 2 arrives later, finds the object, and should have the ability > to update the resource > Personally, unless you think you will be able to merge potentially conflicting changes (as you would with git) the easiest think is to mark records as locked by a user. You could build in lock expiry - if it has been locked for over a certain duration, unlock the record automatically Fred > Thanks, > > Lille > > On Mar 29, 12:40 pm, Walter Lee Davis <wa...@wdstudio.com> wrote: > > > > > On Mar 29, 2011, at 11:15 AM, Lille wrote: > > > > Hi, > > > > I'm hoping to make a parent and several of its dependent children > > > available for updates by multiple users. I want to figure out how to > > > implement and test the following: > > > > 1. A user 'checks out' a parent resource: when seeking to update, > > > other users are informed that the resource and its dependent children > > > are currently unavailable for updating. > > > > 2. A user 'checks out' a child resource: when seeking to update, other > > > users are informed that the child is unavailable for updating, though > > > the parent may be available. > > > In both of these cases, the only time that the user would "know" that > > the element was locked is when they request it initially, or after a > > failure to save due to a lock. Have a read of optimistic locking in > > the Rails Guide. The only issue I can think of here is one of user > > frustration. Let's say they had just spent 20 minutes writing an > > update to a record, now they can't save it, and won't ever be able to > > save it because the starting point for their edit has moved underneath > > them. > > > Walter > > > > I think a reason I'm stumped here is that I have little deployment > > > experience. Yet, even so, how would I test the behaviors above, > > > locally? > > > > Thanks for any comments, > > > > Lille > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Ruby on Rails: Talk" group. > > > To post to this group, send email to rubyonrails- > > > t...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > rubyonrails-talk+unsubscr...@googlegroups.com > > > . > > > For more options, visit this group > > > athttp://groups.google.com/group/rubyonrails-talk?hl=en > > > . -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
