How to Synchronize?

rubyonrails-talk
1

Mutexes aren't for cross process synchronisation (unlike a mutex in windows which can be shared across processes).

Fred

2

Frederick Cheung wrote:

First I suspected that this problem is originating because Passenger was spawning processes and they are not sharing the mutex. But I checked the documentation but couldn't find a mention of it. And in this link (http://m.onkey.org/2008/10/23/thread-safety-for-your-rails) it says that it's OK to use Mutexes (though not mentioning the multiprocess passenger).

Mutexes aren't for cross process synchronisation (unlike a mutex in windows which can be shared across processes).

Fred

OK. Then it means Mutex'es don't work in a multi-process Passenger setup.

But then how can I synchronize this method's usage? I am very new to web development so I just heard about database locking.

Simply, how should I use the ActiveRecord::Transactions::ClassMethods#transaction and ActiveRecord::Base#lock!?

Would it be OK to create a model and its corresponding table for just locking? i.e. Lock model and locks table.

Then use them like this:

Lock.transaction do

  lock = Lock.find(1)   lock.lock!

  # do my stuff which should be done by only one process at a time.

end

Thanks, Onur

3

OK. Then it means Mutex'es don't work in a multi-process Passenger setup.

But then how can I synchronize this method's usage? I am very new to web development so I just heard about database locking.

Simply, how should I use the ActiveRecord::Transactions::ClassMethods#transaction and ActiveRecord::Base#lock!?

Would it be OK to create a model and its corresponding table for just locking? i.e. Lock model and locks table.

That or rails' optimistic locking might be useful. I would usually shy away from creating a Lock model, it just seems a bit artificial. I would probably stick a locked_by_foo column on the appropriate model and use that to tell whether a particular object is being updated (and use optimistic locking in conjunction with that)

Fred

4

Would it be OK to create a model and its corresponding table for just locking? i.e. Lock model and locks table.

That would be pointless. If you wrap your DB operations in a transaction, you will automatically get the appropriate locks -- and the DB will keep track of them, so you don't have to.

Best, -- Marnen Laibow-Koser http://www.marnen.org marnen@marnen.org

Yes, I got your point.

But I think that the situation is not that clear. I don't know a single model to have a transaction open and be safe after.

So you might be right if I had a design which kept that in mind right from the beginning. But -at least as a workaround- I need something like that.

A moment ago, I found this:

This is pretty much the functionality I require.

I think I will use this.

Didn't anybody require anything like this?

Thanks Onur