Hi Kevin, * About 1: I agree, a lock should be in place. Something like this should help: http://api.rubyonrails.org/classes/ActiveRecord/Locking/Pessimistic.html
* About 2: I agree that an exception in the "post transition" should rollback the whole transition. Please share if you find a workaround. I'll open an issue and try to address this too. Warm regards, Ignacio El 18-12-2014 a las 17:23, kevinpfromnm escribió: > 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 > <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> > > > > > <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> > > > > <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 > <http://groups.google.com/group/hobousers>. > > For more options, visit https://groups.google.com/d/optout > <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] > <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.
