This is similar to a application I am working on. In my case, all updates to the database, with one exception, can be done atomically. For examples, use SQL UPDATE to increment a field rather than read with pure Rails/ActiveRecord, increment model instance, and write. The one exception is adding new instances of model with several assocations.
My solution is that all problematic actions are done with ONE Resque worker that runs forever. The cron jobs are Ruby (not Rails) programs that enqueue a task to the Resque worker. This has worked very well. I was pleasantly surprised how easy it went together. The one con is that Resque workers are not good about reporting exceptions and other problems and in the development environment they reload properly after most, but not all changes. So in the development environment if there are problems or I am making big and deep changes, I will stop the Resque worker and run the problematic code with script/runner or whatever the Rails 3 equivalent is. HTH, Jeffrey Quoting PierreW <[email protected]>: > 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. > > Adding an index was actually fairly easy. > > 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. > -- 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.
