Forcing a 'process' to wait on an object specific lock

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


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?

What you're looking for is called a "condition variable", and ruby has a class for that.

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.