Hi Kevin, In theory transitions should only run the callback code after the DB record has been updated (http://hobocentral.net/manual/lifecycles#defining-transitions)
Maybe these transition callbacks aren't working correctly? Or you are using some other callbacks like "before_update" which are creating trouble? Warm regards, Ignacio El 11-12-2014 a las 18:12, kevinpfromnm escribió: > 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 > > <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 > <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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/hobousers. > For more options, visit https://groups.google.com/d/optout. -- 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.
