Ruby on Rails Friday, February 1, 2013

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?

On Friday, February 1, 2013 5:37:58 AM UTC-8, Frederick Cheung wrote:



On Thursday, January 31, 2013 11:55:40 PM UTC, yo...@scope5.com wrote:

The resulting behavior is that (assuming that two code sections tried to operate on the same meter concurrently), one would get there first and the second would be blocked until the first called the OSUnlock. At that time, the second would run and I would be assured that the code sections would always run in sequence for any given meter (as opposed to concurrently).

In Ruby/Rails, I see that there are mutexes, but they seem to be applicable to multiple threads running on the same in memory objects. In my case, the user request is going to load its copy of the meter from the database and the cron task is going to load its copy, so - mutexes don't help. Transactions and pessimistic locking seemed promising, but from my experimentation with them they will only prevent concurrent operations on the specific object that is locked. Operations on associated objects, even if they are inside transaction blocks, can still run concurrently. So - it seems that the executing code is not waiting, rather, the database access, for the locked object only, is waiting.

I need to block the cron task from executing any further than where the lock is taken until the user task releases the lock (and vice versa). How do I do that?

You can still use a database lock on the meter as the gatekeeper to modifying either the meter or its associated objects (although obviously you need to do this in the webapp side too). In fact you don't necessarily need a long lived database lock - it is sometimes easier to have a locked / locked_by attribute on the model, and only use an actual database lock (or optimistic locking) when writing to it.

Actually blocking for a long time on something is not something you really want to do in a web app (assuming this background processing is lengthy) - you're better off failing fast and telling the use to try later

Fred
 

Thanks,
Yoram

--
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/-/Mxfsg1FaIEwJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

No comments:

Post a Comment