New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Action failures don't reset the FSM state to its source state. #31

nepolean opened this Issue Jun 3, 2017 · 4 comments


None yet
3 participants

nepolean commented Jun 3, 2017

The FSM transition occurs regardless of the outcome of 'actions'. This will let the Since the only link between FSM framework & application logic is 'State', it is desired to reset the state of the FSM to its source state in the event of action triggered by transition throws Exception.

Any thoughts?


This comment has been minimized.


developer-x commented Jun 4, 2017

I purposely don't do this since Actions are side effects. The only thing that effects the State is the event. The correct way to deal with "rollbacks" is to model it. So, the event that kicks off the Actions should put the state into a "pending" state. At the end of the Action, the Action should emit an "Action Successful" event which would transition into a "success" state. If there is a failure, the Action should emit "Action Failed" event which would transition the State back to the previous state.


This comment has been minimized.

nepolean commented Jun 4, 2017

Thanks for the response. I have a different view here. Cause & Effect are the heart of event model. Undoubtedly, the event must trigger the transition. But the action must complete the transition.
The side effects of above-suggested model are -

  1. We end up creating many pseudo states. In fact every state is now divided into 2. Does not sound good from the readability point of view.

  2. The action code is overwhelmed with re-initiating the events. Kind of clumsy. I want my action to focus just on core business logic.. not FSM logic.

It would be nice the if the framework creates such pseudo states and takes intelligence decision to either rollback / forward based on the action's outcome.

What do you say?


This comment has been minimized.

bwzhang2011 commented Jun 5, 2017

@developer-x, @nepolean came up with some good suggestion that statefulj should take it into consideration. in real world,
it's not suggested that pending state should be raised and persisted so that each state transition would first lead to pending state.


This comment has been minimized.


developer-x commented Jun 10, 2017

StatefulJ is an event driven state machine. As such, only events determine state transitions.

More practically, StatefulJ was written so that transitions occur atomically within a database or repository. This leverages the database's concurrency mechanism. If we were to do what you suggest, we'd have to hold open a transaction while an action is occurring, committing only on success. Not only is holding open long running transactions problematic - but databases like Mongo don't offer transaction support - only atomic updates.

If you suggest we don't only open a transaction but reset the state on failure, then you've introduced a concurrency issue. What happens when thread-1 transitions to StateA to StateB then invokes an Action1. While Action1 is executing, thread-2 transitions from StateB to StateC. Then Action1 fails. What should we do in this instance? Should we reset back to StateA? Should we leave it alone?

So as you can see, the only solution to handle to rollbacks is to model it via the State Model.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment