Hi Kevin, First, that's a super interesting question for me, here are my 2c:
Not for lifecycle transitions, but for general rails actions, I did it using Rails's Transactions: http://api.rubyonrails.org/classes/ActiveRecord/Transactions/ClassMethods.html This doesn't help you, if there are several user interaction steps necessary. But then, I would classify "start of transaction" when the last post from the user has happened and probably go with a Rails Transaction from there. To my understanding locking in Rails does not need another column, see Rails's Pessimistic Locking http://api.rubyonrails.org/classes/ActiveRecord/Locking/Pessimistic.html but I didn't have the need to use that up to now. I think I would be concerned about the amount of error handling, that's necessary, if locks are suddenly not exceptions, but almost to be expected. Mostly I have just been sloppy, especially when the probability of such a situation is low. Please don't take the following as unfriendly: If the transaction takes to long, there is a flaw somewhere (design?, implementation?). Because however you handle it, you have to block somehow, as you described yourself and that means forcing the other users to wait. One more choice would be to fork in background and run it whenever nobody is affected, but that mean's that even the acting user is not informed about success synchronously. Maybe, if you could give a more concrete example ... Greeting from Vienna, Stefan -- You received this message because you are subscribed to the Google Groups "Hobo Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/hobousers. For more options, visit https://groups.google.com/d/optout.
