I was thinking of transactions more conceptually actually. Ideally, the same object shouldn't be able to have multiple transitions running at the same time. I'd really like to wrap all transitions with a lock method of some sort to prevent that. Then use a permission denied or something along those lines for when a transition is triggered while another is in process.
The transitions are a relatively small part of the workflow but obviously are gatekeepers of sorts and due to the db size/complexity most actions that hit the db take a couple seconds. Long enough that at least once we've had that happen where conflicting transitions were run simultaneously. On Thursday, December 11, 2014 1:31:42 AM UTC-7, Stefan Haslinger wrote: > > 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.
