Friday, February 1, 2013
On Friday, February 1, 2013 3:28:57 PM UTC, yo...@scope5.com wrote:
Thanks Fred.
You did drive right to the heart of the issue. The lock itself is indeed easy enough. It's the waiting on the lock that i'm not sure how to implement (other than a loop that tests the dbase lock, which doesn't seem right). I agree that in general, we don't want to block threads in a web app. But - in this case, the code section that needs to execute without interruption is very brief and the likelihood of collision between the two processes on the same object is very small.
I may yet adopt your suggestion of just telling the user to try again later. It's much more complicated if the cron task gets blocked (it would have to maintain a list of objects that it couldn't process, then go back and process them later). But - is there a way to block a process on some sort of lock/semaphore, other than loop/test/loop?
you should be able to block on a pessimistic lock - select ... for update will either acquire the lock or timeout/deadlock. (The .lock! method does that for you). Don't forget that the lock is released at the end of the current transaction (so if there is no transaction the lock is released immediately.
Fred
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/pMPvNT2-9HUJ.
For more options, visit https://groups.google.com/groups/opt_out.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment