On Apr 4, 12:47 am, PierreW <[email protected]> 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 <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
