Ruby on Rails

On Apr 4, 12:47 am, PierreW <wamre...@googlemail.com> wrote:
> I don't know if using pessimistic locking is the best way to do it,
> but here is why I used this:
>
> - every X hours a demon runs and updates records
> - thing is, this demon "action" can last Y with Y > X
>
> So there is a risk that two instances of the demon try to update the
> same record. So each demon needs to acquire the lock before they can
> do anything on a given record.
>
> I guess an alternative could be to try and make sure that a demon only
> starts if the previous one has finished but this was not an option in
> my case.
>

You might want to look at separating the concept of the SQL lock
(which do have costs, can land you with deadlocks etc) from the
application level lock.

You could have a locked column (better a locked_since column) that
indicates that the row is locked. Use optimistic or pessimistic
locking to update the locked_since column, and make your update stuff
ignore records with a non null locked_since

Fred

> On Apr 4, 12:37 am, Robert Walker <li...@ruby-forum.com> wrote:
>
>
>
>
>
>
>
> > wam r. wrote in post #1054714:
>
> > > Hi guys,
>
> > > I must be missing something obvious with pessimistic locking. Here is
> > > what I do (Rails 2.3, mySQL):
>
> > So is there a reasonable use case for pessimistic locking on a web
> > application? That seems insane to me.
>
> > --
> > Posted viahttp://www.ruby-forum.com/.

--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.