Hey Ignacio, No, I've found 2 different cases were the transition does not occur cleanly.
1) A second conflicting transition from the same initial state is triggered before the state of the lifecycle is updated from the first transition. i.e. someone clicks one transition button, thinks better of it and tries to click the other. Both actually process if done quickly enough. 2) An exception occurring inside a transition, the state still changes, but none of the transition code past the exception takes effect obviously. For the first, I was thinking of adding a lock around the whole transition and the second, adding the option to wrap the whole transition as a transaction. Having a transaction inside the transition isn't sufficient as that's already in place and it still comes back in a mismatched state when an exception occurs. Thoughts? Thanks, Kevin On Tuesday, December 16, 2014 6:01:34 AM UTC-7, Ignacio Huerta wrote: > > 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] <javascript:> > > <mailto:[email protected] <javascript:>>. > > To post to this group, send email to [email protected] > <javascript:> > > <mailto:[email protected] <javascript:>>. > > 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.
